avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Re: [proposal] say no to ROLE (was Re: Re: Roles and Components in Merlin...)
Date Sat, 17 Jan 2004 21:36:26 GMT
Aaron,

> 
> From: J Aaron Farr <farra@apache.org>
> Date: 2004/01/17 Sat AM 08:48:04 EST
> To: Avalon Developers List <dev@avalon.apache.org>
> Subject: Re: [proposal] say no to ROLE (was Re: Re: Roles and Components in
> 	Merlin...)
> 
> On Sat, 2004-01-17 at 17:40, Alex Karasulu wrote:
> > Sorry dude thought I had the dev list there.  
> > ALex
> 
> No problem.
> 
> I have a couple questions though. 
> 
> What do you mean by "say no"?  Are we going to change all excalibur
> components which have it?  Are we going to put disclaimers in the
> documentation that say "don't do it this way"?  Or modify all
> documentation?

First I would get rid of any reference in the existing docs which 
recommends using it.  I don't think the new docs have many references
to this vestigial pattern.  But if we come across it we should 
make sure people understand that it is not necessary (for the containers)
concerned.  Basically ROLE is only a requirement where the container
is concerned because it is an aspect of the implementation for looking
up services.   The framework's support for this aspect as you said comes
from the ServiceManager interface.  So we ought to make sure ROLE is no
where in the framework documentation first and second in any other docs
unless absolutely required for that implementation.  Then in that case
ROLE becomes an implementation specific pattern.  Not a Avalon wide pattern.

The old containers that use it can still require it.  But as far as any
further development is concerned we can tell all Avalon users that they
no longer need to have ROLE defined within their service interfaces.

> 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.  This was perhaps more important
> in the ECM days, but in all three modern containers, the service name
> can be just about anything.  If you're client component doesn't really
> care which implementation of a service it gets, using the service
> classname seems like a reasonable solution.  It says to the container,
> "Look, just get me an implementation of this service."
> 
> Also, it's one thing to get rid of the ROLE constant and just tell
> people to use MyService.class.getName().  It's another to suggest that
> the semantics for ServiceManager lookup need revised (they do, but it's
> a whole different issue) [1].

Who are these people u refer too? I'm thinkin your talking about
the container developer and not the component developer that uses
the ServiceManager for lookup.  If that is the case then I agree.
If not I think I'm a bit lost cuz I never really used the ROLE thingy
when I've wore the component developer hat.

> Don't want to cause any commotion, just want some clarification.

No worries dude.  We're just casually discussing this - at least that's
what I'm doing.

Alex



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


Mime
View raw message