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
- Decorators and @Decorates injection David Blevins
-
