Summary: | Tomcat 7 JAAS problem with CDI | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | Flávio Henrique <servlet> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 7.0.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Attachments: | Tomcat FormAuthentication and CDI problem |
Description
Flávio Henrique
2010-09-23 20:01:53 UTC
This bug report refers to JAAS but the Glassfish fix seems to be more related to FORM authentication. It isn't at all clear to me at this point what the problem is. A test case for Tomcat - with the necessary steps to re-create from a clean 7.0.x install - would help. What also isn't clear is whether there is a Servlet specification compliance issue or if CDI expects things to be a certain way and Tomcat does them differently. The former will certainly get fixed, the latter will probably get fixed. Sorry, the problem is related to FORM authentication, not JAAS. Again: sorry for this mistake. I will prepare the test as soon I reach my Office. Thanks Created attachment 26144 [details] Tomcat FormAuthentication and CDI problem You will need to grab Weld 1.1.0 and put weld-1.1.0.Beta1\artifacts\weld\weld-servlet.jar inside WEB-CONTENT/lib, because I couldn´t updaload the project with the library (file size limit). You can download weld here http://seamframework.org/Weld/Downloads This problem happens with all Weld versions, even with the newest beta. Mark, here is the project for Eclipse Helios 3.6 SR1. You will need to grab Weld 1.1.0 and put weld-1.1.0.Beta1\artifacts\weld\weld-servlet.jar inside WEB-CONTENT/lib, because I couldn´t updaload the project with the library (file size limit). You can download weld here http://seamframework.org/Weld/Downloads This problem happens with all Weld versions, even with the newest beta. The instructions are in the readme.txt, that I will also put here: how to see the bug: 1 - import the project in Helios 3.6 SR1 2 - run on Tomcat 7.0.2 3 - try to access the protected page in restricted/restrictedpage.jsp (right click on the page and execute) 4 - you will get the exception org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped Comment the security constraint that fire the form authentication and you have NO exception. I also discoverd that: a) in eclipse, if you run restricted.jsp with right click (Run On Server) the exception is throw, but if you run the project and after the server start type the complete URL to restricted.jsp, the bug doesn´t happen. b) if you "run on server" the project and open the URL in another browser (don´t use eclipse build in browser), this problem happens. Just updating status now info has been provided. (Unfortunately) the Servlet spec provides no guarantees of the behaviour of request listeners if a forward occurs e.g. for FORM auth or to an error page. Tomcat (and derivatives such as Grizzly and JBossWeb) don't call request listeners around forwards, so Weld's listeners do not get fired. This can either be fixed in Tomcat by calling listeners around forwards (when I spoke to the Servlet EG lead about this, they indicated that they would look at specifying that there is some listener called around forwards in the future) or in Weld's Tomcat support by using Tomcat APIs to get a callback when forwards occur. Mark/anyone on the Tomcat team, if you don't want to make Tomcat call the request listeners around forwards, then we can do some custom hooks in the Weld/Tomcat integration code to get the needed callback. In this case, could the OP file an issue in the WELD issue tracker on http://jira.jboss.org. I don't see any reason to add this to Tomcat but it will probably be optional behaviour. If added this to my list of things to keep an eye on when the EG starts the next version of the spec. I've done a little digging on this. The best definition of the required behaviour is actually in the Javadoc: <quote> Interface for receiving notification events about requests coming into and going out of scope of a web application. A ServletRequest is defined as coming into scope of a web application when it is about to enter the first servlet or filter of the web application, and as going out of scope as it exits the last servlet or the first filter in the chain. </quote> Looking at Tomcat's current behaviour, it isn't firing the request listener for the request that displays the login page. That looks like a spec breach to me. I'll fix that and then see how the test case performs. If the test case is still broken then I'd lean towards the fixing this in Weld option. I've fixed Tomcat 7 so it fires the ServletRequestListener events for the login and error page for FORM authentication. The supplied test case now passes. As part of this, I refactored the process of firing ServletRequestListener so any future change to the Servle spec will be simple to handle. The fix will be in the 7.0.5 onwards. Thanks Marks, the fix of this feature will accelerate CDI adoption in TOMCAT. (In reply to comment #9) > I've fixed Tomcat 7 so it fires the ServletRequestListener events for the login > and error page for FORM authentication. The supplied test case now passes. > As part of this, I refactored the process of firing ServletRequestListener so > any future change to the Servle spec will be simple to handle. > The fix will be in the 7.0.5 onwards. |