Quoting Reingold Genna <[EMAIL PROTECTED]>: > 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. >
Well, not the same result when you remove the jar from WEB-INF/lib as I recommended.... as you seem to have later stated below. > 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. > It sounds like you might have to re-think your circular dependencies. You need to make a decision which jars should depend on each other and whether the dependency direction is one way, both ways, or none at all. You can't get away from making this decision no matter the appserver. > What I don't understand is why my set up works in 4.1.29 and doesn't work in > 5.0.28. > I can't explain that. However, I suspect that you tested 4.1.29 on some other machine than what you have 5.0.28 installed upon. I would investigate how the environment might be different. Different classpaths, different ways of starting the server (batch file -vs- a service), etc.... Make sure you try fresh installs of each version with your app and test both in exactly the same way. Then you will be comparing apples to apples and, therefore, getting rid of extraneous variables that might be clouding the investigation. Jake > > > -----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]
