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 13:38:15 GMT


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>

?


> 
>>>
>>>   <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.

> 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!


> 
>> 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
   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

That's all.

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