> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
>
> As you can see, there are only a couple of ways that would be widely used.
> Phoenix ignores the ServiceSelector contract--even though it is in
> Framework.
> I believe Merlin supports the ServiceSelector, but I am not sure so I will
> leave it to Stephen to tell us more authoritatively.
Also, doesn't merlin support a particular lookup scheme for components
located in nested containers?
> In the end, I would like a way that works easily without having to think
> too
> hard. I have come to appreciate the simplicity of simple name/value
> mapping,
> as long as there is a way to influence that mapping.
+1 for simplicity
> > Probably step in the right direction; however, I think I (and other
> users)
> > will get 'role' and 'type' mixed up.
>
> Hmm. That is a problem. Perhaps we simply need to add these semantics to
> the "alias" attribute?
The WIKI proposal states this:
@avalon.dependency
type=(ROLE|value)
[version=(version)]
[key=(value)]
[optional=(true|false)]
So isn't the 'role' attribute you mentioned really just the 'key' attribute?
Personally, I prefer something more like 'service' than 'type' and either
'key','alias', or just 'name' works for the other.
Also, not to start a flame war or anything, but isn't 'avalon.dependency'
just as much a 'validation' issue as context, logging, and configuration
tags? I mean, it's just the container validating that such services exist
and allowing the component to access them. I don't see the difference
between this and say 'context'. But perhaps I'm wrong.
While I'm at it, here's a questions about 'avalon.service': What about
services in which the interface is defined by a third party, (ie- Sun)? The
interface may not originally been intended to be an Avalon service, but that
doesn't mean it can be used as such. In this case, you can't use AMTAGS, so
however meta-info is gathered by the container, it should be in a way that's
fairly easy to configure. Currently, it's difficult to pull this off in
Phoenix and Merlin since they expect meta-info embedded in the jar files
(for Fortress you can use a ROLE's file).
Of course, you can always create wrapper interfaces that extend the third
party ones you're interested in, but it'd be nice if that were not
necessary. This is more a 'meta-info' issue than a specific AMTAGS issue.
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
