You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/08/28 14:21:16 UTC
Containerkit and Merlin 2 descriptors: basically the same?
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)
<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)
<services>
<service>
- <reference type="SimpleService" version="3.2">
+ <service-ref type="SimpleService" version="3.2"/>
<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?)
- </type>
+</component-info>
Have I forgotten anything?
*What's* the problem then???
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit and Merlin 2 descriptors: basically the same?
Posted by Stephen McConnell <mc...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit and Merlin 2 descriptors: basically the same?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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
>>
>>>>
>>>> <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.
>> 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.
>>> 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?
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
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit and Merlin 2 descriptors: basically the same?
Posted by Stephen McConnell <mc...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit and Merlin 2 descriptors: basically the same?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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>
>>
>> <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.
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.
> 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 managerment-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 componet is doing something it cannot implement.
"the equivalent managerment-access-point declarations in Phoenix
blockinfo DTDs"
Can easily standardize on those.
>> *What's* the problem then???
So?
Again, *what* is the problem?!?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit and Merlin 2 descriptors: basically the same?
Posted by Stephen McConnell <mc...@apache.org>.
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.
>
> <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.
> <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.
> <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.
It is totally independent of a the existance of an extension
implementation. However, a container needs to know if its dealing with
a component it cannot handle.
> - </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 managerment-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 componet is doing something it cannot implement.
Cheers, Steve.
> *What's* the problem then???
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>