Berin Loritsch wrote:
Stephen McConnell wrote:
Old style: ----------
@avalon.meta.version 1.0 @avalon.meta.name fred @avalon.meta.lifestyle singleton
New style: ----------
@avalon.type version="1.0" name="fred" lifestyle="singleton"
Because this is in the avalon namespace, we need to officially adopt it.
Currently there is already the @avalon.component tag that is a marker tag
for components. IMNSHO, it would be better to extend the @avalon.component
tag with these attributes.
That way we have
@avalon.component name="fred" version="1.0.0" lifestyle="singleton"
While the lifestyle attribute has been criticized in the past, it seems to
be the best balance of usability and simplicity.
So far, components for Phoenix and Fortress both use @avalon.component
w hich leaves Merlin as divergent. Would it be too terrible to to simply
extend the already existing tag?
I wanted to but there is a problem that you actually have to distinguish current @avalon.component usage "without attributues" from @avalon.component "with attributes". I had the choice of either adding a lot of legacy handling code or defining a clean tag with hooks for legacy (and by legacy I mean existing @avalon.component no attribute form).
Many of these can fall back to default values. For example, version would either be "1.0" or undefined (whatever we decide). The name would default to the way the Fortress tool translates it or something equivalent. The only problematic one would be the default value for lifestyle. ECM defaulted to "transient" equiv. because that was the safest option at the time. Fortress will use ECM semantics (i.e. the marker interfaces) if no lifestyle is defined. Otherwise it will assign "thread" to the component lifestyle.
Any way you look at it, we can come up with a design that will work. It could be that the default lifestyle is container dependent--or configurable. Preferably, it would be static to one of the above aproaches.
Second problem I encounter was that the "current" spec declares @avalon.component as the marker tag - which does not make sence when your declaring extended service information. I.e. in the following example its the @avalon.service tag that is the marker.
/** * My interface defining a service. * @avalon.service version 2.1 */ public interface MyService { }
The current @avalon.service is defined elsewhere, and is not a marker tag.
We can change the spec to adapt to our new needs.
The meta generation task and plugin as currently implemented basically looks for the following:
@avalon.type <-------- result in the generation of a Type @avalon.service <----- (in an interface) results in the generation of a Service @avalon.component <--- marks class as requiring legacy handling and hooks in a special handler
The only documented semantics for @avalon.service is in a class.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
