[cdi-dev] Interceptors for qualified @PostConstruct methods?

[Craig Ringer]

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.