Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3D9072A6.2080002@apache.org>
Date: Tue, 24 Sep 2002 10:11:50 -0400
From: Berin Loritsch <bloritsch@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Getting rid of deprecated Interfaces/Classes/Methods
References: <0109D6A3-CFC6-11D6-9C97-000393B61B56@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org