I wouldn't mind a 'common-file-separate-instance' directory where each application (as allowed in some manner(web.xml?)) could load *separate instances* of a jar/class file that resides in the same loaction. This would avoid the duplication of such libraries that should not share instances.
I have not yet looked at servlet spec 2.4, so it may already be there. Charlie > -----Original Message----- > From: Ralph Einfeldt [mailto:ralph.einfeldt@;uptime-isc.de] > Sent: Tuesday, November 05, 2002 8:51 AM > To: Tomcat Users List > Subject: RE: Tomcat and CLASSPATH > > > Yes it is housekeeping, and we already have scripts that can > do the housekeeping. As we have in the past moved from linking > to the repositories, we have already a list of jar files > that are needed outside of the container, and a script that > creates the repository entries. > > Still I see some disadvantages. > > - I feel more comfortable if I can see directly > which version of a library is used instead > on relying on external reference. (I have seen > to many people ignoring the rules and copying > something manually without updating the reference.) > > - Although disk space is cheap, it's not for free. > And there are other space requirements that aren't > cheap at all (backup drive + tapes) > Currently the libraries that are used for our > sites have a size of roughly 4-5MB. If you have to > copy this for each site it can get a quite big > number. > Depending on your business model, that can be > a deciding difference. (The smaller the volume > of the content and the more sites you have, the > more painfull this number gets) > > > -----Original Message----- > > From: Turner, John [mailto:JTurner@;AAS.com] > > Sent: Tuesday, November 05, 2002 2:06 PM > > To: 'Tomcat Users List' > > Subject: RE: Tomcat and CLASSPATH > > > > > > > > Thanks for the response. > > > > My point is simply that the files have to reside _somewhere_, > > correct? So > > if they have to reside _somewhere_, they might as well reside in the > > structure intended for them. The act of putting them in > > location A vs. > > location B is exactly the same, only the destination is different. > > > > The rest is housekeeping, and in my mind, it makes more sense > > to write a > > housekeeping tool (or use a build/deploy tool) than it does > > to circumvent an > > intentional design. The only other problem is duplicates, as > > you pointed > > out, but again, that's housekeeping. As long as you know > > who/what has which > > file, the fact that there are two copies of the file is > > pretty irrelevant > > from a practical viewpoint. > > > > John > > > > > > > -----Original Message----- > > > From: Ralph Einfeldt [mailto:ralph.einfeldt@;uptime-isc.de] > > > Sent: Tuesday, November 05, 2002 4:29 AM > > > To: Tomcat Users List > > > Subject: RE: Tomcat and CLASSPATH > > > > > > > > > > > > We have following reqirements: > > > - each site can have a different version of a tool > > > - many sites share the same vesion of the tool > > > - a site may change the needed version of a tool > > > - a site may replace a tool by a different one > > > (switch from postgres to firebird) > > > > > > We have a setup like this: > > > > > > /usr/local/tool-a-v1/lib/toola.jar > > > /usr/local/tool-a-v2/lib/toola.jar > > > /usr/local/tool-a-v3/lib/toola.jar > > > > > > /usr/local/tool-b-v1/lib/toolb.jar > > > /usr/local/tool-b-v2/lib/toolb.jar > > > > > > > > > /www/online/www.site-a > > > /www/online/www.site-b > > > ... > > > /www/online/www.site-z > > > > > > > > > Currently we use jserv and gnujsp. > > > > > > jserv has the concept of repositories. The repositories are > > > added by jserv to the internal classpath. We use the repositories > > > to connect a site with the tools it needs. So it's very easy > > > to change the versions of the tool or to replace the tool. > > > > > > Now to tomcat: > > > > > > Without linking we would have to copy the libraries into > > > the tomcat directory structure for each site. > > > > > > With copying I see two disadvantages for us: > > > - We would have several copies of the same libraries. > > > Although disk space get cheaper, this is something > > > that disturbs me (May be caused by the fact that > > > my first hard disk had less space than a modern > > > grafic card or handheld has memory: 40MB) > > > - We loose the 'natural' information which > > > version of the library we use in specific site. > > > - If we would have to replace a version of a tool > > > by a patched version, we could just replace the > > > central file, now we have to copy this file to > > > all instances that use this version. > > > > > > With linking the libraries we could solve both > > > disadvantages for us. > > > > > > > -----Original Message----- > > > > From: Turner, John [mailto:JTurner@;AAS.com] > > > > Sent: Monday, November 04, 2002 5:39 PM > > > > To: 'Tomcat Users List' > > > > Subject: RE: Tomcat and CLASSPATH > > > > > > > > > > > > We don't use symbolic links. Everything is under Tomcat's > > > > directory tree. > > > > > > > > What is the advantage to using symbolic links or an external > > > > classpath? I'm not seeing what advantage you would get. > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > > For additional commands, e-mail: > > <mailto:tomcat-user-help@;jakarta.apache.org> > > > > -- > > To unsubscribe, e-mail: > <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
