...
If building a JMS wrapper to the bean would include referencing JMS jars which would then need to be moved to the core, I'd suggest adding it to the JMS block, otherwise, it could be core.
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 :-)
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. I don't know the bean well - it's not itself a component is it? In order for the existing JMS component to be directly reusable, it would need to be able to act on the bean which may be getting things backwards.
No its not a component. But it could probably be made into one - so long as the lifecyle methods aren't required for it to function.
What do you mean by 'act on the bean'?
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.
We may need to improve the bean to handle continuous running (it is used to a short (one run) lifecycle, so it should check that cocoon.xconf hasn't changed, etc, as does the servlet.
Ah, good point.
But shouldn't be hard.
Regards, Upayavira
