You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/04/04 20:09:46 UTC
[POLL] Removing Roles File?
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
* @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.
Re: [POLL] Removing Roles File?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
<snip/>
> Pretty standard placement of meta-info files.
>
> At the root of the jar that is run with Fortress's ANT tools is a
> "services.list" file. This tells fortress which service entries
> are available in the JAR.
>
> It then uses that information to load in all the JAR Services
> compliant entries. For instance, the file might have:
>
> org.apache.cocoon.generate.Generator
> org.apache.cocoon.transform.Transformer
>
> And in the JAR file there would be another list for the implementations
> of each service:
>
> META-INF/services/org.apache.cocoon.generate.Generator
> (lists all implementations in the jar)
> META-INF/services/org.apache.cocoon.transform.Transformer
> (lists all implementations in the jar)
>
> The classes aren't loaded until they are actually needed.
Sounds good. +1 !
However, there's a limitation on ClassLoader that you must be aware of
(if you don't know it already) : although methods loadClass() and
getResource() can be redefined to change the priority order between the
current classloader and its parent, the getResources() method is final,
meaning the returned enumeration will always with resources defined on
the ancestor classloaders.
Don't know if this is a problem for Fortress, but this has to be known.
>>> 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?
>
>
> I am for it. It might help with the Block initiative.
+1 for transition to Fortress in 2.2
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [POLL] Removing Roles File?
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> 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!
:) Nope.
Pretty standard placement of meta-info files.
At the root of the jar that is run with Fortress's ANT tools is a
"services.list" file. This tells fortress which service entries
are available in the JAR.
It then uses that information to load in all the JAR Services
compliant entries. For instance, the file might have:
org.apache.cocoon.generate.Generator
org.apache.cocoon.transform.Transformer
And in the JAR file there would be another list for the implementations
of each service:
META-INF/services/org.apache.cocoon.generate.Generator
(lists all implementations in the jar)
META-INF/services/org.apache.cocoon.transform.Transformer
(lists all implementations in the jar)
The classes aren't loaded until they are actually needed.
>> 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?
I am for it. It might help with the Block initiative.
Re: [POLL] Removing Roles File?
Posted by Torsten Curdt <tc...@dff.st>.
>>>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
>>
>
> Absolutely: great, +2 :)
+1
>>I would suggest to do the transition from ECM to Fortress for Cocoon
>>2.2, anybody against this?
+1 sounds good
...I almost missed this one :)
--
Torsten
RE: [POLL] Removing Roles File?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
> > 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
>
Absolutely: great, +2 :)
> I would suggest to do the transition from ECM to Fortress for Cocoon
> 2.2, anybody against this?
>
Yes, agreed, we shouldn't do this for 2.1 and we need it for the blocks
implementation in 2.2 (hopefully) anyway.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/
Re: [POLL] Removing Roles File?
Posted by Stefano Mazzocchi <st...@apache.org>.
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.