cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] The environment abstraction, part II
Date Sun, 29 Jan 2006 21:53:35 GMT
Carsten Ziegeler skrev:
> 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.

Agree, but as people (you included) had valid reasons for not going that 
far in 2.2, I suggest something less radical this time, as I want to get 
rid of the problem of calling servlets from within Cocoon already in 2.2.

> Now, we have currently two other environments: cli and portlets. 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.

Yes. For CLI an alternative is to have a minimal servlet container as 
part of the CLI. Maybe its possible to use Jetty in that way without 
needing to go over a socket?

> 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.

Yes, by letting our Request etc interfaces extend their http servlet 
counterparts we can always assume that Cocoon is executed in a servlet 
environment, (given that the actual environment provide rich enough 
implementations of course).

> 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).

We should definitively make Cocoon more friendly towards other frameworks.

> So, let's simplify Cocoon and remove this extra abstraction completly.

Would be nice. We will see what others think. For me it is most 
important that we let our environment api extend the http servlet api 
now, (which should be back compatible).


View raw message