If that's the case then, great, we can just build the stack when the
bean is created and leave it fixed.
-David
On Oct 16, 2009, at 2:34 AM, Gurkan Erdogdu wrote:
Hi David;
I thought that if decorator beans are defined with scope @Dependent
it seems that no problem occurs regarding thread safety. Because,
every time container gets its instance, there will be a new
decorator instance.
But at the overall, those concerns are all fine.
Thanks;
--Gurkan
________________________________
From: David Blevins <[email protected]>
To: [email protected]
Sent: Fri, October 16, 2009 1:06:10 AM
Subject: Decorators and @Decorates injection
We don't currently support this and implementing it correctly will
actually be tricky. I recommend we ignore everything I'm about to
say and just implement it naively for the sake of simplicity and
come back and make this change later.
The trick: you can't inject the delegate while creating the chain on
the fly during a pending invoke.
The reason being is a single Decorator instance can apply to several
beans and therefore could be executed concurrently. All invocations
to those beans will funnel through the same Decorator instance.
With Interceptors this is not an issue as the delegate is
essentially passed into the around invoke method. With Decorators,
it's a field, and overwriting it while it's being accessed by other
threads is the definition of not thread-safe.
We're essentially going to need to inject a proxy-like object as the
delegate and do that once when the Decorator is created. That
delegate will have to look in a thread local in some way for the
next guy down the chain and send calls to it.
That will actually be somewhat of an effort as this is all strongly
typed -- we actually need to implement the interface which means
well be making one of these for each interface type that can be
decorated. This is old-hat in app server land, but will be a bit of
an undertaking. Fortunately, one that can be done as an isolated
change unrelated to the basic concept of having a stack.
We can just do this ignoring thread saftey at first and then get
that in there once things look good generally. That's my
recommendation anyways. Getting small changes in frequently is
usually better than saying "no one touch this code I'm working on
it" and have that go on for more than a few days, which is an easy
pit to fall into when simple problems continue to get more
complicated. Figured I'd mention it up front as the above problem
is an easy pit to fall into.
-David
