cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] The environment abstraction, part II
Date Wed, 29 Mar 2006 20:54:59 GMT
Carsten Ziegeler skrev:
> David Crossley wrote:
>> Hi Daniel, sorry i cannot understand that last sentence.
>> Would you please re-phrase it.
>> We currently have the three ways:
>> 'forrest run'
>> Starts its packaged Jetty and uses Forrest/Cocoon as a webapp.
>> 'forrest war'
>> Builds a projectName.war ready for deployment in a full Jetty
>> or Tomcat.
>> 'forrest site'
>> Calls the Cocoon CLI to generate a static set of docs.
> I can't speak for Daniel, but my idea/suggestion was to forget about the
> different environments and let Cocoon always run in a servlet container.
> The CLI would then be kind of a http client which starts up jetty and
> then generates the site using http requests. This would simplify some
> things in Cocoon, the question is if this would make the life of Forrest
> too hard?
In Cocoon today, the Cocoon object that implements the Processor 
interface is in some way the top level interface against "Cocoon 
functionality". Then the CocoonServlet and the CLI booth sets up and use 
the Cocoon object. When creating the blocks fw, Processor didn't work as 
abstraction as it contains lots of tree processor specifics. So I 
decided to use the Servlet and javax.servlet.http set of  interfaces 
instead (as discussed on the list a couple of times). This means that 
the CLI in it current state (working against the Processor interface) 
doesn't work with the blocks fw. So the CLI needs to be refactored so 
that it works with a Servlet rather than a Processor.

To some extent this is actually an advantage as the CocoonServlet and 
the CLI has a lot of overlap and the servlet part has been maintained 
and developed while the CLI part hasn't. By using Servlet as the "top 
level" interface of Cocoon the CLI will be much smaller and reuse more 
of the Servlet work.

Back to your question, my incomprehensible sentence was an answer to 
something like what Carsten propose above. In many cases I agree with 
Carsten that it makes most sense to run Cocoon in a full servlet 
container but in some cases, e.g. testing and for a minimal OSGi setup, 
it makes IMO sense to have a really  light weight and minimal servlet 
container instead. I have built a such one for creating the servlet 
environment needed for running a servlet within a block and make it 
possible for it to communicate with other blocks. It is also used for 
the block protocol (the block correspondence to the Cocoon protocol). We 
could reuse part of this for the CLI.

So the current CLI is a minimal command line Processor container, we 
could have a minimal command line Servlet container instead.



View raw message