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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
