Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
On 10/10/2009 23:52, André Warnier wrote: Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars Not that it was my thread to begin with, and not thjat it's really dramatic either, but I suppose you guys must realise that you lost me, like, about 15 posts ago ? What, are you being rude again? (Just kidding :-) I think one of the non-obvious points is that the word instance in an object-oriented environment is strictly defined, and must be used with discretion. So, where did we start to lose you? If you'd prefer to continue the discussion off-list, that's o.k. for this off-topic. No, no. I have no qualms about splaying out, for everyone to see, my dismal lack of fundamental Java knowledge, when the comparison is with experts like you two. And I am rather proud of having triggered this fascinating discussion about the finer points of java classes and objects relationships, which without doubt will some day become part of the anthology of Tomcat classloading and application deployment techniques. Or the other way around, I am not quite sure anymore. Is there a page on the Wiki for bookmarking threads that are 'essential reading'? I can't see one, but we ought to create one somewhere. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
2009/10/11 Pid p...@pidster.com: Is there a page on the Wiki for bookmarking threads that are 'essential reading'? I can't see one, but we ought to create one somewhere. There are http://wiki.apache.org/tomcat/FAQ http://wiki.apache.org/tomcat/HowTo http://wiki.apache.org/tomcat/FAQ/Miscellaneous If you want to create some other one, I do not mind. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 10/10/2009 10:26 AM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars Also, the WebappClassLoader has to be able to re-load classes that are updated during runtime. In order to do that, it needs to know what has been loaded and when. Yes, but that's actually done by restarting the webapp, not redefining an existing class. This results in a new instance of WebappClassLoader and a completely new node being created on the classloader tree. Yes, but in order to /detect/ the change, the ClassLoader needs to know which classes it loaded. I wasn't suggesting that the WebappClassLoader re-loads classes individually, but it needs to detect individual changes in .class files and JAR files. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrR7WsACgkQ9CaO5/Lv0PDlKwCeJ7dusfdU2Re15odh5ruvBUqV 3usAnjZ/qERyzL5yQz8aXv6Xnj6B5Rkr =KPmH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars Yes, but in order to /detect/ the change, the ClassLoader needs to know which classes it loaded. I wasn't suggesting that the WebappClassLoader re-loads classes individually, but it needs to detect individual changes in .class files and JAR files. Correct, but that only requires tracking the /source/ of the loaded classes symbolically, not hanging onto a reference to the java.lang.Class instance. The latter is only necessary due to the required violation of the delegation rules. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 10/9/2009 7:14 PM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: tomcat 5.5.25 shared lib and sharing webapp jars PermGen is a place where Class objects often end up Not often - always (in a HotSpot JVM); and not end up - they are allocated there from the start. Note that PermGen is an attribute of the HotSpot JVM; most other JVMs do not have a PermGen. Quite true: I was confusing PermGen with the tenured generation. I forgot that PermGen is basically not part of that. It's poorly named because it's not really a generation per se, but is still called a generation. The webapp itself is irrelevant. A java.lang.Class object (and therefore any code, static members, etc.) can only be dumped from memory when the ClassLoader that loaded it is not referenced by any live object and no live objects are referring to it. That is not true; classes can be unloaded when all instances of the class are unreachable. One additional requirement: the java.lang.Class object itself must also be unreachable. My direct experience that had led me to believe that ClassLoaders keep lists of their loaded Classes is that a WebappClassLoader held across a webapp restart (due to inadequate cleanup by the webapp) results in all Class objects loaded by that WebappClassLoader staying in memory, essentially forever. I have forgotten what sloppy practices we had in our webapp at one time, but they have been fixed so we can reload our webapp all day long and not worry about busting PermGen. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrQhWgACgkQ9CaO5/Lv0PCZNgCfYWUqlmZW2D1My/Lz9iiO/rhT T2cAn0Qs/JNBJ3WF2AEcf65kygzwKS1i =PWj6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars One additional requirement: the java.lang.Class object itself must also be unreachable. True. My direct experience that had led me to believe that ClassLoaders keep lists of their loaded Classes is that a WebappClassLoader held across a webapp restart (due to inadequate cleanup by the webapp) results in all Class objects loaded by that WebappClassLoader staying in memory, essentially forever. I think you are correct about Tomcat's WebappClassLoader; it has to maintain the set of the classes it has loaded since it breaks the normal Java delegation rule, and can't simply ask its parent for the class. The JVM itself keeps track (outside of the heap) of all loaded classes so that classloaders that follow the standard delegation rule don't have to. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 10/10/2009 9:26 AM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars My direct experience that had led me to believe that ClassLoaders keep lists of their loaded Classes is that a WebappClassLoader held across a webapp restart (due to inadequate cleanup by the webapp) results in all Class objects loaded by that WebappClassLoader staying in memory, essentially forever. I think you are correct about Tomcat's WebappClassLoader; it has to maintain the set of the classes it has loaded since it breaks the normal Java delegation rule, and can't simply ask its parent for the class. Is that because the primordial ClassLoader will hand-out references to any class already loaded by any ClassLoader, so if null is returned, then the current ClassLoader knows it needs to do its own loading (if it can)? The JVM itself keeps track (outside of the heap) of all loaded classes so that classloaders that follow the standard delegation rule don't have to. Also, the WebappClassLoader has to be able to re-load classes that are updated during runtime. In order to do that, it needs to know what has been loaded and when. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrQjqcACgkQ9CaO5/Lv0PC4RgCgqpflDSRXQhOFI8uXTT7gqghM W+QAnA6iVa3jOdstaKgzAUspXvYSEQOe =gb1k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars Is that because the primordial ClassLoader will hand-out references to any class already loaded by any ClassLoader, so if null is returned, then the current ClassLoader knows it needs to do its own loading (if it can)? Mostly correct: the API of interest is ClassLoader.findClass(); every ClassLoader instance is supposed to call that method of its parent, and only attempt a load itself if a ClassNotFoundException occurs (null cannot be returned). If its load fails, it must throw a CNFE back to its caller. All of the above assumes standard delegation rules are being followed, which the servlet spec precludes. Also, the WebappClassLoader has to be able to re-load classes that are updated during runtime. In order to do that, it needs to know what has been loaded and when. Yes, but that's actually done by restarting the webapp, not redefining an existing class. This results in a new instance of WebappClassLoader and a completely new node being created on the classloader tree. Note that JSPs are handled differently - there's a separate ClassLoader created for each JSP file, so they can be easily replaced when modified. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 10/10/2009 9:26 AM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars My direct experience that had led me to believe that ClassLoaders keep lists of their loaded Classes is that a WebappClassLoader held across a webapp restart (due to inadequate cleanup by the webapp) results in all Class objects loaded by that WebappClassLoader staying in memory, essentially forever. I think you are correct about Tomcat's WebappClassLoader; it has to maintain the set of the classes it has loaded since it breaks the normal Java delegation rule, and can't simply ask its parent for the class. Is that because the primordial ClassLoader will hand-out references to any class already loaded by any ClassLoader, so if null is returned, then the current ClassLoader knows it needs to do its own loading (if it can)? The JVM itself keeps track (outside of the heap) of all loaded classes so that classloaders that follow the standard delegation rule don't have to. Also, the WebappClassLoader has to be able to re-load classes that are updated during runtime. In order to do that, it needs to know what has been loaded and when. Not that it was my thread to begin with, and not thjat it's really dramatic either, but I suppose you guys must realise that you lost me, like, about 15 posts ago ? :-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars Not that it was my thread to begin with, and not thjat it's really dramatic either, but I suppose you guys must realise that you lost me, like, about 15 posts ago ? What, are you being rude again? (Just kidding :-) I think one of the non-obvious points is that the word instance in an object-oriented environment is strictly defined, and must be used with discretion. So, where did we start to lose you? If you'd prefer to continue the discussion off-list, that's o.k. for this off-topic. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars Not that it was my thread to begin with, and not thjat it's really dramatic either, but I suppose you guys must realise that you lost me, like, about 15 posts ago ? What, are you being rude again? (Just kidding :-) I think one of the non-obvious points is that the word instance in an object-oriented environment is strictly defined, and must be used with discretion. So, where did we start to lose you? If you'd prefer to continue the discussion off-list, that's o.k. for this off-topic. No, no. I have no qualms about splaying out, for everyone to see, my dismal lack of fundamental Java knowledge, when the comparison is with experts like you two. And I am rather proud of having triggered this fascinating discussion about the finer points of java classes and objects relationships, which without doubt will some day become part of the anthology of Tomcat classloading and application deployment techniques. Or the other way around, I am not quite sure anymore. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
