Re: [xmlblaster] xmlBlasterClient.pl: SessionId '' is invalid + patch

[Marcel Ruff <mr at marcelruff.info>]

Dominique Petitpierre wrote:

> Hello,
>
> continuing my experiments with xmlBlaster demos, I tried the perl
> demos in demo/perl/xmlrpc.  When running xmlBlasterClient.pl, the
> following error message appeared on the xmlBlaster console:
>
> [May 16, 2003 2:12:41 PM WARN  \
> Authenticate-/node/http_129_194_17_16_3412.AccessDenied] \
> SessionId '' is invalid, no access to xmlBlaster.
>
> (see server.log3 and xmlBlasterClient.pl.log in annexe)
>
> Same symptom for messagesList.pl.
>
> Context:
>  xmlBlaster 0.846
>  Frontier-RPC-0.06
>  XML-Parser-2.31
>  expat 1.95.5
>  gcc 2.95.2
>  Solaris 9
>
>
> After investigation, the cause is to be found in an error in
> demo/perl/xmlrpc/xmlBlaster/ConnectQos.pm: it seems that the qos
> structure returned by a connect call has changed format, the sessionId
> info beeing now an attribute instead of a sub-element of the session
> element.
>
> You'll find in annexe a patched version of ConnectQos.pm that works
> correctly (xmlBlasterClient.pl and also messagesList.pl now
> works as intended).
Hi Dominique,

people sending patches are very welcome :-)
I have commited it to cvs.
(You should upgrade to xmlBlaster 0.847).
Getting this sort of feedback brings a nearer to our stable release 0.85.

> This leads me to the following remarks and suggestions:
>
> - If the format of the qos returned by a connection can change from
>  one distribution to another, (like here: sessionId becoming an
>  attribute), why not adding a version number as an attribute
>  (e.g. <qos version="1.1">) and check it systematically in each
>  client program?
Yes, this will certainly come when we release xmlBlaster 1.0

> - Just as documentation, demos are a very important part of a software
>  distribution; in a way they are a show-case of the possibilities and
>  features. Moreover, in the development process, demos are also
>  useful for testing the software after each changes (akin to a poor
>  man's regression tests). Therefore it would be nice if all the demos
>  distributed with each version of xmlBlaster were updated so that
>  they are functional with that version.
You are right again.
The proper way is to add all different demo in different programming 
languages to our
ant test case (build.xml).
Fully automated test are the only answer to this issue.
Probably we should push contributors even more to add autmated tests to 
the benefit of all.

> - Since all problems with demos cannot be avoided (because of
>  platform, third party software versions, etc.), it would be
>  nice to add to the documentation of each demo, some sample
>  output made on a reference installation. This would enable
>  newcomers to easily spot discrepancies instead of maybe
>  missing the point of the demo (see in annexe the log of
>  messagesList.pl which is not very explicit about the failure
>  that occurred).
You are right again ...
Here again we have a solution, our requirement xml documentation.
Probably we should push contributors even more to add those requirements.

Our guideline

 http://www.xmlblaster.org/xmlBlaster/doc/howto/developer-guidelines.html

asks the contributors already to do so.
But all of them are volunteers with dense schedules in their projects
so as in any real project the final documentation and often tests
are missing. But building a library without automated tests is almost
a no-go.

just my additional two euro-cents

Marcel


> Just my two cents...
>
> Best regards,
> Dominique
> --
>