avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Fresh Perspective
Date Wed, 19 Jun 2002 15:49:26 GMT
> From: Leo Simons [mailto:leosimons@apache.org] 
> 
> On Wed, 2002-06-19 at 15:32, Berin Loritsch wrote:
> > Bear with me, because I am trying to sort out the details 
> of all our 
> > conversations with the CM/SM/CL talks and mapping components to the 
> > lookup interface.  What I hoped would happen didn't.  I 
> hoped I would 
> > see some intelligent conversation regarding the five use 
> cases as to 
> > how it would be solved with meta-info, N-dimensional lookup, etc. 
> > However, instead I received attack on the use cases not 
> matching the 
> > particular semantics that the champion of whatever approach didn't 
> > like.
> > 
> > The use cases represent *current* ways of using A4, and in order to 
> > ensure we maintain a user base, A5 has to make each of them more 
> > elegant or easier to use.  So, it looks like I have to do 
> your guy's 
> > homework for you.
> 
> there's some not so nice comments intertwined in the above as 
> well. Not very fresh. But alas, let us ignore all that.

Sorry, my frustrations came out because of people ignoring what
I said.


> > 2. Meta-Info Enabled Container
> > ------------------------------
> > The meta-info enabled container is what I am calling Stephen and 
> > Peter's proposal.  It is going down the correct path, but I 
> need some 
> > clarifications for my finite peanut brain.
> > 
> > 1. locator.lookup("my-component");
> > Essentially the same as A4 with two exceptions:
> > * the name of the lookup mechanism is more aptly named
> > * the name of the lookup key is determined by meta info
> 
> * the thing you look up is not a component, but something 
> satisfying a set of constraints

:/

The *purpose* of the ComponentLocator is to find components.  Whether
they are Avalon components, CORBA components, EJB components, or
some proprietary container's components doesn't matter.  You are
resolving
components.

If we want a lookup service for everything, then just use JNDI, that's
what it's there for.


> > As was pointed out, this is supposed to be more scalable than using 
> > the interface name.  The important thing to realize here is 
> that the 
> > scope of the name is local to the component doing the 
> requesting.  The 
> > remaining question it seems would be what if the client was not a 
> > component?  The arbitrary client has no meta-info 
> associated with it, 
> > so how does the container manage the name that is looked up?
> 
> this is left up to the container right now. Phoenix uses the 
> ROLE property if present, otherwise (I think) 
> class.getName(). Basically, the best path to take is to have 
> meta-info autogenerated as much as possible, if nonexistent.

Ok.  So in the case where the client is not a component (such as
a main() method, or a servlet), that client would default to the
current behavior of looking up the role name?


> > 4. locator.lookup("my-component/SSL");
> > The same mechanism that resolves the use-case #1 solves 
> this issue as 
> > well.  Perhaps I am dense, but I need a little push to help me 
> > understand how the container knows which implementation the 
> component 
> > wants.  The important thing here is _policy_ or _constraint_--not 
> > implementation.  It is more important that I have a 
> ConnectionManager 
> > component that represents SSL connections than I have the 
> one that is 
> > defined in Cornerstone.

<snip/>

Ok, I am going to examine what you wrote in detail.
It'll take a while.


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