On Tuesday, September 24, 2002, at 09:47 AM, Sylvain Wallez wrote: > Carsten Ziegeler wrote: >> Berin Loritsch wrote: >>> 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.
You are not required to have the "meta-info as separate XML documents" to use fortress. It is an optional feature, one that is mainly designed to help with component portability between Avalon containers (and a non-issue for actions or generators as they are cocoon-specific components). The meta-info issue that Cocoon will face is where to store the lifestyle of a sitemap component. It used to be the marker interface, but those are gone. Fortress currently stores that information in the roles file, but we don't want to require Cocoon users to add all sitemap component metainfo to a roles file either. I believe it will be possible to create a custom Fortress container that still obeys the lifestyle interfaces though. >> 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. Agreed. However I *do* find it easier to specify the lifestyle in the roles document for container components (I have been guilty of forgetting to add ThreadSafe to components and dealing with the pain of having it be SingleThreaded by default). As mentioned above, you won't have to deal with meta-info files for Cocoon. Cocoon.roles can stay with a single added parameter per component of what lifestyle to use. > 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). Interesting suggestion :) I believe it was changed to prevent confusion with the old method name. I do agree that the name service() is not as "intuitive" to the function performed as compose() was. You aren't the first to bring this up since the change happened. -pete -- peter royal -> [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
