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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
