Description of problem: It seems the following code is legal (alhough it's not very clear in the Servlet spec): // This servlet is part of CDI-enabled webapp1 @WebServlet("/info1") public class InfoServlet1 extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // CDI-enabled webapp2 contains InfoServlet2 mapped to /info2 req.getServletContext().getContext("/webapp2").getRequestDispatcher("/info2").include(req, resp); } } The problem is the WeldListener in webapp2 cleans up bound request context (ThreadLocal bean store) after the InfoServlet2 processing is finished. Afterwards the request context deactivation in webapp1 results in NPE. Version-Release number of selected component (if applicable): EAP 6.1.0.ER5 How reproducible: Deploy reproducer from WELD-1020 (https://issues.jboss.org/secure/attachment/12360871/WeldTestEAR.ear), which reproduces the same problem using JSP. Open http://localhost:8080/WeldTestWeb1 Actual results: Depending on the Weld version: Weld 1.1.x: java.lang.NullPointerException org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:71) org.jboss.weld.context.http.HttpRequestContextImpl.deactivate(HttpRequestContextImpl.java:86) org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:103) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) java.lang.Thread.run(Thread.java:722) Weld 2.0.0.Beta7: java.lang.IllegalStateException: A request must be associated with the context in order to load the known conversations org.jboss.weld.context.AbstractConversationContext.getCurrentConversation(AbstractConversationContext.java:390) org.jboss.weld.servlet.ConversationContextActivator.deactivateConversationContext(ConversationContextActivator.java:148) org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:143) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) java.lang.Thread.run(Thread.java:722) Expected results: Page opens and shows "include me". Additional info: Clone of https://issues.jboss.org/browse/WELD-1415
*** Bug 1006623 has been marked as a duplicate of this bug. ***
Ron Šmeral <rsmeral> updated the status of jira WELD-1415 to Reopened
Ron Šmeral <rsmeral> made a comment on jira WELD-1415 Only the inclusion is resolved. The cross-context forwarding still does not work. See the updated test: https://github.com/weld/core/pull/372
Jozef Hartinger <jharting> updated the status of jira WELD-1415 to Resolved
Jozef Hartinger <jharting> made a comment on jira WELD-1415 Closing not to break release notes. I am going to create another issue for forwards.
Raising severity to high because there is a one-off for this issue (#1008277) for 6.1.0 and so this needs to be fixed in 6.2.0.
Jozef Hartinger <jharting> made a comment on jira WELD-1511 Fixed in Weld 1.1
Jozef Hartinger <jharting> made a comment on jira WELD-1511 It's tricky to address this issue properly across all servlet containers as almost each of them treats ServletRequestListeners differently. The current fix (ignoring included/forwarded requests) break WildFly where a forwarded request within the same context does not get CDI contexts after the forward.
Jozef Hartinger <jharting> made a comment on jira WELD-1511 We'll need to make this configurable.
Jozef Hartinger <jharting> updated the status of jira WELD-1511 to Resolved
Brian is this merged already in ER4?
Yes. It was fixed via https://github.com/jbossas/jboss-eap/pull/460 which resolved the depended-upon component upgrade BZ https://bugzilla.redhat.com/show_bug.cgi?id=1011551. I'm moving this to ON_QA.
Verified on EAP 6.2.0.ER5.