Geoff Howard wrote:
...
Ah, and that's an issue. The JMS jars from Sun cannot be included in CVS because of the license. As an optional block, it's not a big deal but in core that'd be worse. Stefano has suggested rewriting an Apache licensed version of the API which apparently Tomcat has done with javax.servlet and friends.
That would be good, but probably a lot of work :-)
Geronimo was recently mentioned in same context.
To do this we really just need some code for a generic JMS client that we can extend to handle the CocoonBean.
Now, a generic JMS connection component is in the JMS block which may be all that's needed here.
No, what really needed is Cocoon MDB bean (and/or Cocoon stand alone Java JMS listener) which instantiates and invokes CocoonBean, in the same way as CocoonServlet does (or will be).
In any case, the code for the JMS connection is not very difficult and could easily be recreated for a JMS bean wrapper. What seems to be the tricky part is the Environment - does the CLI provide a CLIEnvironment for example?
The CommandLineEnvironment would do the job I'm sure, even if somewhat wrongly named. We would only want to switch to another one if the JMS protocls offer some information that is required within pipelines. That wouldn't be needed to start with, I'm sure.
JMS does offer some things, like message properties which are similar to HTTP request/response headers. JMS environment should be written to get/set those and other JMS specific things.
Vadim
