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 Sun, 29 Jan 2006 19:42:04 GMT
Carsten Ziegeler wrote:
> Daniel Fagerstrom wrote:
>> I suggested that we should ditch our environment abstraction and replace 
>> it with the javax.servlet.http set of interfaces, as one step in 
>> simplifying Cocoon in 
>> The result of the discussion was that there are some "extras" in our 
>> interfaces compared to the http servlet interfaces that are needed in 
>> the sitemap, so we would get back incompatibility and maybe other 
>> problems and it might be much work to accomplish.
>> Now I would instead suggest that our environment interfaces just extends 
>> the corresponding Servlet 2.3 (or 2.4) interfaces, Request extends 
>> HttpServletRequest etc. This should not create any problems with the 
>> current code base at all AFAICS, and would make it easier to make Cocoon 
>> cooperate with other systems.
>> Calling Cocoon from a Servlet environment is currently not a problem as 
>> we have wrappers, but it gets inconvenient to call servlets from  within 
>> Cocoon. And the block architecture is Servlet based for making 
>> integration and development of new controllers easier and the result 
>> more reusable. As the block protocol requires the sitemap to call back 
>> the block architecture it would be an advantage if we used the servlet 
>> set of interfaces.
>> Also for being able to use the CLI with blocks it need to be able to 
>> call the block architecture, and here it would also be an advantage if 
>> our environment interfaces extended the servlet ones.
>> I'd like to implement the above change ASAP, WDYT?
> First, I'm still not sure if this should go into the current 2.2 code
> base, but apart from that I now think we should even be more radical in
> this area and remove the whole environment abstraction completly and
> make Cocoon a web framework. Period.

Sorry, what do you mean by "web framework"? Isn't it already one? Or do 
you mean "servlet"?

> Now, we have currently two other environments: cli and portlets.

There's also BackgroundEnvironment for background jobs.

> A portlet is a web application, so there won't be any problem. And for
> the CLI we can come up with some kind of HttpClient that internally
> starts Jetty etc.

HttpServletRequest is an interface. So we just have to write a 
CliHttpServletRequest that implements that interface, just as we do 
today with our own interfaces.

AFAIU, what Daniel is proposing is to add an "extends" statement to our 
environment interfaces, which are very close to the standard 
javax.servlet ones. Just like we did with Cocoon's SourceResolver 
extending Excalibur's SourceResolver.

> This would simplify Cocoon even more - and has some other advantages as
> well. For example if you're using third party frameworks like spring or
> hivemind, they are using servlet context listeners. These are only
> available/working in a web environment. So as soon as you are using
> something like that, other environmnents would not work. There are other
> similar examples to this. For example the portal has extra code that
> checks if the portal is used in a servlet environment or not to avoid
> startup problems.
> And we could use a context listener for setting up Cocoon as well. Which
> would make Cocoon easy usable within other frameworks - it's the least
> intrusive way. So imagine a struts web app, which is calling Cocoon (and
> Cocoon has been set up by the context listener and is available through
> the context - similar to what Spring et.all. do).

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.


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

View raw message