avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <adammurd...@apache.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Tue, 03 Dec 2002 10:17:59 GMT
On Tue, 3 Dec 2002 03:42 pm, Peter Donald wrote:
> On Tue, 3 Dec 2002 13:17, Adam Murdoch wrote:
> > Hence my question:  Does the component *really* care whether a particular
> > resource is provided by the container or not provided by the container? 
> > Is this an artificial distinction?  Why is it useful to the component
> > writer to split them?
>
> Essentially it comes down to the context wrt the resources is requested.
> For example lets consider Logger. Historically we had LogManager as a
> service that components depended on to get at their logger. So it would
> look something like;
>
> class MyComponent
> {
>  void service( ServiceManager sm )
>  {
>    LoggerManager lm = (LoggerManager)sm.lookup( LoggerManager.ROLE );
>    m_logger = lm.getLogger( "my-channel" );
>  }
> }
>
> In this case you are passing component specific context (ie string
> "my-channel") into LoggerManager. Now if you wanted two different instances
> of MyComponent - say one production and one testing - they would both log
> to the same channel or we would have to create multiple instances of
> LoggerManager.
>
> However when the container manages allocation of Logger resource they can
> be remapped without the Component writer knowing about it or caring.
>
> Everything available in the context can either be made into a service or
> blended into configuration or both. The problem is that when the resource
> (data or service) requires per-component context you end up having a "fake"
> provider component per component. So assembly requires mapping of several
> "fake" components to the dependencies in the "real" components (ie the ones
> you actually care about). You also end up duplicating data between
> different stages. ie assembly process names components and links them to
> resources resources and those same names need to placed in configuration of
> "fake" provider components.

Sure.  These are good examples of why everyone wins when there's a nice match 
between what a resource means to a component, and how the resource is 
delivered to the component.  If the component wants a logger, give it a 
logger.  If the component wants config, give it config.  etc.  Maybe the same 
resource is presented in different ways depending on how the component asks 
for it.  Maybe not.  Component doesn't care.

But the examples don't really answer the question:  Why is it useful, when a 
component asks for a resource of a particular type, to distinguish between 
resources of that type that are provided by the container, and resources of 
that type that are provided by other components?

(where 'type' = config, or parameter, or data, or service, or whatever).

-- 
Adam

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message