avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Containerkit and Merlin 2 descriptors: basically the same?
Date Wed, 28 Aug 2002 14:30:08 GMT


Nicola Ken Barozzi wrote:
> 
> Stephen McConnell wrote:
> 
>>
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> Stephen McConnell wrote:
>>>
>>>>
>>>>
>>>> Nicola Ken Barozzi wrote:
>>>>
>>>>> In Merlin Assembly there is an xinfo description
>>>>> http://jakarta.apache.org/avalon/merlin/assembly.html
>>>>>
>>>>> In ContainerKit we have a similar file in the examples.
>>>>>
>>>>> Now the differrences are trivial, here is the Merlin assembly type 
>>>>> xinfo compared to the containerkit example:
>>>>>
>>>>> -<type>
>>>>> +<component-info>
>>>>>   <component>
>>>>>     <name>my-component</name>
>>>>>     <version>1.2.1</version>
>>>>>     <attributes>
>>>>>        <attribute key="avalon:display-name-i18n" 
>>>>> value="display-name"/>
>>>>>        <attribute key="avalon:lifestyle" value="THREAD_SAFE"/>
>>>>>     </attributes>
>>>>>   </component>
>>>>> -  <loggers>
>>>>> -    <logger name="store"/>
>>>>> -    <logger name="store.cache"/>
>>>>> -    <logger name="verifier"/>
>>>>> -  </loggers>
>>>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>  (IMHO loggers should not be specified by the Component, it breaks 
>>>>> IOC)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> These are sub-categories relative to the supplied category.  It is 
>>>> the container's responsibility to handle this.  For example, you 
>>>> component may declare that is has a subcategory called "store".  In 
>>>> the container assembly information, the assembler may declare that 
>>>> the "store" category shall be assigned a priority of DEBUG.  The 
>>>> container can validate that assembler supplied logging priorities 
>>>> and targets relative to a category actually correspond to the 
>>>> categories it establishes for the component, and tegether with 
>>>> information from the type defintion, that the declaration are valid 
>>>> with respect to componet type sub-categories.
>>>
>>>
>>>
>>>
>>> Hmmm...
>>>
>>>     /**
>>>      * Create a new child logger.
>>>      * The name of the child logger is 
>>> [current-loggers-name].[passed-in-name]
>>>      * Throws <code>IllegalArgumentException</code> if name has an

>>> empty element name
>>>      *
>>>      * @param name the subname of this logger
>>>      * @return the new logger
>>>      */
>>>     Logger getChildLogger( String name );
>>>
>>> Ok, I understand.
>>>
>>> Make it then:
>>>
>>>  <child-loggers>
>>>    <child-logger name="store"/>
>>>    <child-logger name="store.cache"/>
>>>    <child-logger name="verifier"/>
>>>  </child-loggers>
>>
>>
>>
>> Personally I don't like using "-" in element names, how about:
>>
>>    <loggers>
>>      <subcategory name="xyz"/>
>>    </loggers>
>>
>> ?
> 
> 
> nope, a logger top element name is absolute in meaning, definately 
> misleading.
> 
> Since it's
> 
>     Logger getChildLogger( String name );
> 
> it means that it's about the loggers in the category child-loggers.
> 
> Since in Java the convention is for capitaliation, and in XML it's - 
> (see all the xml specs) translating;
> 
>   <child-loggers>
>     <logger name="store"/>
>     <logger name="store.cache"/>
>     <logger name="verifier"/>
>   </child-loggers>
> 
> You don't like names with - in it?
> Too bad, the world is full of them ;-D

I don;t like it but I can live with it!
;-)

