dependency injection no ResourceFilter não está funcionando?

Eu tenho um monte de resources JAX-RS que fornecem uma API para um novo WebService. Para entender o que está acontecendo, gostaria de armazenar informações sobre cada solicitação em um data warehouse. Na minha opinião, este é um exemplo perfeito para uma preocupação transversal, que poderia ser implementada por um ResourceFilter , certo?

Então eu construí um DataWarehouseService que deveria armazenar coisas no database:

 @Stateless @LocalBean public class DataWarehouseService { public void logApiCall(ContainerRequest cr) { // get interesting fields from request, store in DB ... } } 

E aqui está o meu filtro:

 public class LoggingResourceFilter implements ResourceFilter { Logger log = Logger.getLogger(this.getClass().getName()); @EJB DataWarehouseService dwh; @Override public ContainerRequestFilter getRequestFilter() { return new ContainerRequestFilter() { @Override public ContainerRequest filter(ContainerRequest cr) { log.info("Incoming request: "+ cr.getHeaderValue("user-agent") +" "+ cr.getMethod() +" "+ cr.getPath() ); dwh.logApiRequest(cr); return cr; } }; } @Override public ContainerResponseFilter getResponseFilter() { return null; } } 

Eu injetar o filtro em meus resources JAX-RS via anotação @ResourceFilters(LoggingResourceFilter.class) no nível de class.

A injeção de filtro funciona bem, quando eu access um dos resources do JAX-RS, a instrução de log (“Incoming request: …”) é executada. Mas imediatamente depois, a chamada para o dwh.logApiRequest(cr) DataWarehouseService injetado falha com um Nullpointer – obviamente a injeção falhou ?!

Qual é o problema aqui? Eu pensei, ResourceFilters são gerenciados e podem usar o CDI. Estou errado?

Tudo isso é executado no Glassfish 3.1.1, o Jersey 1.8 é o provedor JAX-RS. Seria uma diferença se eu usasse @Inject ?