cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: Cocoon in Batch Environment
Date Sat, 18 Oct 2003 11:54:35 GMT
Upayavira wrote:

> 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.


>>> 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?

View raw message