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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaoh7wm4....@windlord.stanford.edu
