David Sean Taylor said: > > On May 24, 2004, at 12:12 PM, Ate Douma wrote: > >> Yesterday I succeeded in enabling JAAS Authentication on Tomcat 4: >> http://issues.apache.org/jira/browse/JS2-52 >> >> The problem is, it isn't working on Tomcat 5 because of a change in >> classloading introduced with Tomcat 5 for the JAASRealm. >> >> The JAASRealm implementation on Tomcat 5 is different from the one on >> Tomcat 4 in that it sets the current Thread ClassLoaderContext to that >> of the Catalina core itself before accessing a LoginModule. >> >> The developer adding this *feature* himself seemingly thought it might >> result in problems because it contains as inline comment: >> "What if the LoginModule is in the container class loader ?". >> >> I don't know if this is according to the JAAS specs or not but it is a >> nasty problem with the current Jetspeed architecture. >> >> I've looked into the Tomcat 5 Bug Database and found issue 26475: >> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26475 >> >> This issue exactly describes our problem. >> But, Remy Maucherat, one of the lead developers, simply didn't find >> the issue a problem (2004-01-27 23:31): >> "Obviously, the realm is a server component. As a result, all its >> dependent classes must reside in the server classloader. I do not see >> anything wrong with this." >> >> And (2004-01-28 09:07): >> "/WEB-INF is the application classloader, not the server >> classloader. This does not convince me at all. If somehow the realm >> can look up stuff, the conext CL is the webapp CL during the realm >> initialization. If nobody looks at this report within a week, I'll >> close it again." >> >> And finally (2004-02-02 20:08): >> "As there has been no activity, and I think the classloading >> behavior is the right one, I am closing this bug. Please use >> tomcat-user if you are still experiencing problems." >> >> So it seems we're toast. >> To be able to use JAAS Authentication on Tomcat 5 we are required to >> put the RdbmsLoginModule in the server classpath. This can't be done >> right now: it requires most of the persistence, rdbms and security >> classes and putting them all there won't do either (leads to other >> classloader issues and if it were working it would lead to two >> different OJB caches in which changes made through the portal won't be >> seen by the LoginModule or no cache should be used for the login). >> >> As far as I can see there are three possible solutions: >> 1) Remodel Jetspeed in such a way that the RdbmsLoginModule can be >> used from the Tomcat 5 server classpath. I guess this will take a lot >> of work but I'm not the designer of the security component so maybe >> others see a short way out? >> > Yes, we would need a scaled down light weight version, perhaps using > JDBC only > >> 2) Try to convince the Tomcat crew to revert to the old Tomcat 4 >> behavior. Maybe conditionally with an additional realm parameter? >> I have a gut feeling they are not open to this but maybe Jetspeed is >> important enough to make a difference??? >> > Well there is an obvious issue: > You have one behavior in Tomcat 4, and another behavior in Tomcat 5 > One would think the Tomcat team would want to minimize these kind of > issues. > I think we should try to make an argument > >> 3) Create an extended JAASRealm implementation or patch the current >> one without the new Tomcat 5 ContextClassLoader problems. This would >> be a short and simple solution (I tried it out: 5 minutes work) but it >> creates a dependency on the current Tomcat 5 implementation and >> requires putting the hacked/extended class in the server classpath. >> > This sounds like the solution for now, until we can sort out #2 That's +3 (including mine) for option #3. If nobody is going to object I will create a new issue and a patch this evening for this solution.
I'm also +1 for option #2: sorting it out with the Tomcat Team. But even if they are willing to revert back to the Tomcat 4 behaviour, I expect it will take to long to have no solution for now. Solution #3 will cover that. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
