cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Getting rid of deprecated Interfaces/Classes/Methods
Date Tue, 24 Sep 2002 13:04:59 GMT
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.

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

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

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

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

We need a way to invoke the recycle() method in the current implementations,
so a support for Recyclable is required.

Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message