avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: reduction ad unum
Date Sat, 23 Nov 2002 23:40:38 GMT


Darrell DeBoer wrote:

>>>From another branch of this thread:
>
>On Sun, 24 Nov 2002 00:35, Stephen McConnell wrote:
>  
>
>>In every single one of the examples you have provided above, the
>>extension of context is related to the exposure of a service.  Take the
>>"forwardMail" example and image we want to create a component that is
>>complete and container agnostic.  What we would do is declare that the
>>component in question has a dependency on a MailForwardingService. The
>>contract says nothing about where the service comes from (could be the
>>result of assembly, could be the result of a facility supplied by a
>>custom container).  The point is that using *existing* Avalon Framework
>>contracts - this sort of dependency can be expressed providing we have a
>>consistent component model. Combine this with standard context entries
>>(avalon:home, avalon:work, etc) and the whole requirement for context
>>specialization disappears - or is at least pushed out into relatively
>>closed environments where component reuse outside of a particular
>>technical domain is of no interest.
>>    
>>
>
>(I've replied to this in-thread.) 
>I believe this solution is superior to extending the concept of a Context. 
>
>If we can limit the use of "Context" to a very small set of standard entries, 
>and use the regular service-dependency mechanism for anything that might be 
>remotely container-specific, we avoid making this more complicated than it 
>has to be.
>
>To be honest, I'm not sure we'd lose much by ridding ourselves of 
>Contextualizable altogether - maybe make Context just another service (the 
>GenericUntypedHashMapThatMayJustHaveWhatYoureLookingForButWeCantGuaranteeIt 
>service ;).
>  
>

You lose an important difference.  Service, provided as a result of 
component depedencies, are not regular objects - they are handled 
through a lifecycle, represent a version interface, are suplied by a 
version implementation componet, etc.  A context entry on the otherhand 
is something native - an instance of java.io.File, a java.lang.String, a 
java.lang.ClassLoader, etc.  These native artifacs are not services, 
they are native langauge resources that fall outside of the notion of a 
service per. se.

Context is good and effective for those little things.
Context becomes painful when extended to provide more than this.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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