7:31 a.m.
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.
My specific use case is PrettyFaces, where I'd like to be able to
perform additional injection into a class before @PostConstruct is run.
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, 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?
--
Craig Ringer
9:46 p.m.
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.
10:01 a.m.
On 03/08/11 03:46, Pete Muir wrote:
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.
I didn't realize that, sorry. Because of the discussion of interceptors
in the CDI / web-beans spec, I got the impression they were controlled
by CDI rather than merely extended/enhanced by CDI.
Please disregard my suggestion - it's already defined in version 1.0 of
the spec, as you pointed out below. Sorry for the waste of your time.
If I understand you correctly, you are asking aroundInvoke-style
interception of lifecycle callbacks on both bean instances and interceptors?
In this case, specifically aroundInvoke-style interception of
@PostConstruct and @PreDestroy lifecycle callbacks on bean instances, as
you showed in your example.
Lifecycle callbacks are already available on interceptors and will be
called lifecycle callbacks defined on the target class e.g.
[snip code example]
Now that is _really_ interesting, and something I completely missed in
the spec. Looking back at it, I have no idea how since it's clearly
documented in the Weld reference for interceptors:
http://docs.jboss.org/weld/reference/1.0.0/en-US/html/interceptors.html
... which I read before going into the spec looking for the
functionality I somehow overlooked in the weld docs.
Sorry to waste your time. I thought this was something the existing spec
didn't cover, but it covers it quite fine.
> 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.
In fact, it seems we even have two different options:
- Add new qualified Bean instances and have app programmers mark
injection sites with (eg) @Inject @URLParameter; or
- Use an interceptor to do programmatic injection and property setting.
The former will work well where a bean can have knowledge of the web UI
specifics. The latter provides the more flexible approach I was hoping
to have for cases where non-injected properties must be set, the bean
can't be aware of web UI specifics, or the URL param mappings vary at
runtime.
Thanks very much for pointing out that I'd overlooked this feature. It
covers the sorts of use cases I had in mind in my proposal perfectly, so
there's no point looking into my suggestion.
12:21 p.m.
On 4 Aug 2011, at 09:01, Craig Ringer wrote:
> If I understand you correctly, you are asking aroundInvoke-style
interception of lifecycle callbacks on both bean instances and interceptors?
In this case, specifically aroundInvoke-style interception of
@PostConstruct and @PreDestroy lifecycle callbacks on bean instances, as
you showed in your example.
Just FTR I didn't show aroundInvoke style interception, I showed lifecycle callbacks.
An aroundInvoke style interception would be able to act *after* the target class lifecycle
callbacks were invoked (and prevent them from being called). whilst what we have today
only allows you to add additional logic into the interceptor *before* the target class
lifecycle interceptors are called.
4655
days inactive
4657
days old
3 comments
3 participants
participants (3)
-
Craig Ringer -
Craig Ringer -
Pete Muir