> 
>>>
>>>>>
>>>>>   <context type="MyContextInterface">
>>>>>     <entry key="base" type="java.io.File"/>
>>>>>      <entry key="mode" type="java.lang.Object" optional="TRUE"/>
>>>>>   </context>
>>>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>  (This is consistent with what I've said, ie spacify the keys that 
>>>>> are not Avalon standard like the ones being discussed)
>>>>>
>>>>
>>>> Correct - its simply a statement of the contract that the componet 
>>>> expects the container to fulfill.  Within this information a 
>>>> component can cast in confidence.
>>>
>>>
>>>
>>>
>>> Ok.
>>>
>>>>
>>>>>   <services>
>>>>>       <service>
>>>>> -        <reference type="SimpleService" version="3.2">
>>>>> +        <service-ref type="SimpleService" version="3.2"/>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The only reason for the diference between "reference" as opposed to 
>>>> "service-ref" is that the Type DTD uses this for both service 
>>>> references and for extension references - both of which are version 
>>>> interface references.
>>>
>>>
>>> But an extension is a Service too.
>>
>>
>> Not in the way the work "service" is used.  A service is an object 
>> interface that can be mapped as a solution to another components 
>> service depedency declaration.
> 
> 
> Can't I use an extension as a Service for some reason?
> Anyway, it's not a structural problem.

Technically, an extension could be described as a service. Just based on 
immediate thoughts - it may be possible to include extension 
declarations as classic services provided by a component.  An 
implementation like Merlin could scan service declarations, maybe look 
for a standard attribute that declared the particular service as an 
extension.  This would negate the need to include the <extensions/> 
element in the DTD.

More thinking about this towards the end of this message ...

> 
>>> Anyway, it's a trivial change, can be easily one of the two, I don't 
>>> mind.
>>>
>>>>>         <attributes>
>>>>>         </attributes>
>>>>>       </service>
>>>>> -  </services>
>>>>>   <dependencies>
>>>>>     <dependency optional="FALSE">
>>>>>       <role>my-transformer</role>
>>>>> -     <reference type="org.apache.cocoon.api.Transformer" 
>>>>> version="1.1"/>
>>>>> +      <service-ref type="org.apache.cocoon.api.Transformer" 
>>>>> version="1.1"/>
>>>>>        <attributes>
>>>>>        </attributes>
>>>>>       </dependency>
>>>>>    </dependencies>
>>>>>
>>>>> -    <phases>
>>>>> -      <phase>
>>>>> -        <reference type="org.apache.security.Securable"/>
>>>>> -      </phase>
>>>>> -      <phase>
>>>>> -        <reference type="org.apache.db.Persistable"/>
>>>>> -      </phase>
>>>>> -    </phases>
>>>>>
>>>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>  (this should be specified, I would prefer "lifecycle" as a 
>>>>> container element, but it can be called "ratsass" too ;-)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> :-)
>>>
>>>
>>>
>>>  >
>>>
>>>>>
>>>>> -    <extensions>
>>>>> -      <extension>
>>>>> -        <reference 
>>>>> type="org.apache.excalibur.playground.DemoExtension"/>
>>>>> -        <attributes>
>>>>> -          <attribute key="status" value="experimental"/>
>>>>> -      </attributes>
>>>>> -      </extension>
>>>>> -    </extensions>
>>>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>    (This is Merlin specific, no?)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> No.
>>>> The extensions element is simply the component declaring an 
>>>> extension depedency.  This is specific to the excalibur/meta package 
>>>> - which is used by Merlin - and meets the requirements of both 
>>>> Merlin and Fortress. 
>>>
>>>
>>>
>>>
>>> Ok, then Merlin/Fortress specific.
>>>
>>>> It is totally independent of a the existance of an extension 
>>>> implementation.  
>>>
>>>
>>>
>>>
>>> But it *does* introduce extension semantics, which is a contract not 
>>> to be done lightly.
>>
>>
>>
>> A container that does not support extension semantics does need to 
>> know that if a component requires extensions.  Keeping in mind that 
>> this is at the DTD level, all a container needs to do is check for the 
>> presence of the <stages/> element - if the element is present then the 
>> container can take appropriate action depedening on its level of 
>> support. The only situation this implies semantics is in the case of a 
>> container that supports extensions.  For example - a container that 
>> does not provide extension support can do something like:
>>
>>     Configuration stages = config.getChild("stages", null );
>>     if( stages != null )
>>     {
>>         String error = "Unsupported stage depedencies.";
>>         throw new IllegalStateException( error )
>>     }
>>
>> Not a lot semantics there!
> 
> 
> Exactly!
> 
> Reread what I wrote, I said that <stages/> is needed, but extensions is 
> relative to how Merlin/Fortress provides the stages.

