[jboss-jira] [JBoss JIRA] Updated: (JBAS-8870) Injecting SessionContext and WebServiceContext failing with Weld1.1 Final in JBoss 6

Injecting SessionContext and WebServiceContext failing with Weld1.1 Final in JBoss 6 ------------------------------------------------------------------------------------ Key: JBAS-8870 URL: https://issues.jboss.org/browse/JBAS-8870 Project: Legacy JBoss Application Server 6 Issue Type: Task Security Level: Public(Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Environment: JBoss AS6 Reporter: Joel Tosi Assignee: Marius Bogoevici A customer development team at is using Weld 1.1 on JBoss 6 and is encountering the following issue. hey are looking to apply an interceptor to their EJB's to do special exception handling based upon on how the EJB was invoked (RMI or SOAP). Other than the interceptor, they want no reference to exception handling code in the EJB. They are an EAP customer and using EAP5.1 with @Interceptors(class), they could create an interceptor where they could inject the SessionContext and WebServiceContext simply using @Resource without additional parameters. Trying to do the same thing in JBoss 6 using interceptor bindings, it appears that this does not function the same way. From the stack trace and the code available on line, it appears it is trying to inject the resource as if the interceptor is completely independent of the EJB. Is that as expected or is it an issue? They are seeing an error on the jndi lookup that is caused from the interceptor implementation not being bound. Ideally they would like to reuse this interceptor on all of their services, regardless of whether the EJB's are invoked via RMI or SOAP, POJO JAX-WS services, or POJO JAX-RS services. The expectation is for the injection to fail gracefully (just return null or some façade / proxy) if the SessionContext or WebServiceContext is not relevant for the given invocation. In the short term, in the context of EJB's shouldn't this function the same as @Interceptors? Sample code from the customer is in steps to reproduce along with the stack trace. This looks like a bug - if its not please help me understand the design choices here. Best, Joel