Re: [cdi-dev] Interceptors for qualified @PostConstruct methods?
Note that this group does not control interceptor functionality, however I am more than
happy to take valid requests to the EJB 3.2 EG which does control it.
Anyway, comments inline.
On 2 Aug 2011, at 06:31, Craig Ringer wrote:
Hi all
I've been running into a few cases where it'd be rather handy to be able
to add handling of @PostConstruct (and to a lesser extent @PreDestroy)
to a CDI interceptor, so I can run code before/after a @PostConstruct
method is invoked.
If I understand you correctly, you are asking aroundInvoke-style interception of lifecycle
callbacks on both bean instances and interceptors?
Lifecycle callbacks are already available on interceptors and will be called lifecycle
callbacks defined on the target class e.g.
@Interceptor
@MyInterceptorBinding
class MyInterceptor {
@PostConstruct
public void postConstruct(InvocationContext ctx) {
// Do your injection
}
}
will get called before
@MyInterceptorBinding
class Foo {
@PostConstruct
void bar() { ... }
}
My specific use case is PrettyFaces, where I'd like to be able to
perform additional injection into a class before @PostConstruct is run.
I believe the current behavior should be sufficient for this particular use case.
URL query parameters are to be injected when a bean is constructed,
before @PostConstruct is called. PrettyFaces currently uses an action
method that's run at every request instead, but this works poorly for
beans that are of scopes other than @RequestScoped and requires some
hacks to use effectively.
It's possible that this particular use case can be solved using a
portable extension. PrettyFaces could add new Bean instances with a
prettyfaces-specific qualifier, then app classes can use that qualifier
on injection sites. Parameters not passed may be injected as null; the
injected objects would be of dependent scope so that should be OK. I'm
not sure that'll work yet,
Generally this sounds like a more solid solution.
though, and I thought it'd be worth raising
the idea of intercepting @PostConstruct and @PreDestroy anyway, in case
that sets off ideas for others.
Opinions? Is this a reasonable thing to want? Any obvious pitfalls or
downsides to adding support for it?
As above, I think the existing functionality satisfies your use case. I don't think
there is a need to add this on whim, so I'm interested if anyone has a use case which
can't be met today.