Yep.

>>>> However, a container needs to know if its dealing with a component 
>>>> it cannot handle.
>>>
>>>
>>> That's in the phases.
>>> You should find another way of declaring it.
>>>
>>> Saying "you need this extension class" is not the same as saying "you 
>>> need this feature".
>>>
>>>>> -  </type>
>>>>> +</component-info>
>>>>>
>>>>>
>>>>> Have I forgotten anything?
>>>>
>>>>
>>>>
>>>> One item (not shown in the example).  In the type DTD I have 
>>>> included a <management/> element that contains a <reference/>

>>>> element.  This is needed to handle the equivalent 
>>>> management-access-point declarations in Phoenix blockinfo DTDs.  The 
>>>> <management/> element is not supported by Merlin at this time - but

>>>> just like <stage/> and <extension/>, Merlin needs to know if
the 
>>>> component is doing something it cannot implement.
>>>
>>>
>>> "the equivalent management-access-point declarations in Phoenix 
>>> blockinfo DTDs"
>>>
>>> Can easily standardize on those.
>>
>>
>>
>> Yep.
>>
>>>>> *What's* the problem then???
>>>>
>>>>
>>>>
>>>
>>> So?
>>>
>>> Again, *what* is the problem?!?
>>
>>
>>
>> To converge the DTDs you have to deal with the following:
>>
>>   1. differences in element names
>>       --> easily resovable
> 
> 
> Ok.
> 
>>   2. inclusion of the <stages/> and <extensions/> elements
>>      in order for (a) recogition of a dependency of this
>>      type and (b) interpritation of descriptions by containers
>>      that support extensions
> 
> 
> Easy.
> 
> (a) needed, and we all seem to agree.
> (b) it's not in framework, not widely recognized and still experimental.
>     What would happen if any container started polluting the file with 
>     his needed stuff?

If a couple of containers implemeted and validated it - that would be 
sufficient a case for considering inclusion.  There are other examples 
of Merlin specific stuff which is not in the type DTD - its seperate 
because of the very point that your raising.

> Let's instead define a standard way of resolving them, and in the 
> future, if the concept of extensions proves valuable, we can merge it 
> into the descriptor, as done for interfaces (metadata now ;-), etc...
> 
> So why not:
>   container.type.xext
> 
> So for Merlin
>   merlin.extensions.xext
> 
> For Fortress
>   fortress.extensions.xext

What may be possible (and I emphasis *may*) is for the <extension/> and 
<phase/> elements in the Type DTD to be folded into respective 
<service/> and <dependency/> declarations, flagged with a *special* 
attribute.

For example - a depedency could be qualified with the following attribute:

     avalon.component:dependency.phase="lifecycle"

relative to a default implicit value of:

     avalon.component:dependency.phase="assembly"

The above basically would allow distinction of a dependency descriptor 
in terms of the phase to which it is applicable.  A "lifecycle" phase 
means that the dependency is on a lifecycle extension whereas the 
default "assembly" phase is the classic assembly process of wiring 
together normal service consumption depedencies with service provider 
components.

And for service declarations:

     avalon.container:service.phase="lifecycle"

relative to a default implicit value of:

     avalon.container:service.phase="assembly"

This would help to normalize the DTDs - assuming we include the above in 
a general container attributes spec on wich we handle recognition that 
the attribute has implications thay may or may not be resolvable by a 
particular container.

Thoughts?

Steve.


-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net


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


Mime
View raw message