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 Mon, 25 Nov 2002 15:41:39 GMT


Daniel Krieg wrote:

>>...there are two side to component-oriented-development (a) the component,
>>    
>>
>and (b)
>  
>
>>the container - and its really import to appreciate the potential of
>>isolating these two concerns - because it enables the delivery of
>>portable components, by leveraging a containment solution.
>>
>>Specalizing a container does not mean lost of Avalon container - its
>>about having a container side programming model that makes the above a
>>drop-dead simple proposition.
>>    
>>
>This is a very important point, I think.  If I write an Avalon-based
>component, I must choose a container for that component to execute 
>within.  Certain components may be so generic that all 
>container-implementations should be able host it, while other components 
>are dependent on a specific container.  This is not undesireable.  Take 
>for instance the differences between J2EE Servlet vs. EJB.
>Both are components that are hosted within a Container, yet address 
>entirely different needs.  We could have Avalon containers of similar 
>scope.
>
>I think that when defining heirarchical containers, there is a need to
>also define heirarchical Context objects.  The Uber-container may only
>provide simple-objects, where as the TimeStampContainer might provide
>the TimeStamp, not as a service, but as an object accessible from
>TimeStampContext, since the TimeStamp is so closely aligned with
>aspects addressed by the TimeStampContainer.
>

Hi Daniel:

I would go one step further and qualify the concept of 
TimeStampContainer by saying that this can be a standard container 
configured to use a TimeStampContextProvider during the cestext 
resolution stage that a container executes.  

I think this sort of thing will arrive with the introduction of 
different context management solutions - and from there we can imagine a 
standard approach to a context management services.  In this example, an 
implemetation of a context manager that understands how to establish a 
TimeStamp instance from a TimeStampService, accessible by a container 
over a context management interface, enabling a container to get the 
TimeStamp instance from the manager at the time of component deployment.  

This means that neither the container nor component are linked to the 
TimeStampService.    

If all of this sounds a bit fuzzy - its because I'm thinking out-load.

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