cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [cocoon-2.2] Deprecation
Date Mon, 05 Nov 2007 10:46:41 GMT
>> IIRC it wasn't the functionality of <map:mount> that made some people
>> think that we should deprecate sub sitemaps but the <map:components>
>> part of sitemaps which causes a lot of complicated code that we have
>> to maintain. However, deprecating <map:components> shouldn't be a
>> problem because there already exists a migration path of putting your
>> component definitions into META-INF/cocoon/spring or
>> META-INF/cocoon/avalon.
Hmm, as long as you just have one sitemap in your block this works. But
as soon as you are using sub sitemaps in your block it's not the same.
If people are fine with the change that all components are visible for
the whole block this is no problem.

Please note, that with 2.2 there is an auto include for per sitemap
components which reads configurations from some sub directories. This is
a very nice feature which makes packaging very easy :) But perhaps with
using blocks this is not that important.

>> The second "big thing" for deprecation that we discussed in Rome was 
>> the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU
>> the servlet:/ protocol doesn't provide all the "features" of the
>> cocoon:/ protocol but that's mostly caused by getting rid of
>> side-effects.
>> Can somebody who knows the code and the functionality of
>> <map:components> and cocoon:/ in more detail than me comment on this?
I haven't looked at the implementation of the servlet: protocol, but I
know the (old) implementation of the cocoon: protocol. One of the main
problems are the sax events combined with the required context changes.
As sax events are directly send from a cocoon: call to the parent call
the context of execution has to change back and forth for each sax
events. A lot of things have to change and this was always a place for
interesting bugs and errors.

While directly sending sax events seems to provide more performance I
actually would not care about this today anymore. The context switch
should be done once, the result from the call should be buffered and
that's it. But I think the servlet: protocol is doing this already.


Carsten Ziegeler

View raw message