Nitpicks:
avalon:reentrant
Component, Service
true
Indicates that the artefact is capable of having the
same thread enter component multiple times in same
call stack. ie A thread enters Component A, then enters
Component B and if it is capable of re-entering
Component A then Component A is said to be reentrant.
That describes the behaviour of re-entrant *locks* but not of re-entrant
routines. A lock is re-entrant if you can do multiple acquire()s on it,
as long as those acquire() come from the same thread. In general, code
is
re-entrant if it does not access any data outside of itself.
For example, a method that only accesses local variables or the
parameters
passed to it.
So reentrant implies threadsafe. (But not the other way around.)
You may have a need to declare an attribute that has the meaning you
specified,
but I would:
+ think twice before naming it "reentrant"
+ consider whether it is needed at all. I see some fairly difficult
problems
that the container must solve if it is to magically make every
component
reentrant on demand. (For example, Component A is not re-entrant, but
calls
component B. B now calls A. What should the container do? Plus, the
only time
you'll get something like this is when you have circular dependency -
seems
like a waste of time to me to code for that case...)
/LS
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
>
> 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.
> ------------------------------------------------------------
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
