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
