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:[EMAIL PROTECTED]]
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: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
