Farr, Aaron wrote:
-----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.
Merlin does not support the selector semantics.
Also, doesn't merlin support a particular lookup scheme for components located in nested containers?
Merlin provides the ability to lookup components using URLs.
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?
Ouch - no thanks!
The alias attribute is nice and clean and I want to keep it that way! It provides the mechanism to map standard keys to legacy keys (e.g. this is part of how Merlin delivery runtime support for Phoenix components - but declaring aliases for phoenix terms against standard context keys).
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?
Yes.
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.
The are all declaration of depedencies. Your completely correct.
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).
You can declare a service defintion and package in the namespace of the external service (the only limitation is that you have to create this definion manually).
Just for reference, Merlin allows directories in the classloader classpath statement. When a directory is encountered Merlin will recursively scan sub-directories for type and service definitions. I.e. your not locked into content bundled in a jar file.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
