FOLLOW-UP: Sharing the JSTL JARs and Classloading
Hi all, On Jan. 22 I posted a message to this group, ?? Sharing the JSTL JARS and Classloading ??, where I described a problem I was having with the JSTL JARs. It seemed that when I put the JSTL JARs (standard.jar and jstl.jar) in Tomcat's shared/lib TC could not find them, contrary to the TC documentation. I know what the problem was. It turns out it was my fault. I was using a value of CATALINA_BASE that was not the same as CATALINA_HOME. Tomcat's documentation says that Shared/lib is relative to CATALINA_BASE. So, I'm sorry to all you who read my post and tried to help me solve the problem. It was all my fault after all for not having read the Tomcat documentation well enough. I am sorry to those of you whose time I wasted. I'll be more careful in the future. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOLLOW-UP: Sharing the JSTL JARs and Classloading
Thank you for posting the follow up. So often people solve their problems and don't post the solution. Then when you do a search you may find the issue you were looking for but not the solution. Don't worry we have all goofed. Doug - Original Message - From: Tony LaPaso [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Monday, January 31, 2005 9:21 PM Subject: FOLLOW-UP: Sharing the JSTL JARs and Classloading Hi all, On Jan. 22 I posted a message to this group, ?? Sharing the JSTL JARS and Classloading ??, where I described a problem I was having with the JSTL JARs. It seemed that when I put the JSTL JARs (standard.jar and jstl.jar) in Tomcat's shared/lib TC could not find them, contrary to the TC documentation. I know what the problem was. It turns out it was my fault. I was using a value of CATALINA_BASE that was not the same as CATALINA_HOME. Tomcat's documentation says that Shared/lib is relative to CATALINA_BASE. So, I'm sorry to all you who read my post and tried to help me solve the problem. It was all my fault after all for not having read the Tomcat documentation well enough. I am sorry to those of you whose time I wasted. I'll be more careful in the future. Thanks. - 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: ?? Sharing the JSTL JARS and Classloading ??
Tony LaPaso wrote: Incidentally, in reading the Tomcat docs for Classloading, it seems that any classes in a web app's lib directory *should* be able to see classes in the shared/lib directory. Similarly, any classes in shared/lib *should* be able to see what's in common/lib. This works as you expect. I just tested it with a clean TC5 build from CVS. That being said I noticed the following whilst I was testing which may help: - I needed to clean out the work directory for my app between each test. - I needed to restart Tomcat for each test. If I didn't do both of the above then various caches (already loaded classes, JSPs that have already been compiled, etc) all contributed to weird results. angry-rant The crappy, incomplete Tomcat documentation strikes again. One of the bad things about these open source projects is that since no one owns them no one has responsibility to work on anything except what they're interested in. The result is often neglected, shoddy and incomplete documentation. /angry-rant You are as much of the Tomcat community as anyone else. If you know somewhere where the docs are wrong (which you must do to be able to call them crappy and incomplete - and by implication neglected and shoddy) why not redirect your energy from futile ranting into creating patches to improve the documentation and contribute to the community. So, again, it seems weird that putting the JSTL JARs in common/lib works fine while putting them in shared/lib doesn't. When I put them in shared/lib I get the exception shown below. From the exception below it seems to me that the classes in common/lib (e.g., javax.servlet.http.HttpServlet) do not have access to classes in shared/lib (e.g., org.apache.taglibs.standard.tag.rt.core.ForEachTag) although the classes in common/lib *DO* obviously have access to classes in a web app's lib directory. If only the classloader docs were better In terms of the hierarchy, the docs are right. Perhaps what needs to be added is the circumstances where restarts (app or tomcat) are required for changes to take effect. For the record, my own view is that the increased effort required to manage shared jars is rarely worth the disk space and memory it saves. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
Wendy Smoak wrote: From: Tony LaPaso [EMAIL PROTECTED] You have some good points, Jake. Thank you for the response. If you happen to run across the statement from Craig M. regarding Struts I'd like to see it. http://struts.apache.org/faqs/kickstart.html#jar The struts.jar file MUST be in each webapp, and not in any common location. Disk space and memory are cheap, I'd rather each webapp be a self-contained entity than to have to bother with making sure each server has the right things in various places. Not to mention that if I want to play with a newer version of some library, I don't risk breaking existing apps by replacing the common version, nor confusing the class loader by having both the old and new versions on the classpath. One other note - Tomcat gives you a framework contract, a contract defined by JSP/Servlet specification. There is no mention of JSTL in it. Thus, it is unwise to make it shared, since it involves making the JSTL more internal than external, from Tomcat's point of view. The situation with JDBC drivers, for instance, is slightly different. For use with DataSource mechanism, you have to place JDBC driver in shared area. But, on the other hand, DataSource, although not a part of JSP/Servlet specification, is not exactly external to the whole story. I understand the desire behind the original idea. I build packages myself and that usually leads me to not placing one content in several places. How about placing the JARs someplace public, OUTSIDE Tomcat, and making symbolic links in the web application's area? Again, that WILL make the web application in question dependant on some JARs not present in the package. If you're prepared to make your own RPMs no big deal. So, are you? :-) Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
Mark, When you cleaned out the caches (by deleting the work directory) were you able to move the standard.jar and jstl.jar to shared/lib and then be able to use JSTL? I did that -- I deleted the 'work' directory and then moved the JARs from common/lib to shared/lib and re-started TC. Now I have the exception below. Is the JSP compiler not looking using shared/lib classloader, I wonder? org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:50) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:411) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:118) org.apache.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:316) org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:147) org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:418) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:483) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1539) org.apache.jasper.compiler.Parser.parse(Parser.java:126) org.apache.jasper.compiler.ParserController.doParse(ParserController.java:220) org.apache.jasper.compiler.ParserController.parse(ParserController.java:101) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203) org.apache.jasper.compiler.Compiler.compile(Compiler.java:495) org.apache.jasper.comp! iler.Compiler.compile(Compiler.java:476) org.apache.jasper.compiler.Compiler.compile(Compiler.java:464) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802)- Original Message -From: Mark Thomas [EMAIL PROTECTED]To: Tomcat Users List tomcat-user@jakarta.apache.orgSent: Sunday, January 23, 2005 9:21 AMSubject: Re: ?? Sharing the JSTL JARS and Classloading ?? Tony LaPaso wrote: Incidentally, in reading the Tomcat docs for Classloading, it seemsthat any classes in a web app's lib directory *should* be able to seeclasses in the shared/lib directory. Similarly, any classes inshared/lib *should* be able to see what's in common/lib. This works as you ! expect. I just tested it with a clean TC5 build fromCVS. That being sa id I noticed the following whilst I was testing which mayhelp: - I needed to clean out the work directory for my app between each test. - I needed to restart Tomcat for each test. If I didn't do both of the above then various caches (already loadedclasses, JSPs that have already been compiled, etc) all contributed to weirdresults. angry-rant The crappy, incomplete Tomcat documentation strikes again. One of the badthings about these open source projects is that since no one owns them noone has responsibility to work on anything except what they're interestedin. The result is often neglected, shoddy and incomplete documentation. /angry-rant You are as much of the Tomcat community as anyone else. If you knowsomewhere where the docs are wrong (which you must do to be able to callthem crappy and incomplete - and by implication neglected and shoddy) whynot redirect your energy from futile ranting into creating patches toimprove the documentation and contribute t! o the community. So, again, it seems weird that putting the JSTL JARs in common/libworks fine while putting them in shared/lib doesn't. When I put them inshared/lib I get the exception shown below. From the exception below itseems to me that the classes in common/lib (e.g.,javax.servlet.http.HttpServlet) do not have access to classes inshared/lib (e.g., org.apache.taglibs.standard.tag.rt.core.ForEachTag)although the classes in common/lib *DO* obviously have access to classesin a web app's lib directory. If only the classloader docs were better In terms of the hierarchy, the docs are right. Perhaps what needs to beadded is the circumstances where restarts (app or tomcat) are required forchanges to take effect. For the record, my own view is that the increased effort required tomanage shared jars is rarely worth the disk space and memory it saves. Mark - To unsubscribe, e-mai! l: [EMAIL PROTECTED] For additional commands , e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
- Original Message - From: Nikola Milutinovic [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Sunday, January 23, 2005 12:32 PM Subject: Re: ?? Sharing the JSTL JARS and Classloading ?? One other note - Tomcat gives you a framework contract, a contract defined by JSP/Servlet specification. There is no mention of JSTL in it. Thus, it is unwise to make it shared, since it involves making the JSTL more internal than external, from Tomcat's point of view. Nic, You are right: Tomcat provides a contract via it's implementation of the Servlet/JSP spec and the JSTL has absolutely nothing to do with it. Tomcat *also*, however, provides an alleged facilty (shared/lib) for the sharing of JAR file across web applications. This capability is independent of the Servlet/JSP specs but it is supposed to work with Tomcat. There's a more important issue at work here than whether or not I have to put the JARs in common/lib or shared/lib: When writing code it's considered a bad practice (and I think, rightfully so) to copy and paste the same code to various locations. Instead, we factor out common behavior into separate classes or methods. There's an analogous idea involved here -- instead of copying and pasting the same JARs across many web applications it makes more sense (to me, anyway), to factor out these JARs and make them centrally available. Having said that, I also realize the code within the JARs must be written such that the classes can be shared. Think of .so files or .DLL files. With .DLL files, for example, Windows will share the library's contents across several processes rather than load the same DLL each time for every process. I think this is a good strategy, again, assuming the classes in the JAR were written so as to be shared. It's not a matter of disk or memory space, per se, it's more a matter of administrative convenience. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
Tony LaPaso wrote: There's a more important issue at work here than whether or not I have to put the JARs in common/lib or shared/lib: When writing code it's considered a bad practice (and I think, rightfully so) to copy and paste the same code to various locations. Instead, we factor out common behavior into separate classes or methods. There's an analogous idea involved here -- instead of copying and pasting the same JARs across many web applications it makes more sense (to me, anyway), to factor out these JARs and make them centrally available. Having said that, I also realize the code within the JARs must be written such that the classes can be shared. The flip side of that of course is that you'll potentially run into the same problem as Windows: DLL Hell, although it'll be JAR Hell now :) The point about administrative simplicity is well-taken, but I've always been of the mindset that I'd rather have the JARs repeated in each webapp because then if I have to change a JAR version for a particular app I don't have to go and make sure all the other apps work with that version too. Same problem with DLLs... how many times have you had a version conflict with MS Common Controls? Maybe not recently because some work has been done to alleviate this situation, but certainly in the past is arose all the time. The same could happen if you make JARs shared across webapps. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
Tony LaPaso wrote: Mark, When you cleaned out the caches (by deleting the work directory) were you able to move the standard.jar and jstl.jar to shared/lib and then be able to use JSTL? Yes. I did that -- I deleted the 'work' directory and then moved the JARs from common/lib to shared/lib and re-started TC. Now I have the exception below. Is the JSP compiler not looking using shared/lib classloader, I wonder? It is working for me (but I am using the latest CVS code for 5.5.x). Maybe a configuration problem? Not sure what could cause this though. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
Mark Thomas wrote: Tony LaPaso wrote: Mark, When you cleaned out the caches (by deleting the work directory) were you able to move the standard.jar and jstl.jar to shared/lib and then be able to use JSTL? Yes. I did that -- I deleted the 'work' directory and then moved the JARs from common/lib to shared/lib and re-started TC. Now I have the exception below. Is the JSP compiler not looking using shared/lib classloader, I wonder? It is working for me (but I am using the latest CVS code for 5.5.x). Maybe a configuration problem? Not sure what could cause this though. Just to be 100% sure I built 5.0.30 from CVS and ran my very simple test case. The test case passed. This now looks very much like a configuration problem, although I still don't have a clue what would cause the behaviour you are seeing. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
Tony LaPaso ha scritto: Hi all, I'm using TC 5.0.30. JSTL Is working fine -- I have the standard.jar and jstl.jar files in my WEB-INF/lib directory. The problem is that I have several web applications that use JSTL and therefore several WEB-INF/lib directories. Rather than copy the aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put them in one central location and have them available for *ALL* web applications. I use $CATALINA_HOME/common/lib/ ad it's works. I hope that this is also formally correct edoardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
On Sat, Jan 22, 2005 at 01:24:54AM -0600, Tony LaPaso wrote: : The problem is that I have several web applications that use JSTL and : therefore several WEB-INF/lib directories. Rather than copy the : aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put : them in one central location and have them available for *ALL* web : applications. Webapps are supposed to be self-contained, and as such, it's considered a best practice to pack up a webapp with all the JARs it needs. If it's a hassle to copy the JARs around by hand, why not fold that into an automated build process? -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: ?? Sharing the JSTL JARS and Classloading ??
Not all libraries are written in a way that allows for them to be used from different webapps. Struts has a statement on this written by Craig McClanahan, but I can't find it at the moment. The gist of it is that Struts (at least with 1.1) cannot be guaranteed to work properly if placed in a shared classloader. One example of where this might be problematic is with non-final static variables. If it they get changed by one app, the other app sees the change. Usually, this is not the desired behavior as it will make each app using the shared library behave in unpredictable ways. Anyhow, what error are you getting when you add the library to the shared classloader? I haven't looked at the classloader hierarchy in Tomcat for a little while, but it is possible that shared/lib cannot see common/lib, and if there are libraries that standard.jar and jstl.jar depend on libraries that exist in common/lib, then you might get the error you are seeing. Jake At 01:24 AM 1/22/2005 -0600, you wrote: Hi all, I'm using TC 5.0.30. JSTL Is working fine -- I have the standard.jar and jstl.jar files in my WEB-INF/lib directory. The problem is that I have several web applications that use JSTL and therefore several WEB-INF/lib directories. Rather than copy the aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put them in one central location and have them available for *ALL* web applications. According to the crappy Tomcat documentation that's never updated, I should be able to put the JARs in $CATALINA_HOME/shared/lib. Unfortunately, that doesn't seem to work with these two JARs for some reason. Instead, I have to put them in $CATALINA_HOME/common/lib (which seems to work, for some reason). Why can't I just put these two JARs in $CATALINA_HOME/shared/lib and have them shared across all web applications, as the Tomcat documentation on Classloading indicates I should be able to? It seems very odd that I can either copy the JARs to every WEB-INF/lib directory *OR* put them in $CATALINA_HOME/common/lib, but not put them $CATALINA_HOME/shared/lib. Thanks - 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: ?? Sharing the JSTL JARS and Classloading ??
Call me a minimalist but I don't like the idea of having the same JAR file duplicated if I don't have to. It takes more memory since each web app's classloader needs to have the same classes in memory. It seems much cleaner to have the JARs in one central location. - Original Message - From: QM [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Saturday, January 22, 2005 8:57 AM Subject: Re: ?? Sharing the JSTL JARS and Classloading ?? On Sat, Jan 22, 2005 at 01:24:54AM -0600, Tony LaPaso wrote: : The problem is that I have several web applications that use JSTL and : therefore several WEB-INF/lib directories. Rather than copy the : aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put : them in one central location and have them available for *ALL* web : applications. Webapps are supposed to be self-contained, and as such, it's considered a best practice to pack up a webapp with all the JARs it needs. If it's a hassle to copy the JARs around by hand, why not fold that into an automated build process? -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: ?? Sharing the JSTL JARS and Classloading ??
You have some good points, Jake. Thank you for the response. If you happen to run across the statement from Craig M. regarding Struts I'd like to see it. Incidentally, in reading the Tomcat docs for Classloading, it seems that any classes in a web app's lib directory *should* be able to see classes in the shared/lib directory. Similarly, any classes in shared/lib *should* be able to see what's in common/lib. angry-rant The crappy, incomplete Tomcat documentation strikes again. One of the bad things about these open source projects is that since no one owns them no one has responsibility to work on anything except what they're interested in. The result is often neglected, shoddy and incomplete documentation. /angry-rant So, again, it seems weird that putting the JSTL JARs in common/lib works fine while putting them in shared/lib doesn't. When I put them in shared/lib I get the exception shown below. From the exception below it seems to me that the classes in common/lib (e.g., javax.servlet.http.HttpServlet) do not have access to classes in shared/lib (e.g., org.apache.taglibs.standard.tag.rt.core.ForEachTag) although the classes in common/lib *DO* obviously have access to classes in a web app's lib directory. If only the classloader docs were better exception javax.servlet.ServletException: org.apache.taglibs.standard.tag.rt.core.ForEachTag org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:846) org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:779) org.apache.jsp.index_jsp._jspService(Unknown Source) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause java.lang.NoClassDefFoundError: org.apache.taglibs.standard.tag.rt.core.ForEachTag org.apache.jsp.index_jsp.class$(Unknown Source) org.apache.jsp.index_jsp._jspx_meth_c_forEach_0(Unknown Source) org.apache.jsp.index_jsp._jspService(Unknown Source) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) - Original Message - From: Jacob Kjome [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Saturday, January 22, 2005 10:30 AM Subject: Re: ?? Sharing the JSTL JARS and Classloading ?? Not all libraries are written in a way that allows for them to be used from different webapps. Struts has a statement on this written by Craig McClanahan, but I can't find it at the moment. The gist of it is that Struts (at least with 1.1) cannot be guaranteed to work properly if placed in a shared classloader. One example of where this might be problematic is with non-final static variables. If it they get changed by one app, the other app sees the change. Usually, this is not the desired behavior as it will make each app using the shared library behave in unpredictable ways. Anyhow, what error are you getting when you add the library to the shared classloader? I haven't looked at the classloader hierarchy in Tomcat for a little while, but it is possible that shared/lib cannot see common/lib, and if there are libraries that standard.jar and jstl.jar depend on libraries that exist in common/lib, then you might get the error you are seeing. Jake At 01:24 AM 1/22/2005 -0600, you wrote: Hi all, I'm using TC 5.0.30. JSTL Is working fine -- I have the standard.jar and jstl.jar files in my WEB-INF/lib directory. The problem is that I have several web applications that use JSTL and therefore several WEB-INF/lib directories. Rather than copy the aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put them in one central location and have them available for *ALL* web applications. According to the crappy Tomcat documentation that's never updated, I should be able to put the JARs in $CATALINA_HOME/shared/lib. Unfortunately, that doesn't seem to work with these two JARs for some reason. Instead, I have to put them in $CATALINA_HOME/common/lib (which seems to work, for some reason). Why can't I just put these two JARs in $CATALINA_HOME/shared/lib and have them shared across all web applications, as the Tomcat documentation on Classloading indicates I should be able to? It seems very odd that I can either copy the JARs to every WEB-INF/lib directory
Re: ?? Sharing the JSTL JARS and Classloading ??
On Sat, Jan 22, 2005 at 04:43:20PM -0600, Tony LaPaso wrote: : Call me a minimalist but I don't like the idea of having the same JAR file : duplicated if I don't have to. It takes more memory since each web app's : classloader needs to have the same classes in memory. It seems much cleaner : to have the JARs in one central location. Try not to think of it as duplicated; it's more along the lines of, making each webapp independent and portable. The more you share amongst webapps, the more you leave yourself open to version skew (several webapps needing different versions of the same file). -QM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
From: Tony LaPaso [EMAIL PROTECTED] You have some good points, Jake. Thank you for the response. If you happen to run across the statement from Craig M. regarding Struts I'd like to see it. http://struts.apache.org/faqs/kickstart.html#jar The struts.jar file MUST be in each webapp, and not in any common location. Disk space and memory are cheap, I'd rather each webapp be a self-contained entity than to have to bother with making sure each server has the right things in various places. Not to mention that if I want to play with a newer version of some library, I don't risk breaking existing apps by replacing the common version, nor confusing the class loader by having both the old and new versions on the classpath. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
Call me a realist, but the jars you are talking about are only 375k...if 375k of memory kill your web app, go to ebay, and pick up another gig of ram, and it will be fine. :-) Seriously, I have been down the path you are describing (I only want one copy of my jars, so when I upgrade, I only have to do it once!), and trust me...it sucks. The first time you upgrade one and it breaks 3 others, you (not to mention your customers) will be very, very unhappy. And no, I thought it would work! will not be an acceptable response. In addition, jars in the shared/lib classloader may or may not use the appropriate classloader to load configuration resources - it they your this.getClass().getClassloader(), it just plain will not work if it is not in the WEB-INF/lib directory. Ever. Larry On Sat, 22 Jan 2005 16:43:20 -0600, Tony LaPaso [EMAIL PROTECTED] wrote: Call me a minimalist but I don't like the idea of having the same JAR file duplicated if I don't have to. It takes more memory since each web app's classloader needs to have the same classes in memory. It seems much cleaner to have the JARs in one central location. - Original Message - From: QM [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Saturday, January 22, 2005 8:57 AM Subject: Re: ?? Sharing the JSTL JARS and Classloading ?? On Sat, Jan 22, 2005 at 01:24:54AM -0600, Tony LaPaso wrote: : The problem is that I have several web applications that use JSTL and : therefore several WEB-INF/lib directories. Rather than copy the : aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put : them in one central location and have them available for *ALL* web : applications. Webapps are supposed to be self-contained, and as such, it's considered a best practice to pack up a webapp with all the JARs it needs. If it's a hassle to copy the JARs around by hand, why not fold that into an automated build process? -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
?? Sharing the JSTL JARS and Classloading ??
Hi all, I'm using TC 5.0.30. JSTL Is working fine -- I have the standard.jar and jstl.jar files in my WEB-INF/lib directory. The problem is that I have several web applications that use JSTL and therefore several WEB-INF/lib directories. Rather than copy the aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put them in one central location and have them available for *ALL* web applications. According to the crappy Tomcat documentation that's never updated, I should be able to put the JARs in $CATALINA_HOME/shared/lib. Unfortunately, that doesn't seem to work with these two JARs for some reason. Instead, I have to put them in $CATALINA_HOME/common/lib (which seems to work, for some reason). Why can't I just put these two JARs in $CATALINA_HOME/shared/lib and have them shared across all web applications, as the Tomcat documentation on Classloading indicates I should be able to? It seems very odd that I can either copy the JARs to every WEB-INF/lib directory *OR* put them in $CATALINA_HOME/common/lib, but not put them $CATALINA_HOME/shared/lib. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
