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