[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 \
SessionId '' is invalid, no access to xmlBlaster.
(see server.log3 and xmlBlasterClient.pl.log in annexe)
Same symptom for messagesList.pl.
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
You'll find in annexe a patched version of ConnectQos.pm that works
correctly (xmlBlasterClient.pl and also messagesList.pl now
works as intended).
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
Yes, this will certainly come when we release xmlBlaster 1.0
You are right again.
- 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.
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
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.
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
just my additional two euro-cents
Just my two cents...