week10+

Standalone version

Eveything seems to work fine. We tested several tasklists, including the one that was used on the last version of Unicorn. The tasklists (and rdf files) are saved on the CVS in a new folder : unicorn/conf/backup.

Tests on Tomcat

First step : deployment of Unicorn on the Flyingman server. We set the build.xml file so that the project can be deployed directly from Eclipse.BR JDK 1.5 is used on flyingman so we had to solve some issues of automatic class definition. After that, the tests in standalone seem to fit well with the results of Unicorn on flyingman.

We replaced the StringBuffer attribute of the Response by a StringBuilder because it caused a bug in character encoding. It implied the use of the deprecated class StringBufferInputStream which was the culprit. BR

Other enhancements :BR - Replace the observer ID by the exec ID as the key of the mapOfResponse in the UnicornCall class. Indeed, two execs could share the same observer but have different parameters. This implies a lot of changes since the observer ID is used as a key several times. In pauseBR - Move the XML response document from inside each Response object, in order to parse it only when needed ie when the output sequence is called. (basic solution : create a Response object with only the XML document in it, then at the time of the output, parse the XML document and fill the Response object)BR - Clean the code in the parsing : keep only one method with one possible argument.

Remaining issues

- The parsing of the XML response documents causes several problems. We have an alternative : BR

    ¤ we could repair the DefaultParser class so that all the cases of possible inclusion (between the different blocks such as Code, LongMessage, Img ...) work fine ;[[BR]]
    ¤ we could rewrite this class from scratch ; [[BR]]
    ¤ or rewrite the schema and make a simple and efficient DefaultParser.[[BR]]

- Test on Jigsaw ... Will it work ??