Bug 1022069
| Summary: | Undeploying a web application removes the http request PolicyContextHandler globally | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Eric Wittmann <eric.wittmann> |
| Component: | Web | Assignee: | Rémy Maucherat <rmaucher> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Radim Hatlapatka <rhatlapa> |
| Severity: | unspecified | Docs Contact: | Russell Dickenson <rdickens> |
| Priority: | unspecified | ||
| Version: | 6.2.0 | CC: | brian.stansberry, dandread, kconner, myarboro |
| Target Milestone: | ER7 | ||
| Target Release: | EAP 6.2.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-12-15 16:13:44 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: | |||
|
Description
Eric Wittmann
2013-10-22 15:13:45 UTC
It should be noted that I plan to workaround this problem in Overlord by introducing a Valve (configured in jboss-web.xml) which will do nothing except stash the current Http Request in a thread local variable so that the login module has access to it. It should work fine, but it would be better of the PolicyContext bug were fixed so that the additional valve were not necessary. This happens in JBossWebRealmService.start()
// Register the active request PolicyContextHandler
HttpServletRequestPolicyContextHandler handler =
new HttpServletRequestPolicyContextHandler();
PolicyContext.registerHandler(SecurityConstants.WEB_REQUEST_KEY, handler, true);
and this in stop():
// remove handler
Set handlerKeys = PolicyContext.getHandlerKeys();
handlerKeys.remove(SecurityConstants.WEB_REQUEST_KEY);
The problem is JBossWebRealmService is a service scoped to a deployment. Those calls seem more appropriate for a service scoped to the web container.
So these two things could be moved to WebServerService.start/stop, for example ? I agree they do seem static and detached from the deployment. (In reply to Rémy Maucherat from comment #5) > So these two things could be moved to WebServerService.start/stop, for > example ? I agree they do seem static and detached from the deployment. Sounds good. I don't see any other services that make more sense than that. I looked at the PolicyContext impl and all registerHandler does is do a put in a static map. So I can't see any downside to moving this out of the deployment-scoped service. Semi-OT -- the stop behavior of PolicyContext.getHandlerKeys().remove(...) is kind of a hack. The PolicyContext.getHandlerKeys() API doesn't say anything about the returned Set being usable for that purpose. There's no other API to accomplish the purpose though. Probably the call should be in a try/catch though so if an impl rejects the remove the failure doesn't propagate. If it was rejected it doesn't really harm anything, since the VM is either shutting down, or in a reload case on the next start call the 'true' param to registerHandler will replace the old handler with the new one. Dev-acking on behalf of Rémy (or please shout). Verified with EAP 6.2.0.ER7 |