cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] The environment abstraction, part II
Date Mon, 30 Jan 2006 18:04:53 GMT
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>> Sorry, what do you mean by "web framework"? Isn't it already one? Or do 
>> you mean "servlet"?
> Cocoon is currently a mixture. It's mostly used as a web framework
> through a servlet, but for example if you're using the cli you don't
> have a web framework or a web server or something like that.
> Now, because of this, we have the environment abstraction. And I think
> we can remove that completly making Cocoon just a web framework which
> always has a servlet environment including listeners and filters etc.

Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based 
implementation of the servlet API, but having the Cocoon CLI launching 
an internal Jetty for this really seems wrong to me. Forrest is already 
a large beast, now if you say that generating a site requires to start a 
servlet engine, many people with run away for something probably less 
powerful but much more light.

Now Cocoon is much more than a web framework, as we discussed in the 
"necessary mutation" thread:
- a servlet
- a component container
- a controller
- a pipeline engine
- many blocks built on top of one of the above.

The CocoonBean used by the CLI is actually parallel to the servlet and 
uses the lower-level layers.

>>> Now, we have currently two other environments: cli and portlets.
>> There's also BackgroundEnvironment for background jobs.
> True, but as that one is running "inside" Cocoon it shouldn't cause
> problems either.

Right. But that also means we need to have request/response/context 
implementations that are totally decorrelated from a servlet 
environment. This is the same for the CLI also.

>> Hmm... Struts and Cocoon are on the same level, as they handle the 
>> request. Spring (its container part) is more to be compared with our 
>> ECM. So although setting up ECM as a context listener would make sense, 
>> Cocoon itself must remain a servlet to be able to handle requests.
> Yes, it can remain a servlet (although it might not need to be, but
> that's another topic). Why not, for example, calling pdf generation from
> let's say Struts?

This uses the servlet API, as calling Cocoon from Struts is done using 
the request dispatcher:
  request.getRequestDispatcher("/path/to/cocoon").forward(request, response)


Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message