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 Mon, 30 Jan 2006 10:55:06 GMT
Upayavira wrote:
> Daniel Fagerstrom wrote:
>> Carsten Ziegeler skrev:
>>> 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.
> I am starting to change my mind about this in regard to 2.2. 2.2 is
> changing as a concept. It was previously just a small step up from 2.1,
> in which case a significant change in interface would not have been
> appropriate. However, particularly the maven build, but also a lot of
> the other stuff that is going on, is leading to some quite substantial
> improvements.
It starts to look like a 3.0 rather than a 2.2 and my personal goal is 
to implement the whole blocks design including OSGi. OTH I try to not 
hinder the possibility for a 2.2 release, given that someone is prepared 
to spearhead it.
>  More particularly Daniel's proposals to do with using
> servlet interfaces for block controllers would make it possible to
> implement some (or even all) of Sylvain's Cocoon 3.0 ideas within this
> framework.
That is the goal :)
> If this is the case, then it would seem timely to improve these
> interfaces now, as 2.2 given the greater flexibility could become _the_
> future Cocoon, and we may miss the boat if we don't make this change now.
Yes, I feel some urgency. With enough focus and dedication on 
refactoring Cocoon and finish the blocks Cocoon can be the Rich Server 
Platform ( And 
regain its momentum. Focusing on 2.2 seem more like losing valuable time 
for me.

But that is IMHO, if enough people are prepared to make a 2.2 happen, I 
will of course join in that work.
>>> 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?
> Why a servlet container? Or do you mean simple implementation of the
> servlet interfaces? That would be what we would need. Something to set
> up request and response and call the servlet's service() method.
I mean a simple implementation of the servlet interfaces as you suggest.

I haven't studied the CLI implementation in any detail, what is your 
opinion about letting it work on the servlet interfaces rather than at 
the Processor level. What consequences will it have?


View raw message