avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [A5] CM Use Cases from real requirements
Date Wed, 19 Jun 2002 00:30:48 GMT
On Tue, 18 Jun 2002 22:36, Berin Loritsch wrote:
> > I belive this use case is an abuse of the CM.  The CM is a
> > utility supporting interaction between the container and the
> > component.  In this context the inteface information is
> > redundant if the container provides support for metadata.  If
> > not, the passing of string that is not opaque is a workaround
> > to support either a container or component deficiency.  This
> > simple case can be easily support by seperating the usage of
> > a lookup interface for commonent aquistion as opposed to
> > component lifecycle servicing.
>
> Stephen, this is the core use case.
>
> lookup(MyComponent.ROLE);
>
> Nothing more.  Read into what you want, but I am talking about
> how it is used NOW.

You mean you use a container that sucks and as a result you have certain 
preconceived notions and refuse to listen to any one else.

Gee - thats never happened before ;)

> Sometimes I get the feeling you don't pay attention.

I know you don't. Stephen has not been talking about outlawing optional 
components.

> Now that we have taken the junior developer tack, now try explaining
> that to an administrator who wants to override the default mappings
> of component implementations to something different.

You don't need to exlpain it to them if you use a smart container alal Merlin.

> Also, as you have repeatedly demonstrated that while it is not necessary
> to bind the same role name for all components, it is definitely harder
> to follow when you are maintaining your components if one component
> calls
> the SSL ConnectionManager "ConnectionManager.ROLE/SSL" and another calls
> it "ssl-connection".  Consistency is very important in maintenance.

And whats the price of fish on Sundays?

> > I think this is a seperate concern - it can be handled by a registry
> > interface that can expose lookup( role, hint, whatever)
> > semantics but is
> > independent of a CM lookup.
>
> How do you really propose to choose the correct Transformer?  The
> container (in this case) is also a component responsible for resolving
> a request.  The rules for a particular component can require five or
> more different types of transformers.
>
> The important thing is that the component/container needs to resolve
> the correct transformer for the particular stage in the pipeline.

So let the container do it. It aint rocket science.

> > Bottom line - this is easily correctable without modifying the CM/SM
> > lookup signature.
>
> Outline a proposal.  Please, enlighten us.

Why would he bother. I have outlined several solutions to this problem - none 
of the posts got responses or have even been read it seems. Funnily enough 
Leo has also posted much same solution but does not see it. Anyways to 
reiterate;

On ComponentSeletor
-------------------
Then: 
 * (Cocooners): The sky will fall if we dont have it
 * Me: Crappy unscalable, unmaintainable solution
Now:
 * All: Crappy unscalable, unmaintainable solution

On release()
------------
Then: 
 * (Cocooners): The sky will fall if we dont have it
 * Me: Crappy unscalable, unmaintainable solution
Now:
 * All: Crappy unscalable, unmaintainable solution

On MetaInfo stored in code (Component, ThreadSafe etc)
------------------------------------------------------
Then: 
 * (Cocooners): The sky will fall if we dont have it
 * Me: Crappy unscalable, unmaintainable solution
Now:
 * All: Crappy unscalable, unmaintainable solution

See a pattern?

Anyways I am done trying to convince you that some of your choices are dumbass 
choices leading to pain in future because you wont listen to me anyways ;)

Just a little to think about though. If you try to force others to adopt your 
design decisions or foist non-framework stuff for A5 then there will be 
blocking or forking. 

Anyways return to your scheduled discussion as I can see real progress is 
being made now ;)

-- 
Cheers,

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>


Mime
View raw message