[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Java webapps and configuration files



Hello all,

Several of us (at least myself, Faidon Liambotis, and Sam Hartman) are
looking at packaging the Shibboleth IdP, which is the identity provider
component of a federated authentication system.  I'm also going to be
looking, in the next six months to a year, at how to build Debian packages
for a variety of identity management web applications written in Java for
Stanford University.

I talked to some folks at DebConf10, and my understanding is that webapps
are an area of Java where there hasn't been much policy work in Debian
yet.  This is going to be increasingly important for these and other
projects, and I have some time available to spend on this problem.  I
wanted to start discussing possible design issues here.

Starting with the Shibboleth IdP, this is a large Java application
distributed primarily in WAR format.  It has all the standard Java
problems that I'm sure everyone here is all too familiar with: a huge
collection of bundled JARs, an upstream not used to users who want to
build from source themselves, and similar difficult but boring problems
that aren't worth getting into.  But it also has some specific challenges
that I think are topics for policy work, best practices, and possibly
helpers.

First, the web application has some configuration in its WEB-INF/web.xml
file that the end user is expected to change, and which can't be changed
by overrides in the context file.  We're currently handling that by moving
web.xml to a package-specific directory in /etc and symlinking it into
the /usr/share directory where the rest of the webapp is.  Other packages,
like jspwiki, are using the same approach.  This works, but having to use
symlinks like this is not ideal.

Second, and more difficultly, upstream includes a set of JSP files for the
login page of the Shibboleth IdP and related pages which are templates and
explicitly intended for the end-user to customize.  In essence, upstream
is using JSP as a templating language, and the end user is expected to
write their own JSP pages for the application so that the login page can
blend in to their site appearance.  There are also accompanying image
files and so forth.  These files are all shipped at the top level of the
webapp structure in the same directory as the WEB-INF subdirectory that
contains the code.

The JSP files for this application need to be conffiles so that users can
change them and those changes are preserved during upgrades.  This means
that they can't live in /usr/share, but so far as I know, Tomcat requires
that all these files be kept together in the same tree for a webapp to
work properly.

We've come up with the following possibilities:

1. Move all the JSP files and the images directory to /etc similar to the
   web.xml file and create symlinks.  This has some major problems,
   though.  Not only is it messy and a bit fragile, but it means that the
   end-user can't add new files that should be part of the webapp (like
   CSS files, shared JSP files for common headers, and so forth).

2. Move the whole webapp into /etc except for the WEB-INF directory and
   similar code portions, and symlink back to those in /usr/share.  This
   has the same ugliness problem, plus now relies on symlinks in /etc that
   the user may think they can remove (since /etc is normally just
   configuration) but which would break things completely.

3. Rather than using a context file to point to a complete file system
   version of the deployed webapp, ship the code portions in /usr/share,
   the configuration files (like web.xml and the JSPs) in /etc, and
   include in the package a script that assembles a WAR file from all
   those component parts, incorporating the latest versions of the
   configuration files in /etc, and then deploys that WAR file in
   /var/lib/tomcat6/webapps.  Each time the user changes anything, they'll
   need to re-run that script to redeploy the application.

Does anyone have any other good options?  I'm personally leaning towards
(3) at the moment, even though it adds another user step to make any
changes in configuration be effective and duplicates the webapp on disk,
since it seems the cleanest.

Is this something where Tomcat may eventually be able to help us, by
providing some way to put the files for a webapp in multiple places so
that conffiles can be kept separate from package files?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: