cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: [cocoon-2.2] Deprecation
Date Mon, 05 Nov 2007 11:49:33 GMT
Reinhard Poetz pisze:
> I think that you refer to the idea of deprecating sub-sitemaps which
> isn't an as good idea as it seemed from a quick glance because there is
> no equivalent to get the same functionality if you have to replace it
> with servlet-services and Spring AOP. Hence I won't suggest sub-sitemaps
> for deprecation.

Solution does not exists *yet* but I guess we could find some replacement as soon as we know
functionality is lacking. AFAIR, Vadim mentioned following construct:

<map:match pattern="...">
  <map:act type="prepareSomething"/>
  <map:mount .../>
  <map:act type="finilazeSomething"/>

that cannot be replaced by use of Servlet Service Framework, right? If it's the only use-case
 surrounded by some initialization code) I guess we could easily find something equivalent.

Are there any other examples?

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

Not only <map:components/>. Mounting + cocoon protocol makes whole core unnecessary
complicated and
lacking of separation. Mounting involves creation of new context, cocoon calls affect code
sitemap and pipeline handling very deeply which is a bad sign IMO.

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

Yep. One of design goals of servlet: protocol was to share as less of environment as possible
cocoon: protocol shares and mixes as much as possible. I firmly believe in first approach
that makes
everything isolated thus simple and reliable.

We already have introduced quite advanced concepts like true OO in servlet service framework
so we
should be very careful on not creating another "magic" box that nobody knows and everyone
is scared
to fix or change.

There is a random thought: if we stick to the idea that environment is not shared between
caller and
called service we get clustering for free. I think you could easily imagine several blocks
services deployed to several separate machines. Then servlet services could be used remotely.
Thanks to the fact that we use only standard HTTP you could even deploy one block to several
machines and use standard load balancer for balancing load of all machines serving some servlet


> Can somebody who knows the code and the functionality of
> <map:components> and cocoon:/ in more detail than me comment on this?

I know cocoon:/ protocol quite well and I can assure that with conjuration of map:mount it's
very problematic part of Cocoon.

It's also not a good idea that we are going to have two competing solution for achieving the
yet core functionality of Cocoon.

> I think we should discuss these two big topics first and then we can
> continue with smaller things like the SimpleFormsTransformer, obsolete
> input modules, etc. I hope that I find some time soon to write a summary
> that contains a list with all those components.


Thanks Reinhard for bugging us on this topic and sorry for delays. I have finally some free
that I can devote to Cocoon now.

Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon

View raw message