AltRMI is using the Attributes framework from Commons. What do you think we should do. Have our own comp or use commons ?
- Paul
I have some rudimentary support for using attributes to represent components and their roles. The core mechanisms in Fortress have not changed, but I am adding a new RoleManager that can read a resolve components from several different jars automatically.
It will be used in my GUIApp system--but I want to put it in Fortress before we release as well. I want to mark the services and components with a minimal set of attributes--which will get our users used to added functionality in Merlin and Phoenix.
I can think of the following *core* attributes:
@avalon.service -- Required for marking role interfaces.
@avalon.component -- Superfluous because I can cull all the implementations of a service quite easily. Used in Merlin and Phoenix though.
@avalon.scope -- Used to represent the scope of the component, and consequently the lifestyle. Values are "container", "thread", and "request"
Non standard container specific attributes would be:
@fortress.configname -- The short name used for component configuration. I would like to see this as an official Avalon attribute because I feel strongly that the simple name of a component's configuration element should reflect a *type* (implementation) and not an instance. I am not willing to fight a long battle on it.
@fortress.handler -- The fully qualified name of the component handler. Used to access new variants or non-prefered handlers. The main three can be accessed via avalon.scope.
Two of these are already a done deal, the only two to get feedback on are @avalon.scope and @avalon.configname.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
