avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Component Discovery and Resolution
Date Tue, 18 Mar 2003 07:50:27 GMT

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:


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 

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

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message