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]
