[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdi-dev] It is beyond time to fix interception on self invocation
|
Hi,
one of the most unintuitive and tripping things in CDI is
invoking internal methods inside a CDI bean and having
interceptors on this methods. Even after several years as a
JavaEE/MP developer I still occasionaly forget about this fact and
waste hours trying to figure out why my interceptor is not
triggering.
It is almost every day that I encounter a need to put a metrics
@Timed or a fault tolerance @Retry, a @Transactional, logging
interceptor etc. on a method called from another method in the
same bean. Typically, the entry point is a JAX-RS endpoint,
followed by injection and call of a CDI bean that implements
business logic. If that business logic is complex I have to split
it up into multiple methods, some of them private.
In order to make this work, I need to move these methods to a
different bean or use a self-inject hack. For example, as tested
right now, Weld supports self-inject or Instance<> inject
and that works fine for @ApplicationScoped and @RequestScoped
beans but not @Dependent (circular dependency exception).
The current situation is bad for multiple reasons:
1. It forces developer to needlesly reorganise code into more
beans than necessary.
2. It forces developer to remember to use a self inject which
seems like a hack and anti-pattern.
3. You need to be aware of the internal workings of CDI proxies.
4. You get no compile time or linter warnings about the fact that
interceptor will be ignored. You only notice the bug at runtime
when testing and things work in some weird way.
5. For a beginner it is unintuitive why it doesn't "just work" by
looking at the code. It just should.
@Timed(name = "timedMethod")
public void timedMethod() {
}
public void selfInvocationTimedMethod() {
timedMethod();
}
Something like and opt-in "@AutoProxy" would keep backward
compatibility while allowing us to instruct CDI runtime to
automatically invoke all/specific bean methods as "business"
methods.
Perhaps there is an even better solution but this is what seems
to make the most sense from all the discussion I've read so far.
See also: https://issues.redhat.com/browse/CDI-414
Best regards, Cen