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 gettogether). >>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. >> >> >> >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... > > 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. >> >> >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. >> 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 -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
