cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Getting rid of deprecated Interfaces/Classes/Methods
Date Tue, 24 Sep 2002 13:47:40 GMT
Carsten Ziegeler wrote:

>Thanks for clarification, Berin! Inline are some comments:
>Berin Loritsch wrote:
>>>What does this mean in terms of compatibility and a stable Cocoon? Are
>>>written components using a CM with Composable and Component still working?
>>>I think noone will recode all the components he has written so far. But
>>>I guess that this is covered.
>>Fortress has a DefaultContainer that fits the best for Cocoon.  In fact,
>>Cocoon can extend the DefaultContainer and add in any missing pieces it
>>needs to get the job done.
>>In its current state, any Composable component will be able to access
>>any service (i.e. generic Object) due to the wonderful dynamic proxy
>>mechanism of JDK 1.3.  As long as you are using JDK 1.3+ everything will
>>work fine.
>Ah, ok - so he should shift to JDK 1.3 - this would solve some other
>problems in Cocoon as well.

But will unfortunately make it more difficult to port to less featured 
platforms (teasing : see the abstract of my talk at outerthought's 

>>Fortress is moving toward a MetaInfo enabled component matching system,
>>but that is done in a separate container.  You will be able to take
>>advantage of that when it is done.  Also, Fortress has a "big jar" that
>>includes all the Excalibur dependencies in one JAR file.

IIRC (didn't follow closely Avalon for some time), this meta-info is 
stored in a resource file near the component's class. IMHO, this will 
certainly seem complicated to average users that simply want to add an 
action or a generator. Also, using a doclet adds an extra step in the 
build process that doesn't make it much less complicated.

>>>So the remaining question is, is fortress/merlin stable and usable?
>>>If these both points can be answered positiv, I would say: +1.
>>Fortress is useable (others have used it without problem.  Development
>>is still continuing on it, however it is being done in such a way as
>>to not cause problems with existing users.
>>The biggest thing you will have to do to migrate to Fortress is to
>>change your cocoon.roles file format.  It is the roles file that now
>>determines the "lifestyle" of a component, and the marker interfaces
>>SingleThreaded, ThreadSafe, and Poolable do not have any meaning any
>Argh...sorry, I don't want to question this, but I simply do not like
>it. What will happen if I write a "SingleThreaded" implementation and
>configure it as ThreadSafe...

Same feeling : implementing a marker interface seems to me more 
intuitive and straightforward that writing a meta-info file.

>>Your Poolable components would have to change because Fortress uses
>>the MPool package (part of the Event package).  The Poolable and
>>Resettable interfaces are not there.  I do need to provide a mechanism
>>for the MPool package so that we can reset components.
>Do you mean Resettable or Recyclable?
>>One of the nice things is that Cocoon will be able to handle more
>>load using Fortress.  There is a profiling testcase that compares the
>>pure lookup/release cycles for Fortress vs. ExcaliburComponentManager,
>>and Fortress comes out ahead 15:1 (or more).  The higher the load,
>>the better Fortress does.  That figure even includes the proxied
>>ComponentManager implementation.
>>My question for you guys is whether you want me to force you to change
>>your interface for Resettable, or to have MPool work by reflection and
>>discover if there is a reset() method with public access.  If that is
>>the case, then MPool would be able to call it--whether there was an
>>interface or not.  I think the latter would be preferable, as it is
>>much more flexible--I just need to make it explicit that is what is

Using reflexion hides Java's strong typing and makes mechanisms using it 
obscure or semi-magical. It also makes life more difficult to automated 
bytecode processing tools (still the port on small platforms). All this 
makes me prefer a Resettable interface.

Last note (I know, it may be late for it now), the name of the service() 
method of the Serviceable interface doesn't seems well chosen to me. 
This name is more suited for a method that asks the component to perform 
its job, like in Servlet.service() than a method that gives a component 
the means to link itself to other components or services. "compose" was 
good (a system is composed of services) and having 
compose(ServiceManager) doesn't conflict with compose(ComponentManager).

Sorry for not being very constructive, but the power brought by the new 
container infrastructure seems to me somehow hidden by the additional 
constraints or annoyances it brings to the developper.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message