cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Compatibility Issues with 2.2
Date Fri, 05 Dec 2003 14:30:05 GMT
Unico Hommes wrote:

>>-----Original Message-----
>>From: Carsten Ziegeler [] 
>>Sent: donderdag 4 december 2003 11:03
>>To: Cocoon-Dev
>>Subject: Compatibility Issues with 2.2
>>I'm a little bit concerned about compatibility between 2.1 and 2.2. Now, imho every
component developed for 2.1 should also work in 2.2 without requiring to change the code -
recompiling is acceptable.
>>There are of course two exceptions to this rule:
>>a) if you are using deprecated code
>>b) if you are using some private code/internals that you shouldn't have used.
>>Now with this great move to fortress we changed Composable to Serviceable and Recyclable
to Resettable. The first move (C-->S) has been done in a compatible way as we introduced
new abstract classes that replace the "composable" abstract classes with "serviceable" versions.
>>That's ok.
>>But, the move from Recyclable to Resettable has not been done in this way and will
break a lot of components! E.g. AbstractXMLProcuder has been changed from Recyclable to Resettable,
so every component inheriting from that one will break! That's bad.
>>I really think this move Recyclable to Resettable is nonsense. It has no advantage
(while Composable to Serviceable has). It's only this "we need to choose the correct name"
>>Now, Fortress must support Recyclable anyway - otherwise it'S not compatible to ECM
(I guess Fortress does so anyway), so I'm +1 on still using Recyclable. This is a) more painless
and b) more compatible.
>I never understood why Resettable was introduced in the first place, aren't its semantics
exactly the same as Recyclable? Why are Ressetable or Recyclable not part of the core framework?
Even if we move to Resettable now, nothing will insure that the next big container will not
introduce yet another interface for the same functionality.

The main difference between Resettable and Recyclable, beside the name, 
is that Recyclable extends Poolable. And with Fortress, being poolable 
is described by component meta information rather than harcoded in the 
component itself.

This is how I understand it. But what I don't understand, as Unico, is 
why Resettable is "hidden" in mpool (still somehow related to pooling) 
itself hidden in excalibur-event (??) and is not in the framework?

Now it's obvious that Recyclable *must* be supported, because *lots* of 
components rely on it.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message