cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: [RT] The environment abstraction, part II
Date Thu, 30 Mar 2006 19:23:50 GMT
Daniel Fagerstrom wrote:
> 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.

This makes complete sense to me and is exactly how I would have proposed
implementing it.

Upayavira

Mime
View raw message