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

[Pete Muir]

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.