cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [cocoon-2.2] Deprecation
Date Thu, 08 Nov 2007 08:04:21 GMT
Grzegorz Kossakowski wrote:
> Carsten Ziegeler pisze:
>> Yes, that's true. Now, at some point we have to break compatibility to
>> get a cleaner architecture and
>> an even better way of doing things. Perhaps removing sub sitemaps is one
>>  of these things, perhaps not.
> 
> Before we start to think about migration path and embedding 2.1 as "emergency help" for
existing
> users I really think we should agree what we are going to deprecate and remove in the
future and
> most importantly how we envision future Cocoon's architecture so there will be no "perhaps
yes,
> perhaps no" doubts any more.
Good point.

> 
>> But on the other hand there are many applications out there using this
>> stuff and they don't want to migrate. There is no real benefit for them.
>> But there is benefit for them using latest and greatest Cocoon for now
>> stuff. And this is very I think embedding 2.1 in 2.2 might make sense.
>> It allows people to run their old applications without modifications
>> while at the same time they can start new apps with 2.2.
> 
> If people don't want to migrate I would tell them to stick to 2.1, it's stable and final
release of
> 2.2 won't make 2.1 unusable.
Yes, but what about bug fixes etc.? Given the activity over the last
year I doubt that there will be any 2.1.x release. And people want to do
new things with Cocoon while at the same time keep their apps running.

But this is more a hypothetical discussion :) All I want to say is that
we should not care too much about compatibility. We should find a clean
and great solution for future Cocoon versions.

> 
>> As Cocoon 2.2 uses Spring as the container and as the Cocoon beans are
>> added to the Spring root container, these things are available in 2.1
>> through Spring as well. So people are able to call 2.2 stuff from within
>> 2.1. It might be a thin bridge in terms of possibilities but I think
>> going this way makes things easier.
> 
> Carsten, haven't you forgotten that in 2.2 all components (even Avalon-based) are managed
by Spring?
Hmm, no - it was me who created this stuff :)

> I mention this because I can easily imagine clashes between the same components defined
both in 2.1
> and 2.2. If you want to make anything usable you must assure collaboration in both ways
between 2.1
> and 2.2 so all components must be shared and clashes are unavoidable IMHO.
No, I don't think so - keeping them separate is the key I think. We
would even have to run Cocoon 2.1.x in an own class loader to avoid
class clashes. Basically I think it could work like this: the global
spring container contains spring stuff and cocoon 2.2 stuff. There is
some bridging servlet registered which forwards to an embedded Cocoon
2.1.x which runs in an own class loader and own Avalon container. There
is no direct conncetion to spring or 2.2. However people could get the
global spring container inside 2.1.x and use the registered beans.

> 
> Really, the more I think about this I idea the more obstacles I see but maybe I'm lacking
something.
Yes, maybe it's not that easy - but currently I think it should be
doable without too much work and too many problems. If we come to the
conclusion that this might be worth exploring I could have a look at it
by the end of December.

> Anyway, I think that the most important point is made earlier that we must establish
goals we want
> to achieve before we start to think about implementation.
Absolutely true. I also think that we should get 2.2 out first. We can
delay all this deprecation etc. for one release.

> 
> Thinking more about incompatibilities between cocoon: and servlet: protocols I'm getting
an
> impressions that they are not such fundamentally different when it comes to their usage
schemes. Of
> course they differ in many details but as Reinhard properly characterized differences
comes from the
> fact that servlet: protocol just tries to avoid side-effects cocoon: protocol allows.
Yepp, but unfortunately too many people rely on these side-effects :(

Carsten


-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message