avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [ISSUE] containerkit
Date Wed, 03 Jul 2002 17:02:57 GMT

> From: Peter Donald [mailto:peter@apache.org] 
> On Wed, 3 Jul 2002 09:57, Stephen McConnell wrote:
> > Peter Donald wrote:
> > >On Wed, 3 Jul 2002 02:01, Leo Sutic wrote:
> > >>My point is that if the context is only constants that
> > >>are entered by an assembler (a person), then it is not different 
> > >>from a Configuration.
> > >
> > >Bingo!
> >
> > Read the rest of the thread.
> I have. Same conclusion. 
> But I am sure it is vital and the sky will fall if we dont 
> adopt Merlins 
> approach. Just like the sky fell would have falled if we 
> hadn't have adopted 
> ComponentSelector. 


I don't understand what the problem is and exactly what it is you are

I'll try to outline the point I see us being at, and I ask you to
tell me what is wrong.

Somewhere you should document what a component needs to run - for
dependencies on services and so on. If for no other reason than that the

assembler should be able to check if the component will even run in the 
container without having to try starting it. In that document you should

be able to specify what context it requires.

So if we use two constraints:

 + What interfaces the Context must implement (that is, to what
   other type can you cast the aquired Context interface).

 + What values must it have (that is, what are the keys to the
   get() method), and what should the type of those values be.

That's it as far as constraints are concerned. This we can standardize.

Now for Stephen's method of populating the Context via application 
profile, we can make that container specific.

I'll try to argue for Stephen's approach (the following being container
specific and not part of the component xinfo):

 + Being able to remap context entries from the container's namespace
   to the component's is good. Just like we needed to remap roles,
   this will avoid namespace collisions.

 + Being able to provide constant values via a config file is open
   to abuse, but I can see it being useful at times.

 + The two features above can help the assembler resolve the second
   of the two constraints I listed at the top of the email. Now,
   what if the context received can not be cast to the required
   interface, but it is possible to put in an adapter? Therefore,
   it should be possible to specify a context adapter class.

In summary: I don't think there's a problem with the constraint spec,
as it allows one to describe all the possible uses of a Context that
I have seen so far.

For the container-specific parts (the container-specific configuration
for the component), that will not affect any current usage of the
Context, and need not be implemented.


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