Re: DI/wiring
On 04/22/2013 02:59 PM, markspace wrote:
On 4/22/2013 12:03 AM, Daniele Futtorovic wrote:
In code terms, instead of:
class Actor {
void act( Context c ){ doSomethingWith( c.getXXX() ); }
}
Just to be clear, I was advocating using constructors, not method
parameters:
public class Actor {
private Context c;
public Actor( Context c ) {this.c = c}
public void act() { doSomethingWith( c.getXXX() ); }
}
This is really really different:
You'd have:
class Actor {
void act(){
doSomethingWith( ContextHelper.getThreadLocalContext().getXXX() );
}
}
Now actor does something different depending on what thread is invoking
a method. My class was invariant with respect to the thread invoking its
method. No matter who calls "act()" the result will always be the same.
Since modern systems often use thread pools and the worker threads are
supposed to be generic and often randomly assigned, I can't see too many
cases where your thread local context is going to be useful. Worse, if
an generic worker thread has a context and then is assigned to another
task... the results could be random and unpredictable, and really hard
to debug as well.
I'm sure you must have some use case in mind where a thread local is
useful, but I'm having a hard time seeing it. It feels like you push
the context/initialization problem into the threading system, where it's
actually going to be harder to manage. In a system that was designed
from the ground up to support contexts attached to threads, OK it might
work, but in many existing systems it seems difficult to add.
I can think of one right now, one that is in production in a fairly
major J2EE/JEE system I am familiar with.
The idea was/is to implement a persistent conversation, and this
implementation goes back about 7 years, in the context of JSF 1.x and
JPA. Basically an application-managed entity manager needs to kept
around, one for each application user, from a defined EM-creation
checkpoint to a defined EM-commit/rollback checkpoint. This is needed
because money is involved and the real-world scenario demands it. It is
not possible to commit per-request, for much of the business state.
Between HTTP requests it's reasonable to keep a user's EM in their HTTP
session. *During* requests the specific conversational EM assigned to
that user must be made available wherever it's required in code - a very
convenient way of doing that is to place the user EM into a ThreadLocal
in the 1st JSF phase, in a helper class, and provide a getter to allow
the user's HTTP request thread to retrieve that "special" EM as needed
in any method.
I think you'll realize that something like an ApplicationScoped JSF
managed bean would not work here. It's technically possible for B.L. or
datalayer code to access a JSF managed bean, if you assume that that top
layer is there, but it's an unpleasant picture. Much better to have the
user EM's kept in a ThreadLocal in a data layer helper class, since that
makes architectural sense.
I might add, this described implementation is pre-Servlet 3 and no async
processing is involved.
AHS