Berin Loritsch wrote:
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.
Ok. I know in phoenix the assembly file is used to make the config file instance based and not type based.
Every time I have a different config/instance of a ShowScreenCmd, I want the config file to represent that type by
<show-screen id="comp.name"/>
If that is your @avalon:type.name then I can use that instead.
@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).
That's fine. I would like someone who knows Phoenix to tell me how they implement it. That way we can come to an agreement.
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.
In fortress there is *no* equivalent. EIther your container controls it or it doesn't. I have never seen a case where a *real* singleton is needed (of course I have never done IO driver work either).
AKA pooled
Nope. Pooled objects are recycled to a pool following release. Transient objects are disposed of on release.
Point being that transient components are not preferred. Pooling should be used in preference if there is no other option.
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.
It also has @avalon attributes (check the metagenerate task)
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.
Fortress has *VERY* simple needs. I want to keep the CORE/minimal set just that--minimal. As containers provide more services for their components, they respond to more attributes.
What we probably need is a a standard set of compliance layers.
Management ---------- Validation ---------- CORE
By the layer diagram above, you can see that there are a minimum set of attributs, a set that allows for component validation (a service provided by Merlin and Phoenix), and a set that allows for remote management (Phoenix's JMX integration).
Attributes that are not supported by a container are simply ignored, and the component needs to be OK with that.
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>
All I need is @avalon:info.name <name> (i.e. @avalon.configname)
@avalon:context <string> @avalon.context.attribute <key> <value> @avalon:context.entry <key> <type> [optional]
I don't need any of these (context validation set)
@avalon:services.attribute <key> <value> @avalon:service [tag] <type> @avalon:service.<tag>.attribute <type>
The only one I need is @avalon:service [tag] I'm not too sure on what the others buy me, and will look into it later.
@avalon:dependencies.attribute <akey> <avalue> @avalon:dependency <key> <type> @avalon:dependency.<key>.attribute <akey> <avalue>
I don't need any of these (dependency validation set)
@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>
Fortress isn't going this route yet.
I wouldn't put it in the Avalon namespace. I would put it in the @lifecycle: namespace because it has to do with Excalibur Lifecycle.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
