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