Re: Component Discovery and Resolution

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