Questions about 4.0.4 rpm compliance with FHS & RH Linux extensions

[Michael Crawford <mj...@yahoo.com>]

First time contributor - I hope these questions and suggestions aren't seen as
out of bounds...

I generally agree with the reorganization of the /var/tomcat4 directory. But it
seems to me from my reading of the Filesystem Hierarchical Standard v3.1 that
some of the new file names and locations still don't conform. As I've been
using my understanding of how to apply the FHS when designing my own commercial
software, I thought I'd use this forum to correct my understanding, if I'm in
error on the issues outlined below, to keep my custom java apps compatible with
the direction Tomcat takes in the future.

- I agree with moving the main config file from /etc/tomcat4/conf/tomcat4.conf
  to /etc/tomcat4/tomcat4.conf - since I think that is the more correct
  location for the main config file. But I don't agree that this is a config
  file (like httpd.conf, for example) - it seems like it is more like the
  environment setup files used by other /etc/init.d scripts, and should
  therefore be called /etc/sysconfig/tomcat4 (to most closely match other
  network packages - squid or tux, for example); or if also used to initialize
  the user's environment, perhaps /etc/profile.d/tomcat4.sh (Note: other
  Red Hat conventions like /var/lock/subsys/tomcat4 are used, so not using
  sysconfig seems inconsistent.)

- The use of /var/cache for both cache and temp files seems to violate FHS:
  - /var/cache/tomcat4/work does contain cache files, but should be called
    simply /var/cache/tomcat4 - which is possible if...
  - /var/cache/tomcat4/temp does not contain cache files, so according to FHS,
    temp files which should be maintained between server restarts should be
    in /var/tmp, meaning I'd think such files should be in /var/tmp/tomcat4,
    or if truly temporary, /tmp/tomcat4

- The placement of jar files seems to violate the FHS or is incompatible with
  other existing conventions and other co-resident java servers in the
  following ways:
  - /var/tomcat4/bin/bootstrap.jar: This really isn't an executable... The FHS
    appears to limit placement in /bin to such files.
  - /var/tomcat4/common/lib/*.jar: This location seems to conflict with the
    use of /usr/share/java/*.jar for other jar files which are included in
    the same distribution, like servletapi4.jar! I'd think the /usr/share/java
    location is more correct for these files.
  - Similar objection to /var/tomcat4/server, plus both are non-common top-
    level directories (based on a comparison to /usr/local/* and /opt/<pkg>/*
    standard top-level directories.
- I'd think one of the following two alternatives is more compliant?
  - Everything under lib, use config file to indicate what is used where.
    - /usr/share/java - contains ALL jars
      - Primary benefit: many jars are needed for other purposes, such as
        ant-based build scripts, or sharing the machine with an EJB server
        (Weblogic, JBoss).
    - Set up which jars are used for which purpose in /etc/sysconfig/tomcat4
      via environment variables. This script called from /etc/init.d/tomcat4
      Call env vars TOMCAT_CLASSPATH, TOMCAT_SERVER_CLASSPATH, 
      TOMCAT_COMMON_CLASSPATH, ... The classloaders should use environment
      variables like these, as opposed to directory naming conventions that
      may change, require duplication when sharing jars with other servers,
      etc.
      - Primary benefit: Seems like most other daemons work that way to me...
  - Everything under lib, with subdirs:
    - /var/tomcat4/lib/bootstrap/* instead of /var/tomcat4/bin/*
    - common jars should still go in /usr/share/java
    - /var/tomcat4/lib/server/* instead of /var/tomcat4/server/lib/*
    - /var/tomcat4/lib/* for same stuff in there now
      - Problem: These are shared, read-only files, which under FHS should be
        somewhere in /usr/share, or the /opt/packaging convention should be
        used, shouldn't it?  Only /var/tomcat4/webapps really belongs in /var,
        IMHO (compare to /var/www/ - only html, cgi-bin, other variable files
        here for Apache - binaries & modules go elsewhere).

- Finally, I'd think if you're going to have all files under one root, like
  the older non-rpm formats, the FHS System V /opt packaging convention should
  be followed as I thought the FHS recommended. That's where I've generally
  been installing tomcat (i.e. /opt/tomcat) prior to the introduction of the
  rpm packages.

- One final note: I generally use the /opt packaging convention when I create
  java enterprise apps, as follows:
  /opt/<app> - application root, I create <APP>_HOME as an env var.
  /opt/<app>/bin - shell scripts & binaries
  /opt/<app>/doc - docs
  /opt/<app>/lib - jars, ejb-jars, ejb-client-jars, taglib-jars, tlds, etc.
  /opt/<app>/webapps - *.war files or webapp directory trees go here
  /opt/<app>/src - only in src rpm, below this are files to build and install
                   stuff in above dirs. 
  - I deploy out of here, rather than copying the wars to /var/tomcat/webapps,
    since I usually want to have multiple versions of the app available for
    rollback purposes - i.e.
    /opt/<app> -> /opt/<app>-1.2.3  # symbolic link to current version
    /opt/<app>-1.2.3                # current version
    /opt/<app>-1.2.2                # rollback version
    - plus I also need to deploy ejbs as well. I've been using this technique
      with weblogic for years for major websites and packaged software. 

I'm a huge fan of FHS, and thought I'd been using it correctly. Either I'm way
off and can learn why things in tomcat are as they are and adjust my style, or
perhaps kickstart a discussion here. As things stand, I'm more likely to patch
up the standard tomcat distribution (like I've been doing for years with
weblogic to make it conform to my ideas of proper FHS) than use the rpms as 
currently defined.

Sincerely,

Mike


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>