Re: moving all classes to shared
On Sat, Feb 19, 2005 at 06:38:03PM -0800, Oleg wrote: : If I have 200 users deployed on tomcat with 99% using identical : classes, would it be ok to move all classes to shared/classes : directory? Will that give better memory usage? Also, can I later add : the classes that are different directly to WEB-INF/classes and will : they be given priority? You've already received answers to the other points, so I'll address just the last question: it depends With hierarchical classloaders, you can get yourself into a right snit when 1/ there's version skew between the per-webapp class and the one in shared/lib; and 2/ when a class in shared/lib depends on a class that's in the per-webapp area (that is, it can't see a dependent class because it's out of the scope of the current classloader). IIRC, both result in NoClassDefFoundError, and both can be a mess to sort out if you don't know in advance where to start looking. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving all classes to shared
Well regarding #1 from what I understand the class in webapp web-inf will take priority, however, I can see how #2 can be a problem, but, does it only work one way? Meaning a class in sared/classes will not see webapp/web-inf/classes, so down the hierarchy, however, it will work just fine going up, so class in webapp will see classes in shared? Thank you Oleg On Mon, 21 Feb 2005 10:54:45 -0600, QM [EMAIL PROTECTED] wrote: On Sat, Feb 19, 2005 at 06:38:03PM -0800, Oleg wrote: : If I have 200 users deployed on tomcat with 99% using identical : classes, would it be ok to move all classes to shared/classes : directory? Will that give better memory usage? Also, can I later add : the classes that are different directly to WEB-INF/classes and will : they be given priority? You've already received answers to the other points, so I'll address just the last question: it depends With hierarchical classloaders, you can get yourself into a right snit when 1/ there's version skew between the per-webapp class and the one in shared/lib; and 2/ when a class in shared/lib depends on a class that's in the per-webapp area (that is, it can't see a dependent class because it's out of the scope of the current classloader). IIRC, both result in NoClassDefFoundError, and both can be a mess to sort out if you don't know in advance where to start looking. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - 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]
Re: moving all classes to shared
On Mon, Feb 21, 2005 at 11:21:01AM -0800, Oleg wrote: : Well regarding #1 from what I understand the class in webapp web-inf : will take priority, however, I can see how #2 can be a problem, but, : does it only work one way? Meaning a class in sared/classes will not : see webapp/web-inf/classes, so down the hierarchy, however, it will : work just fine going up, so class in webapp will see classes in : shared? Correct -- the per-webapp classloader is the child of the shared/lib classloader. (This is an oversimplification but please bear with me.) Really, there are more than two classloaders involved, forming several parent/child relationships in a hierarchy... Try to think of it as the GoF Chain of Responsiblity pattern: when the per-webapp classloader can't find a class, it delegates (passes the request) to its parent. This keeps going until you hit a classloader that can successfully load the class, or until the innermost classloader -- which doesn't delegate to anyone else -- gives up and says there's no such class. Going the other way thus isn't possible: that innermost (parent) classloader can't see what its children see, and so on. If a class under shared/lib needs access to (depends on) a class in a child classloader, it will never find it, and the system throws a NoClassDefFoundError. It's for a similar reason one webapp can't see another webapp's classes: they only have a relationship with their parent classloader, and not that of their siblings. -QM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving all classes to shared
Hmm, quick question, do you know of a reason why this ould not work for Struts, I did it and for some reason I get an error org.apache.struts.action.RequestProcessor - ERROR - No action instance for path /selectTiles could be created this class was moved to shared. Thansk, Oleg On Mon, 21 Feb 2005 14:39:52 -0600, QM [EMAIL PROTECTED] wrote: On Mon, Feb 21, 2005 at 11:21:01AM -0800, Oleg wrote: : Well regarding #1 from what I understand the class in webapp web-inf : will take priority, however, I can see how #2 can be a problem, but, : does it only work one way? Meaning a class in sared/classes will not : see webapp/web-inf/classes, so down the hierarchy, however, it will : work just fine going up, so class in webapp will see classes in : shared? Correct -- the per-webapp classloader is the child of the shared/lib classloader. (This is an oversimplification but please bear with me.) Really, there are more than two classloaders involved, forming several parent/child relationships in a hierarchy... Try to think of it as the GoF Chain of Responsiblity pattern: when the per-webapp classloader can't find a class, it delegates (passes the request) to its parent. This keeps going until you hit a classloader that can successfully load the class, or until the innermost classloader -- which doesn't delegate to anyone else -- gives up and says there's no such class. Going the other way thus isn't possible: that innermost (parent) classloader can't see what its children see, and so on. If a class under shared/lib needs access to (depends on) a class in a child classloader, it will never find it, and the system throws a NoClassDefFoundError. It's for a similar reason one webapp can't see another webapp's classes: they only have a relationship with their parent classloader, and not that of their siblings. -QM - 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]
Re: moving all classes to shared
From: Oleg [EMAIL PROTECTED] Hmm, quick question, do you know of a reason why this ould not work for Struts, I did it and for some reason I get an error org.apache.struts.action.RequestProcessor - ERROR - No action instance for path /selectTiles could be created this class was moved to shared. You can't share the Struts libraries across multiple webapps. (Well, you can, but it probably won't work, and it's not a supported configuration-- the developers specifically warn against it.) Scroll down to section 5.5: http://struts.apache.org/userGuide/configuration.html -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: moving all classes to shared
I'm not sure what you're getting at here. The number of users are irrelevant to the classes. You should only use shared/classes if the classes have to be shared across web apps. Although this is not usually advised as it is good practice to keep web apps self contained. WEB-INF/classes would take precedence over shared/classes but I still don't see what you are trying to achieve. My understanding (I'm sure someone will correct me if i'm wrong) of the shared is that each class will be loaded into the classloader of each webapp so no memory would be saved, if you chose to use this area for sharing classes accross webapps. If you wanted to save memory then the common/classes is where you should put your classes. This will only classload 1 copy of the class. Ta Matt -Original Message- From: Oleg [mailto:[EMAIL PROTECTED] Sent: Sunday, February 20, 2005 2:38 AM To: Tomcat Users List Subject: moving all classes to shared If I have 200 users deployed on tomcat with 99% using identical classes, would it be ok to move all classes to shared/classes directory? Will that give better memory usage? Also, can I later add the classes that are different directly to WEB-INF/classes and will they be given priority? Thank you Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Any opinions expressed in this E-mail may be those of the individual and not necessarily the company. This E-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this E-mail in error and that any use or copying is strictly prohibited. If you have received this E-mail in error please notify the beCogent postmaster at [EMAIL PROTECTED] Unless expressly stated, opinions in this email are those of the individual sender and not beCogent Ltd. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving all classes to shared
Dale, Matt wrote: I'm not sure what you're getting at here. The number of users are irrelevant to the classes. You should only use shared/classes if the classes have to be shared across web apps. Although this is not usually advised as it is good practice to keep web apps self contained. WEB-INF/classes would take precedence over shared/classes but I still don't see what you are trying to achieve. My understanding (I'm sure someone will correct me if i'm wrong) of the shared is that each class will be loaded into the classloader of each webapp so no memory would be saved, if you chose to use this area for sharing classes accross webapps. http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html I doubt that classes in shared lib are existing multiple times per webapp. I'm quite sure the exist per tomcat instance... The difference is that common lib is available to both Tomcat and the webapps. Shared lib is not available to the Tomcat classes. Typically one places the jdbc driver into common lib, because Tomcat needs that when using the JNDI pooling. If you just use old JDBC style it should work in shared lib or even web-inf/lib. The interesting part is that shared lib is relative to catalina base, not catalina home, unlike common lib... Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
