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