Berin Loritsch wrote:
Stephen McConnell wrote:
@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.
I understand, and can make it happen that way. However I *really* don't like instance based short names. An XML element should stand for the same implementation all the time. It makes it really simple to understand.
The main thing I need to confirm is if the configname value is a name statically bound to a component implementation class? If yes - then where you describing as @avalon.configname is equivalent to what I'm describing as @avalon:info.name.
In Merlin this appears in the .xinfo file as:
<type>
<info>
<name>some-name</name>
</info>
</type>For the moment I just confirm that we are talking about the same thing.
@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.
We currently have no standard on this. I would like to push toward a standard--without forcing implementation types.
Which is why your more focussed on "policy" names as opposed to "mechanisms" - makes sence. More notes below - more thinking needed (at least by me).
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
Correction: unique across a container.
No. I'll be more explict. A singleton policy (in Merlin) results in the establishment of a single service provider that is shared across all consumers within the scope of the classloader within which it is published.
thread - unique per thread transient - unique per request
AKA pooled
Nope. Pooled objects are recycled to a pool following release. Transient objects are disposed of on release.
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:
Keys to data *types* which is much more clear.
@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.
Yes, but we need a dictionary of keys that our users can build upon. I would like to get the minimal set done now--which ignores validation arbitrary attributes and version info. Just enough to tell the container what is available.
Sure - agreed.
I just included the subset related the <info> block as an example of the bigger picture.
You see, merlin and phoenix seem to have their own set of naming conventions. I would really prefer if our users don't have to do a global replace on all the attribute names when they upgrad from Fortress to Merlin or Merlin to Phoenix.
They won't - keep in mind that the attributes that exist in the Phoenix sources (@phoenix) deal with the <blockinfo> meta descriptors. You run an an task over the sources and pump out a blockinfo file containing the phoneix specific xinfo XML. When moving to a generic model your going to end up with different attributes because there will be things you will need to describe that are not within the existing blockinfo descriptor. This means a different generation tool that may support one or more output DTDs. For example you could image a tool that generates an a common descriptor from which native descriptors could be geenrated automatically.
But this does mean being aware of the big picture before starting on "standard" attributes for meta generation.
Keep in mind that Phoenix has been doing the attributes the longest, so I would tend toward using their conventions.
It's not as easy as that. At the end of the day (and well after a Fortress release) the objective is a complete attribute declaration spec. I don't believe that this will come together without working though the meta requirements on a step-by-step basis. For example, Leo is/was close to this with respect to the discussions on the Context interface. Continuing that process enables reolution of a context descriptor DTD and from that - you have the requirements we have to meet relative to tags in source files. Phoenix work will certainly contribute - but it is a subset of the complete picture. The end result will be considation and rationalization of requirements across Fortress, Merlin and Phoenix.
Maybe it would not be a bad idea to look briefly at what the big picture looks like before standardizing anything at the avalon level. Work I've been doing is hading in the following direction:
@avalon:info.name <name> @avalon:info.version <version> @avalon:info.attribute <key> <value>
@avalon:context <string> @avalon.context.attribute <key> <value> @avalon:context.entry <key> <type> [optional]
@avalon:services.attribute <key> <value> @avalon:service [tag] <type> @avalon:service.<tag>.attribute <type>
@avalon:dependencies.attribute <akey> <avalue> @avalon:dependency <key> <type> @avalon:dependency.<key>.attribute <akey> <avalue>
@avalon:stages.attribute <akey> <avalue> @avalon:stage [tag] <type> @avalon:stage.<tag>.attribute <akey> <avalue>
@avalon:extensions.attribute <akey> <avalue> @avalon:extension [tag] <type> @avalon:extension.<tag>.attribute <akey> <avalue>
Due to complaints about length emails from your's truly I'm not going to explain all of the above - its just an example of the scope of information that a big picture scenaio may need to cover. Just for reference, there are additional tags that would be needed to handle Phoenix that are not listed above.
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]
