On Wed, 4 Sep 2002 21:22, Peter Donald wrote: > > What I like about making services and components full meta types is > > summed > > up in two aspects: Service resolution and Service management interface > > publication. We had talked in the past regarding attributes helping the > > container distinguish between multiple service implementations. However > > there was no real way to validate the attributes, or use them in an > > automated fashion. Here is what a service definition would allow us > > to do: > > I attributes slightly differently but I have similarly come up against the > limitations (lack of validation/definition). > > Anyways I tend to think of attributes as aspects rather than features of a > artefact. So I tend to think in terms of saying things like "Apply these > (persistence|transaction|remoting|security|instrumentation) attributes to > the method/interface/component etc." However you are marking them as > helping the selection criterion be narrowed for a component and so forth? > > For an example I have attached the set of attributes I have attempted to > boil down that are essentially container independent. The list used to > contain many more but I have moved them to different categories; > * toolkit specific (ie altrmi:*) > * container specific (ie phoenix:*) > * aspect specific (mx:*, persist:*) (Though I have barely looked at this > side of things) > > Anyway take a look at the list to see what I mean.
And this time I made it into a jar so the list manager will not strip it. -- Cheers, Peter Donald ------------------------------------------------------------ militant agnostic: i don't know, and you don't know either. ------------------------------------------------------------
attributes.jar
Description: application/jar
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
