Fortress (The ECM replacement) has a feature that allows you to automatically gather all your roles and components that implement those roles at runtime. There is no need to maintain a separate file, or to include a "user-roles" document.
Hmmm, how do you do that? I mean, the classloader doesn't have a way to for you to gather all the classes it contains in its address space.
Please don't tell me you are looking into the jars directly!
I just want to see what kind of response this feature will get, and if I should make it the default. Please let me know what you think.
ok
The way it works is that you store your meta-information in javadoc tags like this:
/** * @avalon.component * @x-avalon.lifestyle pooled * @x-avalon.name my-component */ public class MyComponent implements SomeRole { //.... }
/** * @avalon.role */ public interface SomeRole { //.... }
The way it works is you use a couple Ant Tasks that are included in the Fortress tools JAR. One collects all the meta information and generates a services.list file and the property files next to the components for your JAR. The other one polls your JAR and finds *all* the concrete implementations of your services (in the services.list file), and upgrades the JAR file with the JAR services compliant entries.
At runtime, all you have to do is drop in your JAR and Fortress will do the rest. According to the information given, the above component would be referenced in the config file as:
<my-component id="comp"/>
The meaning of the attributes are as follows:
@avalon.component Marks a class as a component @avalon.role Marks an interface as a Role interface @x-avalon.lifestyle Marks the lifestyle of the component @x-avalon.name Provides a short name for configuration @fortress.handler Class name for the component handler
Both @avalon.component and @avalon.role are markers, they have no additional information.
If either @x-avalon.lifestyle or @x-avalon.name do not exist, Fortress will attempt a best guess. @fortress.handler is not needed unless you want to extend Fortress's standard set of lifestyle handlers.
@x-avalon.lifestyle has one of four possible values:
singleton (aka ThreadSafe) pooled (aka Poolable/Recyclable) transient (aka SinlgeThreaded) thread (uses ThreadLocal)
If you do not provide that attribute, OR the @fortress.handler attribute, then Fortress will attempt a best guess by respecting the old ECM contracts for the marker interfaces. If even that information is missing, Fortress will assume it is a Thread Local component.
If the @x-avalon.name does not exist, Fortress will attempt to provide a mapping by converting the class name to a string. The conversion converts humpback notation (e.g. ThisIsHumpBackNotation) to all lowercase hyphenated names. For example:
XMLCompiler --> xmlcompiler HiMom --> hi-mom XYZpdqBCLtdl --> xyzpdq-bcltdl
This should not only make things easier for the migration to any container the Avalon team could possibly think of in the future, it also provides a much easier way to integrate user components in Cocoon based applications.
I like it.
+1
I would suggest to do the transition from ECM to Fortress for Cocoon 2.2, anybody against this?
-- Stefano.
