[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Dominique Petitpierre wrote:


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.

 xmlBlaster 0.846
 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


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


Just my two cents...

Best regards,