cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Getting rid of deprecated Interfaces/Classes/Methods
Date Mon, 30 Sep 2002 13:28:11 GMT
Stephen McConnell wrote:
> 

<snip/>

>>
>> which can be ported to:
>>
>>     public void service( ServiceManager manager )
>>     {
>>            if( this.mainManager == null )
>>            {
>>             this.mainManager = manager;
>>            }
>>         this.manager = manager;
>>     }
>>  
>>
> 
> This is the correct approach.
> 
> When preparing the service package I excluded the Recomposable notion on 
> the grounds that (a) it was insufficiently documented and insufficiently 
> understood at the time, and (b) in terms of an interface - you can do 
> exactly what you propose above - i.e. re-apply an invocation of service( 
> manager ).
> 

That is a distinct break from the Composable contracts.  One of the main
reasons that the Recomposable interface was originally introduced (i.e.
back in the A3.0 days) was because you needed a different contract.
Composable was purely a creation-time contract.  Recomposable was a
run/use-time contract.  I think it is fundamentally wrong to mix the
two.

It is true, though--Recomposable was not very well thought out as far
as implications go.  Essentially, we would need to proxy *every*
component looked up to ensure none of the re*** interfaces were exposed.
It imposes a security risk where a peer component can look up your
one component, and reassign the ComponentManager at will.  That is
*bad*.


-- 

"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


Mime
View raw message