[fedora-java] Packaging tomcat shell scripts

Robert Rati rrati at redhat.com
Thu Jan 16 15:43:08 UTC 2014

On 01/09/2014 10:34 AM, Robert Rati wrote:
> On 11/07/2013 05:22 AM, Severin Gehwolf wrote:
>>>> Since I've come along systemd's tomcat at foo service file[1] recently
>>>> while packaging thermostat in rawhide, what is preventing you from
>>>> using
>>>> this for hadoop httpfs? It worked quite nicely for us, since we didn't
>>>> have to ship our own systemd service file. We now simply use $
>>>> systemctl
>>>> start tomcat at thermostat for firing up tomcat with a CATALINA_BASE
>>>> in /var/lib/tomcats/thermostat.

This will work for hadoop's httpfs service and obviously works for 
thermostat, but I don't think is the direction that should be taken by 
most webapps.  The problem with the tomcat at foo service as used by 
thermostat is that it fires up an instance of tomcat and deploys the 
webapp.  That works great if:
A) there is only 1 webapp that needs to run at any time with tomcat at foo
B) all webapps use the same port
C) the system tomcat isn't running

If A or C is false, tomcat at foo won't work.  The problem is that all 
tomcat instances use the same server.xml file, so all try to use the 
same Connector setup.  Whichever tomcat instance starts first will work 
fine.  Try to launch a second and you get port collisions and tomcat 
goes down taking the previously running instance with it.

If B is false you end up running webapps that listen on ports other than 
what upstream uses, potentially causing confusion and/or breakage with 
whatever might interact with the webapp.

> I've finally gotten the time to look at this solution and it looks like
> there could be issues with multiple webapps deploying the way thermostat
> does.  I'm not a tomcat expert so I'm probably missing something, but
> here are the concerns I have:
> 1) With all webapps using the same configuration files, wouldn't the
> logs become a mess?  From my testing of thermostat, it places all logs
> in /usr/share/tomcat/logs with no unique extensions save a single
> exception (thermostat-web-storage).  If multiple webapps launch this
> way, won't the logs be incomprehensible?

This is what happens.  All catalina logging ends up in the 
/var/log/tomcat directory (symlinked to from /usr/share/tomcat/logs). 
The mess isn't as bad as it could be because only 1 instance can be 
running at at time.  Try to launch two and these log files become a 
record of the tomcat errors.

> 2) What ports end up being used by these webapps if they all use the
> same configuration?  It seems like there'd be a logjam on 8005.  What
> about webapps that want to use different ports?  Is that needed/allowed?
>   Can this be done with the config file in sysconfig?

There is a logjam on port 8080 (not 8005).  Every tomcat instance uses 
the same configuration files with the same Connector configuration 
resulting in all instances listening on the same port.

Looking at other webapps besides thermostat, many seem to install 
themselves into /usr/share/tomcat/webapps and are run by starting tomcat 
itself. I would think this is the preferred way to deploy webapps.

Unfortunately installing into /usr/share/tomcat/webapps won't work for 
httpfs because httpfs uses system.getProperty to retrieve system 
properties to configure the service.  I don't see a way to get around 
this requirement and as far as I've found there is no way to provide 
these values on a per-webapp basis.  The only way I've found to provide 
the values is as options passed to tomcat on invocation.

The tomcat at foo allows you to define options that will be passed to 
tomcat on invocation, but there seems to be no co-ordination/plan for 
how tomcat at foo1 will run along side tomcat at foo2 or the system tomcat.

Should the goal be to allow these various methods of deploying a webapp 
to run on the same machine?


More information about the java-devel mailing list