tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reingold Genna <Genna.Reing...@siemens.com>
Subject RE: FW: Configuring JAAS realm for a web appplication (Catalina c lass loader bug)
Date Mon, 08 Nov 2004 05:32:40 GMT
Jake,

Thanks for our reply.

I have tried common/lib scenario. As a matter of fact I have started with
that option. However it produces the same result. 

I have tried to move ejb-client jar out of of web app. But then I run into
the problem when the application uses a class loaded by common class loader
and if the class references another class in the WEB_INF/lib jar (a
different jar) I get NoClassDefError. Effectively the only safe way to
install my application in that scenario is to copy all application jars into
common/lib and that is fundamently wrong.    

What I don't understand is why my set up works in 4.1.29 and doesn't work in
5.0.28.

 

-----Original Message-----
From: Jacob Kjome [mailto:hoju@visi.com] 
Sent: Monday, 8 November 2004 3:52 PM
To: Tomcat Users List
Subject: Re: FW: Configuring JAAS realm for a web appplication (Catalina
class loader bug)


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.

Jake

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

>Hi,
>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
>
>Genna
>
>
>
>
>
>
>
>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: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


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.



Mime
View raw message