cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: [RT] The environment abstraction, part II
Date Mon, 30 Jan 2006 09:46:34 GMT
Daniel Fagerstrom wrote:
> 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.

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

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.

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

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

As I say, I feel much happier about this now, after seeing some of the
changes that have taken place since our last discussion.

Regards, Upayavira

View raw message