avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject RE: [proposal] avalon 5 ComponentManager interface
Date Tue, 11 Jun 2002 14:34:00 GMT
> > Berin Loritsch wrote:
> > 
> > >>From: Stephen McConnell [mailto:mcconnell@osm.net]
> > >>
> > >>Leo Sutic wrote:
> > >>
> > >>>The need for hints exist because we have decided that the 
> > role should 
> > >>>be an interface name.
> > >>>
> > >>Slowdown here - can anyone/someone please refer me to any Avalon
> > >>framework documentation anywhere that states a role is an interface 
> > >>name?  Please - let's not get mixed up between decisions 
> > >>concerning ECM. 
> > >> The CM/SM is not and does not inherit from ECM.
> > >
> > >It's a decision we came to a long time ago.
> > >
> > -1
> > 
> > The "decision" is not documented in the CM/SM interfaces - is not 
> > enforced by anything in the framework least of all 
> > DefaultComponentManager or DefaultServiceManager.  But the 
> > worst thing 
> > of all is that implies the potential interpritation of the 
> > lookup key on 
> > a CM/SM manager implemetation. The decision I accept is the decision 
> > expressed by the CM/SM interfaces and the javadoc that goes with them.
> Steve, with all do respect, I do not know what your "-1" is supposed
> to signify.  The fact that it isn't properly represented in the javadocs
> documentation doesn't negate the fact that historically the team came
> to that conclusion.  It does not negate the fact that it was the
> tradition
> imposed by Federico, who convinced both Peter and I (no small feat I
> might
> add) that it was the best way.

It is a tradition, a recommendation, and a "best practice". It is _not_
a requirment.

JDBC specifies a JDBC url starts with "jdbc:", then recommends you
follow with "drivervendor:host:port:database:{settings}". It will still
work if you do it differently, and that's cool.

> enforces the role abstraction.  The important thing is that the Role is
> tightly coupled to its interface--and as such the lookup name should be
> the Role's interface name.

The important thing is that the Role is tightly coupled to its
interface--and as such the lookup name should be tightly coupled to the
Role's interface name.

important difference.

We could tighten this to the lookup name should start with the results
of getClass().toString() called on the role interface, minus the
starting "interface ".

> The decision stems from the best way to have a unique name for a role,
> without being subject to naming clashes.  It would be really bad and
> incorrect if I received a component implementing
> "com.infoplanning.Store"
> when I really wanted something implementing
> "org.apache.excalibur.Store".
> If the role name in the CM was simply "Store", which one should the
> container
> return?  Under which circumstances should it return the
> "com.infoplanning"
> version and which circumstances should it return the
> "org.apache.excalibur"
> version?

this is determined by the combination of container programmer (design
time) and assembler (initialization time) (just to answer the question
for those that might not know the answer).

In the case of phoenix, it depends on the xml configuration files fed
into it by the assembler.

> Would you rather set up an authority to come up with id's like ICANN?

ugh. The thing both sun and w3 figured out is that basing yourself on
ICANN id's is the only way to fly =)

You forget the other alternative allowed (regardless of whether this is
by code or contract) is for framework users to be their own authority.

final note: coupling role name to interface only gives as much namespace
clash avoidance as the java namespace mechanism, which still depends on
trust (unless you use signed jars). I'd suggest not trying making it
more solid.

- Leo, who always follows "best practice" in his own projects

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