tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject Re: FW: Configuring JAAS realm for a web appplication (Catalina class loader bug)
Date Mon, 08 Nov 2004 04:51:48 GMT

Well, the short answer is, move it to common/lib, not 
server/lib.  server/lib is for stuff that *only* Tomcat itself should 
see.  common/lib is for stuff that both the server and applications should 
see (and shared/lib is the converse of server/lib, but different from 
WEB-INF/lib since it is global to all apps in the server).

Even in the common/lib case, you may run into the same problem, though, 
because if you put the jar in WEB-INF/lib, that will be loaded, 
preferentially by the application because of child first classloading 
behavior that Tomcat implements.  If JASS looks up this class as well, but 
loads it in a different classloader you will run into the same issue.  In 
this case, you'll need to remove the jar from WEB-INF/lib and load it from 
common/lib only.

I can't say for sure that it isn't bad behavior by Tomcat, but I doubt 
it.  It is just a classloading issue you'll have to deal with.  However, 
this is one reason why many appservers out there don't use child first 
classloading behavior by default, although in the server/lib situation 
you'd get the same result in this case.  The common/lib case would have 
been taken care of in a server implementing normal parent first 
classloading behavior, but then it would be redundant to have the jar in 
WEB-INF/lib in that case anyway.  Bottom line is that classloaders are 
tricky and different situations call for different solutions so I doubt 
there is anything fundamentally wrong with what Tomcat is doing.


At 09:31 AM 11/8/2004 +1100, you wrote:

>My company  isusing Tomcat 4.1.29 and I'm investigating a transition to 
>version 5.0.28.
>We use JAAS for authentication. The realm is decleared inside the web 
>application context. The authentication code makes an EJB call to jBoss 
>server (we are using stand alone Tomcat not jBoss bundled version).
>In verion 4.1 we have ejb-client code jar in both server/lib and Web 
>Application lib directories. I have replicated the same structure in 
>version 5 but I get ClassCastException inside my JAAS 
>Authentication  module. If I remove the copy of ejb-client jar from Web 
>Application it all works fine which suggest to me that the 
>ClassCastException related to the fact that the same class id loaded by 
>different classloaders. Tomcat doco specifies that Catalina classloader is 
>invisible to webapplications ( and that's why we use it in Tomcat 4) but 
>it doesn't seem to be the case. The work-around (removing ejb-client code 
>from web app) is not a solution because it has a lot of web app specific code.
>If I don't copy authentication code to server/lib directory and only keep 
>it in web app Tomcat doesn't find it. That is the case for both versions - 
>4 and 5. To me it suggests a different problem - since JAAS realm declared 
>in web app context it should apply to web application only and therefore 
>it should be looking into webapp not server/lib directory. But that is a 
>different discussion topic altogether.
>Thanks in advance
>CAUTION - This message may contain privileged and confidential information 
>intended only for the use of the addressee(s) named above. If you are not 
>the intended recipient of this message you are notified that any use, 
>dissemination, distribution or reproduction of this message is prohibited. 
>If you have received this message in error please notify Siemens Ltd., ABN 
>98 004 347 880, or Siemens (NZ) Limited immediately. No representation is 
>made that this email or any attachments are free of viruses. Virus 
>Scanning is recommended and is the responsibility of the recipient.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message