cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [POLL] Removing Roles File?
Date Fri, 04 Apr 2003 21:22:05 GMT
Berin Loritsch wrote:
> 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.



Mime
View raw message