Bug 956631

Summary: CLONE - Cross-context forward/include call from another web app breaks HttpRequestContext cleanup
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Ron Šmeral <rsmeral>
Component: CDI/WeldAssignee: Jozef Hartinger <jharting>
Status: CLOSED CURRENTRELEASE QA Contact: Ron Šmeral <rsmeral>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.1.0CC: amelicha, dandread, jharting, jlivings, lcosti, lywang, maschmid, pmuir
Target Milestone: ER4   
Target Release: EAP 6.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
For forwarded requests, `WeldListener` would clean-up a bound context request when the servlet that was processing it finished, even though it was being sent to another servlet. As a result, when the other servlet would try to access the context, it would produce a `NullPointerException`. This issue has been fixed in this release of JBoss EAP 6 by not cleaning up a bound context if the servlet is being redirected. As a result, using `getRequestDispatcher().include()` to forward requests between servlets should no longer produce exceptions related to incorrect `WeldListener` clean-ups.
Story Points: ---
Clone Of:
: 1008277 (view as bug list) Environment:
Last Closed: 2013-12-15 16:22:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1011551    
Bug Blocks: 1003581, 1008277    

Description Ron Šmeral 2013-04-25 10:37:57 UTC
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

Comment 2 James Livingston 2013-09-11 00:14:11 UTC
*** Bug 1006623 has been marked as a duplicate of this bug. ***

Comment 3 JBoss JIRA Server 2013-09-18 16:49:12 UTC
Ron Šmeral <rsmeral> updated the status of jira WELD-1415 to Reopened

Comment 4 JBoss JIRA Server 2013-09-18 16:49:12 UTC
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

Comment 5 JBoss JIRA Server 2013-09-19 07:12:47 UTC
Jozef Hartinger <jharting> updated the status of jira WELD-1415 to Resolved

Comment 6 JBoss JIRA Server 2013-09-19 07:12:47 UTC
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.

Comment 7 Ron Šmeral 2013-09-20 10:59:35 UTC
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.

Comment 9 JBoss JIRA Server 2013-09-23 09:11:18 UTC
Jozef Hartinger <jharting> made a comment on jira WELD-1511

Fixed in Weld 1.1

Comment 10 JBoss JIRA Server 2013-09-25 08:01:52 UTC
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.

Comment 11 JBoss JIRA Server 2013-09-25 08:05:42 UTC
Jozef Hartinger <jharting> made a comment on jira WELD-1511

We'll need to make this configurable.

Comment 12 JBoss JIRA Server 2013-09-26 13:56:00 UTC
Jozef Hartinger <jharting> updated the status of jira WELD-1511 to Resolved

Comment 17 Dimitris Andreadis 2013-10-15 12:47:44 UTC
Brian is this merged already in ER4?

Comment 18 Brian Stansberry 2013-10-15 14:10:08 UTC
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.

Comment 19 Ron Šmeral 2013-10-16 15:14:32 UTC
Verified on EAP 6.2.0.ER5.