avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Aaron Farr <fa...@apache.org>
Subject Re: [proposal] say no to ROLE (was Re: Re: Roles and Components in Merlin...)
Date Sat, 17 Jan 2004 15:35:52 GMT
On Sat, 2004-01-17 at 20:00, Stephen McConnell wrote:

> > What do you mean by "say no"?  Are we going to change all excalibur
> > components which have it?  
> 
> That's not an option so long as there are ECM users out there. But 
> "saying no" can be interpreted as deprecating the usage pattern.

Yep.  And that was partly what I wanted to point out.

> > Are we going to put disclaimers in the
> > documentation that say "don't do it this way"?  Or modify all
> > documentation?
> 
> I think we need to purge the notion from the documentation.

I think that could be a good thing.  Especially if it is causing
confusion.

It's all part of the process of moving away from ECM and on to better
things.

> > The ROLE thing was really just a shorthand, a shortcut. In general it's
> > equivalent to MyService.class.getName(); or the fully qualified
> > classname of the service in question.  
> 
> But its not necessarily the same.  I remember a long time ago raising 
> the same subject and it was explained to me that the string returned by 
> ROLE need not be the same as the interface classname. Anyway, I've never 
> managed to get a clean computationally answer on the ROLE question.

A computationally correct definition of ROLE?  Don't think it exists. 
Or I should say, it probably existed in ECM days, but is slightly out of
place now.  I'm certainly a +1 on cleaning up the semantics of ROLE and
other related lookup issues.  Consistency in these basic definitions is
something I think we're all looking for.  

I just wanted to make sure we all understand what "saying no" to ROLE
means.  If it means removing it from documentation and clearing up it's
use in existing code (ie- Excalibur), then I'm all for it.  If it means
removing it from the code or removing lookups via type or classname
(which is essentially what most uses of ROLE are) as opposed to alias,
then I have some concerns.

-- 
 jaaron  <http://jadetower.org>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message