Carsten Ziegeler wrote:
> Giacomo Pati wrote:
>
>>Hi Team
>>
>>I'll have some spare time this week and thought of moving the HEAD branch
>>away from deprecated stuff from newest Avalon Framework/Excalibur jars.
>>
>>My plan will be:
>>
>> 1. Get rid of Loggable in favor of LogEnabled
>> 2. Get rid of Component and move to Service infrastructure
>>
>>1. is straight forward and doesn't need any voting I think
>>
>
> Yupp. +1
>
>
>>2. can be done in two steps:
>>
>> a. move from Component to Service infrastructure as the
>>ExcaliburComponentManager supports this.
>>
>> b. use Fortress/Merlin (don't know the status of those and which one
>>makes more sense for Cocoon to be used, so I need some advice of
>>Avalonians here)
>>
>
> 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.
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.
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.
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.
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
happening.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
