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.
WDYT?
/Daniel
