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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
