DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684 WEB-INF/lib jar file loading and operations problems. [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-01-31 03:42 --- *** Bug 6139 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684 WEB-INF/lib jar file loading and operations problems. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-01-24 08:00 --- Reporter says that it's working now. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fw: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
FYI for the 4.x group mostly. He is refering to bug #5390, which it seems is still alive in 4.x. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 23, 2002 10:48 PM Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Hi Bill, It's been a week now and everything is AOK. Please close out this bug. Thanks for your great job in pursuing a fix to this problem. Truly appreciate this. BTW, I'm starting on an implementation of a Tomcat 4 shared jvm. I ran all of my jar scenarios against Tomcat 4 and it works great. It does lock jar files (from deletion only) but only when the context is in use. If you stop the context using the /manager app, it frees up the jar files as well as any files and directories associated with the context. If you replace jar files, it's auto detection works excellent. My only gripe with tomcat 4 is it has the same jspinit problem that you fixed and it's ajp13 connector does not do tomcat authentication. So I just have to wait until these problems are fixed. Thanks again for everything. Regards, Mike - Original Message - From: [EMAIL PROTECTED] To: Bill Barker [EMAIL PROTECTED] Sent: Thursday, January 17, 2002 7:42 PM Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Hi Bill, It's looking real excellent. Your changes passed all my tests. I felt comfortable enough with the 1/16 build that I installed it on my production server last night. I emailed my customers whom I've been working on this issue to give it a spin. One developer already responded with positive results. So far so good. Let's give it a week of usage before we close this issue. I'll email you in about a week once all the results are in. Once again, thanks for all of your help. Regards, Mike - Original Message - From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 16, 2002 9:00 AM Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. I checked in a patch to DependClassLoader12 last night (which should appear in tonight's nightly) that seems to make jar replacement much better at least with my very limited testing. It was leaving the jar file open whenever it had to define a new Package. From your description, it sounds like it would eventually get garbage collected, but it may take quite a while. While servlets and beans are loaded the same way, if the package contains a load-on-startup servlet it would get loaded very early on (and define the package for everyone else). This means that the open jar file is very likely to be finalized by the time Tomcat actually starts serving pages. You are also correct that the ProtectionDomain is still set even when using SimpleClassLoader. That is because DependClassLoader12 is the one that actually defines the class (and it sets the PD). SimpleClassLoader is only used to load resources (even under Java 1.1). It isn't used to load classes by itself. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 2:41 PM Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Hi Bill, Oooh. I spoke up to soon. After further testing, I still have the same problem BUT ONLY with regular bean or taglib classes in the jar. Servlet classes in a jar are working great. But as soon as a bean class is loaded from the jar, the same problems exist -- locked jar or 404 resulting from a class not found exception and it also affects the servlet classes from that point on. Even if I restart the context (remove then add), the same problems exist. I'm trying to research the problem but I got to admit that the tomcat code is pretty hefty to trace through due to my lack of experience with the code. Are servlet classes loaded from a jar any different from regular classes loaded from a jar? Any thoughts? Regards, Mike - Original Message - From: [EMAIL PROTECTED] To: Bill Barker [EMAIL PROTECTED] Sent: Friday, January 11, 2002 8:55 PM Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Bill, First I'd like to say that you are darn good. Everything worked perfectly. What can I say. Thank you very much. I will put it through more extensive testing but my initial tests which was to delete the jar, replace the jar, restart contexts with jar reloading, servlet reloading, and full reloading all worked. I do have one thing to clear up in my mind in understanding this class loader mechanism. The simpleclassloader has one deficiency
Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
I checked in a patch to DependClassLoader12 last night (which should appear in tonight's nightly) that seems to make jar replacement much better at least with my very limited testing. It was leaving the jar file open whenever it had to define a new Package. From your description, it sounds like it would eventually get garbage collected, but it may take quite a while. While servlets and beans are loaded the same way, if the package contains a load-on-startup servlet it would get loaded very early on (and define the package for everyone else). This means that the open jar file is very likely to be finalized by the time Tomcat actually starts serving pages. You are also correct that the ProtectionDomain is still set even when using SimpleClassLoader. That is because DependClassLoader12 is the one that actually defines the class (and it sets the PD). SimpleClassLoader is only used to load resources (even under Java 1.1). It isn't used to load classes by itself. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 2:41 PM Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Hi Bill, Oooh. I spoke up to soon. After further testing, I still have the same problem BUT ONLY with regular bean or taglib classes in the jar. Servlet classes in a jar are working great. But as soon as a bean class is loaded from the jar, the same problems exist -- locked jar or 404 resulting from a class not found exception and it also affects the servlet classes from that point on. Even if I restart the context (remove then add), the same problems exist. I'm trying to research the problem but I got to admit that the tomcat code is pretty hefty to trace through due to my lack of experience with the code. Are servlet classes loaded from a jar any different from regular classes loaded from a jar? Any thoughts? Regards, Mike - Original Message - From: [EMAIL PROTECTED] To: Bill Barker [EMAIL PROTECTED] Sent: Friday, January 11, 2002 8:55 PM Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Bill, First I'd like to say that you are darn good. Everything worked perfectly. What can I say. Thank you very much. I will put it through more extensive testing but my initial tests which was to delete the jar, replace the jar, restart contexts with jar reloading, servlet reloading, and full reloading all worked. I do have one thing to clear up in my mind in understanding this class loader mechanism. The simpleclassloader has one deficiency as it does not define the protection domain in the define class method. But as far as I can tell, dependentclassloader12 takes over and loads the class which will defineclass with the protection domain. It appears that simpleclassloader is used by dependentclassloader for getting the resources. DO I UNDERSTAND THIS CORRECTLY? So the hierarchy is webapp loader (parent2), simpleclassloader (parent) then dependentclassloader. Thanks again for your help and support. Aloha, Mike - Original Message - From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 2:56 PM Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. I checked in the change to LoaderInterceptor11 to allow it to optionally use the SimpleClassLoader (which is mostly the code from AdaptiveClassLoader) even under Java2. It should show up in tonight's nightly. To enable it, you set the use11Loader=true attribute on the LoaderInterceptor11 element in server.xml and re-start Tomcat. Hopefully this will be more jar-friendly on reloads. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 05, 2002 6:47 PM Subject: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Hi Bill, I downloaded the 3.3 source code and did some sniffing. From what I can tell, here is why 3.2 works and 3.3 does not work with regards to jar files and it's classes. TC 3.2 - LoaderInterceptor uses new instances of the AdaptiveClassLoader (and subclasses for jdk12 support) to handle a context init. This classloader overrides classloader methods and does everything correctly. That's why it has no problem with loading classes from jar files using zip methods or jar file locking. It closes it's jar files after reading it's class files. TC 3.3 - LoaderInterceptor11 uses new instances of the jdk's URLClassloader. What more can I say. Tomcat has no control over URLClassloader and it's operations. The problems you and Bojan pointed out are out of Tomcat's control. I'd like to know what you think. If I'm correct, the question is whether
Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
I checked in the change to LoaderInterceptor11 to allow it to optionally use the SimpleClassLoader (which is mostly the code from AdaptiveClassLoader) even under Java2. It should show up in tonight's nightly. To enable it, you set the use11Loader=true attribute on the LoaderInterceptor11 element in server.xml and re-start Tomcat. Hopefully this will be more jar-friendly on reloads. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 05, 2002 6:47 PM Subject: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Hi Bill, I downloaded the 3.3 source code and did some sniffing. From what I can tell, here is why 3.2 works and 3.3 does not work with regards to jar files and it's classes. TC 3.2 - LoaderInterceptor uses new instances of the AdaptiveClassLoader (and subclasses for jdk12 support) to handle a context init. This classloader overrides classloader methods and does everything correctly. That's why it has no problem with loading classes from jar files using zip methods or jar file locking. It closes it's jar files after reading it's class files. TC 3.3 - LoaderInterceptor11 uses new instances of the jdk's URLClassloader. What more can I say. Tomcat has no control over URLClassloader and it's operations. The problems you and Bojan pointed out are out of Tomcat's control. I'd like to know what you think. If I'm correct, the question is whether or not you folks are going to punt to Sun. This will let me know what my course of action will be. Regards, Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 05, 2002 12:34 PM Subject: Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Bill, Is this patch in the 1/4 nightly build of 3.3? Which .java file was it? Regards, Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 04, 2002 4:50 PM Subject: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684 WEB-INF/lib jar file loading and operations problems. --- Additional Comments From [EMAIL PROTECTED] 2002-01-04 18:50 --- There was a missing close statement in the app-ClassLoader. I've added it in, so that the jar file shouldn't stay open. This may fix part 1 (since 3.3 typically does GC much less often then 3.2). It is possible (if very unlikely) that being able to delete the jar file may help with 2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
I don't see any problem with adding an option to LoaderInterceptor11 to force it to use a SimpleClassLoader (the descendent of AdaptiveClassLoader) even on a Java2 platform. There are some trade-offs, since SimpleClassLoader is really meant for Java1.1 platforms, but for a lot of people they don't look too serious. This is a little bigger decision than I want to make on my own, so I've included the Developer List in the reply in case one of the other developers has comments/suggestions. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 05, 2002 6:47 PM Subject: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Hi Bill, I downloaded the 3.3 source code and did some sniffing. From what I can tell, here is why 3.2 works and 3.3 does not work with regards to jar files and it's classes. TC 3.2 - LoaderInterceptor uses new instances of the AdaptiveClassLoader (and subclasses for jdk12 support) to handle a context init. This classloader overrides classloader methods and does everything correctly. That's why it has no problem with loading classes from jar files using zip methods or jar file locking. It closes it's jar files after reading it's class files. TC 3.3 - LoaderInterceptor11 uses new instances of the jdk's URLClassloader. What more can I say. Tomcat has no control over URLClassloader and it's operations. The problems you and Bojan pointed out are out of Tomcat's control. I'd like to know what you think. If I'm correct, the question is whether or not you folks are going to punt to Sun. This will let me know what my course of action will be. Regards, Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 05, 2002 12:34 PM Subject: Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Bill, Is this patch in the 1/4 nightly build of 3.3? Which .java file was it? Regards, Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 04, 2002 4:50 PM Subject: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684 WEB-INF/lib jar file loading and operations problems. --- Additional Comments From [EMAIL PROTECTED] 2002-01-04 18:50 --- There was a missing close statement in the app-ClassLoader. I've added it in, so that the jar file shouldn't stay open. This may fix part 1 (since 3.3 typically does GC much less often then 3.2). It is possible (if very unlikely) that being able to delete the jar file may help with 2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684 WEB-INF/lib jar file loading and operations problems. --- Additional Comments From [EMAIL PROTECTED] 2002-01-04 01:47 --- For problem 1 and 2: In tomcat 3.2.3, these problems did not exist. You could delete, rename, and replace jars even while the context was running. If you deleted a jar, tomcat would throw a: 2002-01-03 23:31:37 - Ctx( www.foodomain.com:/examples ): Exception in: R ( /examples + /servlet/HelloWorldExample + null) - java.lang.IllegalArgumentException: Repository D:\home\foodomain\www\examples\WEB-INF\lib\examplesdir2.jar doesn't exist! After deleting a live jar (this is an extreme), a remove and add of the context will restore everything perfectly. No need to shutdown tomcat/jvm. To verify this, I reloaded tomcat 3.2.3 and re-tested everything. It all worked like before. The jvm is still the same at 1.3.1_01. Can you folks look into it? I really like 3.3 classloading scheme so I dont want to go back to 3.2. Any comments? Thanks Mike -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684
WEB-INF/lib jar file loading and operations problems.
--- Additional Comments From [EMAIL PROTECTED] 2002-01-04 02:54 ---
One workaround is to use straight classes rather then jars (i.e. unpack your
jars in the classes directory).
As for the ZIP class problems, I've submitted this bug to Sun a number of times
and I was able to replicate it on Windows and Linux. But, they wouldn't buy it.
The following sample program illustrates the problem:
--
import java.io.*;
import java.net.*;
import java.util.*;
class ZipFileTest extends ClassLoader{
public static void main(String argv[]){
LineNumberReader in=new LineNumberReader(new
InputStreamReader(System.in));
while(true){
Properties p=new Properties();
try{
// Get the resource using the first ClassLoader object (first
set)
ZipFileTest t=new ZipFileTest();
System.err.println(t=+t);
InputStream i=t.getResourceAsStream(/some/properties/file.props);
System.err.println(i=+i);
p.load(i);
p.save(System.out,);
// Get rid of the objects
i=null; t=null; p=null;
// Wait for user input while replacing the jar
in.readLine();
} catch(Throwable t){
System.out.println(t);
t.printStackTrace(System.out);
System.exit(1);
}
}
}
}
--
All you need to do is have a JAR file with a properties files inside it (make
sure you change the name). Run the program and it will print out the properties
file. After that it'll wait for your input. At that point replace the JAR file
with another JAR file that contains the same properties file, but is otherwise
different. After the input is received, the program will fail while reading the
JAR file, given the JAR file is sufficiently different (i.e. at times there will
be no problems).
Bojan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684 WEB-INF/lib jar file loading and operations problems. --- Additional Comments From [EMAIL PROTECTED] 2002-01-04 18:50 --- There was a missing close statement in the app-ClassLoader. I've added it in, so that the jar file shouldn't stay open. This may fix part 1 (since 3.3 typically does GC much less often then 3.2). It is possible (if very unlikely) that being able to delete the jar file may help with 2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684 WEB-INF/lib jar file loading and operations problems. --- Additional Comments From [EMAIL PROTECTED] 2002-01-03 23:03 --- 1) This is really a Windows issue, since *nix machines happily let you delete open files. (and Tomcat delegates which files are open to java.lang.Classloader). 2) This is a known problem, but it is basically a bug in java.util.zip. (and, yes, this one effects *nix boxes as well). What happens is that the JVM holds on to it's old index of the jar file (which is no longer valid of course), so it is unable to reload the class when Tomcat asks it to. My understanding of the feeling among the developers is that they'd really rather that Sun fix this one than re-write java.util.zip. AFAIK, this is still an issue in Java 1.4 Beta, but I might be wrong. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
