Re: Java webapps and configuration files
Torsten Werner <twerner@debian.org> writes:
> On Fri, Aug 20, 2010 at 6:10 AM, Russ Allbery <rra@debian.org> wrote:
>> The JSP files for this application need to be conffiles so that users
>> can change them and those changes are preserved during upgrades.
> no I don't think that JSP files are good candidates for conffiles.
> Web.xml is okay but not code and data.
The way that JSP is used in this particular application means that these
files in this particular application are configuration files. I don't
mean to sound argumentative here, but I'll show you below how upstream is
using them and then it will hopefully be clear.
For all I know, this may be rather weird compared to other Java webapps.
I don't have a lot of experience with other Java webapps and how they
normally handle theming.
>> Does anyone have any other good options?
> The Debian way is still dpkg-divert. It sucks but it works.
Requiring the local user to use dpkg-divert would be a clear violation of
Policy 10.7 in this case, IMO. Debian Policy requires that we put "a file
that affects the operation of a program, or provides site- or
host-specific information, or otherwise customizes the behavior of a
program" in /etc (a must-level directive) and treat such files as
configuration files, which means not requiring dpkg-divert if the user
changes them.
> Two other options come to mind:
> 1) Good webapps support theming. The local admin can put override files
> into some different directory.
In this case, there's just a specific set of pages that are provided as
samples and expected to be edited. See the upstream installation
documentation at:
https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass
for example, specifically:
The example login page is located, in the IdP distribution, at
src/main/webapp/login.jsp. Deployers should brand this page as
necessary, however the names of the username input, j_username, and
password input, j_password, and the form action, /Authn/UserPassword,
must not be changed.
[...]
Once the login page has been customized the deployer should rerun the
installer in order to rebuild the WAR and move it to the IdP home
directory structure.
In other words, upstream expects every site deploying this software to
build their own WAR file with their customized pages. This sort of thing
will have to be customized for each site, since it's a web signon page and
hence will have to match the style for that site.
The sample files are not large; we're not talking about sophisticated JSP
code:
-rw-r--r-- 1 eagle root 319 Aug 18 13:40 error-404.jsp
-rw-r--r-- 1 eagle root 859 Aug 18 13:40 error.jsp
-rw-r--r-- 1 eagle root 13660 Aug 18 13:40 images/logo.jpg
-rw-r--r-- 1 eagle root 372 Aug 18 13:40 login-error.jsp
-rw-r--r-- 1 eagle root 1874 Aug 18 13:40 login.jsp
-rw-r--r-- 1 eagle root 45 Aug 18 13:40 shibboleth.jsp
Upstream is basically using JSP itself as their template mechanism.
One of the challenges of packaging this application will be to find the
right way to support this sort of customization in a way that respects the
FHS and Debian's support for local configuration, rather than using an
installation mechanism that requires each person to build their own WAR
manually (since that's one of the things we offer by packaging it for
Debian).
> 2) I thinks about how is it done in the good old Unix way? If you want
> to modify /bin/true you can put your own implementation into
> /usr/local/bin and you are done. Does Tomcat use some PATH like variable
> to load jsp and css files where some other directory can be prepended?
If it does, that would be great. That would definitely be a cleaner
solution. However, I couldn't find any hint of any such thing in the
Tomcat documentation when I looked.
My understanding is that the JSP pages have to be included inside the
webapp from the Tomcat perspective for them to be able to make use of the
Java code that's deployed in that webapp context.
> BTW I do not like your 3rd option at all. It sounds unsupportable in the
> long run and the local admin has to learn a new tool which is only used
> in Debian and only for Tomcat based apps. We should either use some
> existing solution or something generic one or something that is fully
> automatic and easy to support.
If you can give me a better option, I'm definitely all ears. I'm not sure
why you feel like it would be unsupportable in the long run, though. What
sort of problems are you expecting? Creating the WAR file looks fairly
straightforward, and Tomcat supports live deployment of WAR files and
deploying new WAR files to replace an existing application.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: