Berin Loritsch wrote:
I am finally happy with the way GUIApp automatically finds and resolves components. I think this functionality can be backported to Fortress prior to the official 1.0 release.
It sits in between ECM's braindead simplicity and the niceties of Merlin and Phoenix. I have a couple of ant tasks to collect all the services and their components. While there are some refinements that can happen with the ant tasks, I think this provides a nice bridge to introducing folks to a more powerful system.
The crux is this:
All our roles (AKA services) will be tagged with an @avalon.service interface. The ANT task records all services in a services.list file at the root of every jar that defines new component types.
All our components have an @avalon.component attribute, and a couple others. The component meta information is fairly simply addressed for FOrtress:
@avalon.configname Maps to the shorthand name we use in our configuration files.
I think this is Fortress specific. Phoneix resolves configuration fragments based on block names in the assembly file. Merlin resolves configurations at multiple levels (type, profile, and block). However, see notes towards the end of the reply.
@avalon.scope Maps to a set of constants ("container", "thread", or "request") to represent the type of lifestyle it must support.
I'm a little confused on this one - if we are talking about lifestyle then should this not be something like [singleton|thread|pool|transient] (using Merlin terminology here). The [container|thread|request] set seems to be referring to something different.
Alternatively if you absolutely have to specify the handler by the long name, you can use the @fortress.handler attribute instead.
Ok - I getting the impression that we are talking about lifestyle in which case what is the correlation between Merlin and Fortress here? This is the Merlin summary:
singleton - unique across a virtual machine thread - unique per thread transient - unique per request pooled - a pooled lifestyle handler
In the absense of either of these attributes, they are determined by the class itself. It will revert to ECM behavior to respect the old interface based attributes--strictly for back compatibility. If there are absolutely no clues for the component, the ServiceRoleManager will assume the component is "thread" scoped. As to the shorthand name, that is done by splitting the words of the last portion of the class name using the following regular expression:
([A-Z]+)
The config name will be in all lowercase, with the word splits using a hyphen. For example:
XHTMLFormatter --> xhtmlformatter ThisIsCool --> this-is-cool
The really cool thing about this approach is that the same RoleManager can define *all* the roles and component implementations with *all* the hints in *all* the jars in the classloader. It rocks. For GUIApp it pays off because we can alter the core libraries at will, and add functionality as we move on.
This is definately specific to the Fortress/ECM notion of shorthand name mappings which are basically keys to data entries. If I understand correctly, the shorthand name is a equivalent to the name of the component (or in Merlin terms, the name assigned in type info declaration). If that's correct, the equivalent in Merlin type info structure looks like:
@avalon:info.name <name> @avalon:info.version <version> @avalon:info.attribute <key> <valaue>
Where avalon:info.name equates to Fortress/ECM shorthand name?
One other thing, in the background work I've been doing I'm using the URN convention of <domain>:<key> - i.e. "avalon:something.whatever.etc". The benefit here is that you can use the domain to establish a dictionary of keys.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
