The types task automates the creation of component type meta-info. Information captured during type creation includes the component implementation class name, logging channel assumptions, the services provided by the type, context assumptions, and internal parts.
| name | Set the type name - used internally in error reports. |
| class | Set the component implementation class. |
| lifestyle | Set the component lifestyle. Allowable values include SINGLETON, THREAD, and TRANSIENT. A component declaring the SINGLETON will be shared across all consumers within the JVM (i.e. the potential for concurrent access will exist). A component declaring the THREAD lifestyle policy will have a set of instances corresponding to the number of threads requesting access. A component declaring the TRANSIENT lifestyle will instantiated for each request. The default lifestyle policy is TRANSIENT (reflecting the most conservative scenario). |
| collection | Sets the component garbage collection policy. Allowable values include WEAK, SOFT and HARD. A component declaring a WEAK collection policy will be garbage collected at the discretion of the JVM. A component declaring a SOFT collection policy will be garbage collected in the event of memory contention. A component declaring the HARD collection policy will remain in memory for the lifetime of the JVM unless explicitly removed via a management system or controlling application. |
| threadsafe | Declares the component implementation as threadsafe. |
| state | Definition of a component state graph. |
| parts | Definition of the internal parts (nested components) within this component type. The parts element allows for the structural composition of components as part-of an enclosing component type. Enclosed components can be viewed as a private internal implementation strategy of the type. |
Example using the <type> task to generate a series of .type descriptors:
<type xmlns="dpml:metro" class="net.dpml.test.composite.ChildComponent" name="child"/>
<type xmlns="dpml:metro" class="net.dpml.test.composite.CompositeComponent" name="parent">
<parts>
<component type="net.dpml.test.composite.ChildComponent" name="child" activation="false">
<context>
<entry key="color" method="BLUE"/>
</context>
</component>
</parts>
</type>
The above usage of the <type> task can be optimised through the usage of the <types>. The <types> tasks reduces the overhead during construction of runtime classloader information. When generating types using the <types> task the classloader construction is only executed once. The following example is an optimized equivalent of the above.
<types xmlns="dpml:metro">
<type class="net.dpml.test.composite.ChildComponent" name="child"/>
<type class="net.dpml.test.composite.CompositeComponent" name="parent">
<parts>
<component type="net.dpml.test.composite.ChildComponent" name="child" activation="false">
<context>
<entry key="color" method="BLUE"/>
</context>
</component>
</parts>
</type>
</types>
The implementation does not currently provide support for the overriding of published services or the delcaration of logging channel usage assumptions within the component implementation.
Component type meta-info is stored in an XML file collocated with the class. The naming convention is the full-qualified classname appended with the suffix .type. The file format is the XML encoding specificed by JSR-57.