I think the real problem is in third party repackages that have a tendency to treat .jar files like any native binary library. The jar is placed somewhere and then three or four different symlinks get chained together to make it show up in all the places it's needed. I know why they do it -- they want to be able to build the library jars themselves and then backport patches made to later releases to maintain compatibility with all the dependent packages. Unfortunately it doesn't work and causes more headaches than it's worth.
I've personally done deploys somewhat similar to the way Apache Httpd get's deployed -- make /etc/tomcat (or whatever you want to name it) the root of the service, and then symlink webapps, work, temp, logs, lib, and bin directories to different more appropriate places. conf and all it's subdirectories stay put under /etc/tomcat. This lightweight symlink works well for me. The heavier weight stuff of symlinking the jars themselves is usually where I've seen stuff break. --David André Warnier wrote: > Hi. > > Picking up on a recent (mild) comment on this list : > > quote > > Note that relocating everything means that when posting your users post > questions to this mailing list we're likely to say "who's the idiot that > scattered all the directories all over the place? try downloading a > fresh version of Tomcat and see if all your problems go away?". > > unquote > > I wonder if it is not time to "make peace" on this issue and maybe > trying to find a reasonable middle ground. > > An installation of the complete official Tomcat under > /usr/local/tomcatx.y, including logfiles, webapps, etc.. is > undoubtedly the simplest case for someone here trying to offer support > to some bewildered user. > At the same time, it is not the configuration that most users have > when they come here for help. > > Also, application packagers for various systems have undoubtedly a > number of reasons for doing what they do, and it is also undoubtable > that the availability of software packaging and distribution > mechanisms greatly facilitate the life of system administrators and a > whole bunch of users. > And these packagers have to deal not just with Tomcat, but with > hundreds of applications which vie for the same or alternative > resources, and try to bring some modicum of order into this chaos. > > And yes, some packagers for some platforms seem to have great fun in > scattering Tomcat things all over the place, and creating a maze of > symlinks where the most seasoned of Tomcat developer quickly loses his > serenity. > > My point is that packaging of applications, considering its many > practical advantages, is here to stay. That implies also putting > logfiles for all applications in some generally common place, > configuration files ditto, added user applications ditto, etc.. > > So why not try, at the Tomcat development level, to take some steps to > make this easier, while providing a framework that helps in diagnosing > issues and simplify the life of experts on this list and others. > > For instance, the startup of Tomcat already uses the JAVA_HOME > variable to locate the appropriate jvm, the CATALINA_HOME to find the > code, CATALINA_BASE to find the instance-specific stuff etc.. > > So why not add some variables like CATALINA_LOGS, CATALINA_WEBAPPS > etc.., whose value would by default be what they are now (such as > $CATALINA_BASE/webapps) but which could also easily be "redefined" by > the application packagers when needed ? > (And I mean without the need for these people to become real Tomcat > experts and go digging in the server.xml, context.xml etc..). > > And why not add a standard program/script/webapp to Tomcat, which > prints out a few lines containing the platform type, Tomcat version, > location, jvm version and location, webapps location, logfiles > location, and so on, so that we could in this forum ask that posters > first and for all execute this command or webapp and prefix their > messages with the output ? > Only that, would already save a significant percentage of the > bandwidth on this list. > > I know that this is to some extent a naive request, and that there are > some aspects that may be more difficult than others, but is it > possible to approach this issue in a positive, rather than > recriminative fashion ? > > > > --------------------------------------------------------------------- > 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
