avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Tue, 03 Dec 2002 01:34:58 GMT
On Tue, 3 Dec 2002 11:46, Adam Murdoch wrote:
> Could someone explain why the distinction between resources provided by the
> container and resources not provided by the container is important *to the
> component* itself?  Why does it care?  And if it does, why is it useful
> that the component should use one mechanism for looking up one group of
> resources, and a different mechanism for looking up the others (and
> presumably separate mechanisms to describe to the container the resources
> it is expecting)? Ignore the fact that some resources are passive,
> immutable 'data' and other resources are active 'services' - that's a
> separate distinction.

Take this to it's logical end. Why use different mechanisms for looking up 
different types of resources in any component? ie Why do loggers have their 
own lifecycle interface? Could not you just look up the Logger this 
directory? Or why don't you just lookup the Configuration object in this 
directory? Is this not what JNDI is - so why not use that instead of our own 
mechanisms?

ie It would end up looking like

public void init( java.naming.Context ctx )
{
  //Replace ... with correct path according to J2EE recomendations
  m_logger = (Logger)ctx.lookup( "java: ... Logger" );
  m_configuration = (Configuration)ctx.lookup( "java: ... Configuration" );
  m_service = (MyService)ctx.lookup( "java: ... MyService" );
}

FWIW I believe this was the original apporach and it has gradually had the 
concerns separated. The reason for separation was based on usage patterns. ie 
The above seemed overly complex mechanism if you just wanted to get a logger 
or just wanted to get at configuration etc.

So we broke out things based on usage patterns. IIRC Configuration + Context 
were already separate when I started lurking in Avalon. Then someone (Fede?) 
broken out ServiceManager because that had a distinctive usage pattern. Later 
on LogEnabled and Parameterizable got separated out because they also had 
distinctive usage patterns. 

By breaking things down by how we use them makes it possible for more scalable 
design and we don't have any monolithic pieces. We can essentially mix and 
match to get what you want.

So why separate out container provided resources and peer provided resources? 
Mainly as they follow different usage patterns.

-- 
Cheers,

Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated 
beyond their intelligence."
-------------------------------------------------- 


--
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