RE: static,synchronized and classloaders

2001-06-13 Thread Cox, Charlie
Title: RE: static,synchronized and classloaders I'm not sure what you mean by abc.MyClass and xyz.MyClass as the class in question is in the same package in both contexts. This archive link from Craig McClanahan(thank you Craig) gives a good explaination of classloaders: http://www.mail

Re: static,synchronized and classloaders

2001-06-13 Thread Jeff Trent
Title: RE: static,synchronized and classloaders Are you saying that I don't need different JVMs to handle each of my webapps if I move the JAR files that I have in my classpath down into the lib directory of the webapp? I have a problem in that this JAR I'm using in several of my webapp

RE: static,synchronized and classloaders

2001-06-13 Thread Cox, Charlie
Title: RE: static,synchronized and classloaders That is what I am seeing with my servlets. I have the same class file in each context's web-inf/classes directory and it is keeping the static members independent from the other context. I have a static instance of a helper class in my servlet

Re: static,synchronized and classloaders

2001-06-13 Thread Jeff Trent
Title: RE: static,synchronized and classloaders This is a great lead. I was cursing Tomcat since I thought I was forced to create different JVM configurations for each of my webapps. I'll give it a try and let you know what I find later on today. - jeff - Original Message

Re: static,synchronized and classloaders

2001-06-13 Thread Jeff Trent
Title: RE: static,synchronized and classloaders Well, Charlie, I take that last statement back. I have common.jar in both of my webapps/lib directory, and I'm still seeing the corruption I talked about. I'm not sure if its worth my effort to expand the JAR into the classes directory to see

Re: static,synchronized and classloaders

2001-06-13 Thread Bo Xu
Hi :-) I did a test with TC4.0-b5(standalone, J2SE1.3, winnt40): * cases: - % put the Same MyServlet.class in WEB-INF/classes in Different Context path which has Different Context docBase % put the Same MyServlet.class in the Same MyJar.jar file in WEB-INF/lib in Different

RE: static,synchronized and classloaders

2001-06-13 Thread Cox, Charlie
Title: RE: static,synchronized and classloaders well, I am using TC 3.2.1(win2k,standalone and w/iis, with and without virtual hosts), but it seems to work the same. Also make sure your jar is not in tomcat\lib or your classpath thanks for the thorough test Bo Charlie -Original

Re: static,synchronized and classloaders

2001-06-13 Thread Jeff Trent
test without writing the same code / logic from scratch? thanks, jeff - Original Message - From: Bo Xu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 13, 2001 11:10 AM Subject: Re: static,synchronized and classloaders Hi :-) I did a test with TC4.0-b5(standalone, J2SE1.3

Re: static,synchronized and classloaders

2001-06-13 Thread Bo Xu
June 13, 2001 - Original Message - From: Bo Xu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 13, 2001 11:10 AM Subject: Re: static,synchronized and classloaders Hi :-) I did a test with TC4.0-b5(standalone, J2SE1.3, winnt40): * cases: - % put

RE: static,synchronized and classloaders(was:Java Question)

2001-06-12 Thread Cox, Charlie
Title: RE: static,synchronized and classloaders(was:Java Question) Now is this true for when I have multiple contexts mapped to the same docbase? I have seen on this list that Tomcat loads the classes(in web-inf/classes) independently for each context and passing MyObject class instance

Re: static,synchronized and classloaders(was:Java Question)

2001-06-12 Thread Luba Powell
Title: RE: static,synchronized and classloaders(was:Java Question) If your context points to another virtual machine - yes. On the same virtual machine static is static - Original Message - From: Cox, Charlie To: '[EMAIL PROTECTED]' Sent: Tuesday, June 12, 2001 3

Re: static,synchronized and classloaders(was:Java Question)

2001-06-12 Thread Luba Powell
Title: RE: static,synchronized and classloaders(was:Java Question) Also, look ifidentical files are generated based on 2 different context: abc.MyClass is not the same as xyx.MyClass. If 2 class loaders load from identical class files - JVM verifier should throw the exception before