Re: Component Discovery and Resolution

Stephen McConnell wrote:
> 
> 
> 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.