avalon-phoenix-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 10:52:22 GMT
oops - sent when I meant to save as draft and finish later ... I clarify now 

On Tue, 3 Dec 2002 21:45, Peter Donald wrote:
> On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> > 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?
> I don't really understand what you are getting at. If you are wanting to
> unify the interface then this has already proposed - I actually created
> another service API recently that looked something like
> interface Composable
> {
>   void compose( Locator locator ) throws LocatorException;
> }
> interface Contextualizable
> {
>   void contextualizable( Locator locator ) throws LocatorException;
> }
> interface Locator
> {
>   Object lookup( String key ) throws LocatorException;
>   boolean exists( String key );
> }
> If thats what you mean then I think I agree. It resulted in cleaner code.
> If you mean merging Contextualizable and Composable then I disagree.

And I disagree because they are logically different resources. 

Just like Logger or Configuration/Parameters or InstrumentationPoint resources 
could be all added into a central directory and got in one sweep - we 
separate out purely because of different usage patterns. 

90% of generic component based apps will not use Contextualizable. Almost 100% 
of typed/container-bound objects (ie Tasks, Mailets, Servlets, EJBs) 
conceptually use Contextualizable. 

Even in Servlets the service provision (JNDI) and interaction with container 
(ServletContext) are logically different access mechanisms and have different 
usage patterns. ie I rarely use JNDI except when writing EJBs yet I use 
ServletContext in every servlet app I write.


Peter Donald
The two secrets to success:
   1- Don't tell anyone everything.

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

View raw message