cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [POLL] Removing Roles File?
Date Fri, 04 Apr 2003 18:09:46 GMT
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.

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.

The way it works is that you store your meta-information in javadoc
tags like this:

  * @avalon.component
  * pooled
  * 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        Marks the lifestyle of the component             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 or 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. 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

If the 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.

View raw message