Geoff Howard wrote:
Upayavira wrote:
Friedrich,
I would recommend using Cocoon 2.1 for this purpose, as it has much more functionality.
In 2.1, the CocoonBean provides programmatic access to Cocoon's functionality, including a method for requesting that a page/resource be sent to a supplied output stream.
That's what I was going to suggest but figured you'd chime in ;).
:-)
I don't know anything about JMS (other than that it is a messaging service).
If it follows the usual request/response cycle, would it be possible to create a standard JMS interface to Cocoon, such that someone sends a JMS message to Cocoon by passing it a URI for a page/resource, and Cocoon then returns by JMS a message containing the generated page?
The request/response is decoupled but the same paradigm can be used. And really you'd not write a JMS server, but a client which would receive and send on a Queue or Topic. You could do point-to-point or publish-subscribe.
Ah. Good.
If this is possible, then a JMS interface to Cocoon shouldn't be too hard to create.
I think it would be a good thing to have in the Cocoon code base as another wrapper around the CocoonBean.
Does the Bean encapsulate all the non-servlet issues he'd face? What I mean is your work on the bean turned up areas where the code had become servlet-centric. Would he need to work through those again, or has the bean hidden those?
There are still some servlet specific problems, e.g. it won't run without Servlet.jar in the classpath, and more seriously, it currently won't run with the session-fw block included.
The only other option to consider is leveraging the JMS block which is developing now. I'd only recommend this if you need to use Cocoon for web requests too, or if it just seems so easy to implement that the pure standalone solution doesn't matter to you.
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.
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.
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?
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.
Geoff
I want to write a small JMS server that reads a message from the queue and
generates a report using cocoon. The generation of the reports spends a
long time in SOL querys and they can also grow very large. So i can't
generate them online in our webapplikation. But we need PDF and Excel
format, so cocoon would be a good choice.
My questions to the experts are:
* Ist the org.apache.cocoon.Main class a good starting point?
I hope i can reuse all the initialization of cocoon and only have to adapt
the main method for the queue reading loop. But i don't see a hook. I will
make a new class and copy the methods.
* A new environment will be necessary. The commandline environment is
designed to read a uri, the http environment is designed to handle a http
request. I will have a JMS message as request and a JMS message as reponse.
Is there something to reuse, or is it necessary to create a completly new
environment?
* What more is necessary? Will it work to have a JMSMain that initializes
cocoon, reads the incomming JMS messages, puts them in a JMSEnvironment and
delegates to cocoon? Is this realy all?
