Peter Royal wrote:
> 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.
Absolutely. Just extend the AbstractContainer like DefaultContainer
does.
>>> 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.
right.
>> 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
Unfortunately it is not easy to change now.
--
"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]
