[fedora-java] Packaging Webapps for Fedora

[Adam Young]

I'm one of the developers working on the next version of Dogtag, the 
Public Key Infrastructure packages (pki-*)  which is, as far as I can 
tell, the only Java Web app that actually ships in Fedora.


PKI is an old project, and it has vestiges of many  aspects of Java 
development that are just done differently today.  We are looking to 
close the gap between where it is and where the Standard lies.   As 
such, we have to figure out how to attack packaging the application.

Part of that, for Fedora, is to establish the standard in the first place.


Dogtag ships with a utility called  pkicreate.  This is an application 
that creates a Tomcat instance in (by default) /var/lib/pki-*  and sets 
the ports, the SELinux policy, the config, etc.  While I think it does 
more than it should, certain aspects of what it does are essential.  For 
example,  it handles all of the SELinux configuration for the Tomcat 
instance.  Tomcat ships with SSL  disabled, and  without an AJP 
connector to apache.  Thus,  Tomcat can't serve over port 80 or 443, 
meaning that they can't be viewed by many people behind firewalls.  
pkicreate configures mod_proxy_ajp support.   It performs the SELinux 
configuration for the HTTP  ports (if they are different from 8080 and 
8443 which should be handled by system policy), as well as the AJP port.


Russ Alberry, on the Debian Java team, has propsed a deployment utility 
similar in scope to what pkicreate does, but for the general case:

http://dep.debian.net/deps/dep7/


Fedora 17 and later will have  JBoss, which has a different set of 
deployment rules.  Geronimo is already part of Fedora, although I have 
to admit ignorance as far as how it would interact with Tomcat.  Resin  
is a possiblity as well.  So we don't want to hardcode the deployment 
approach to the Tomcat  server.  But, the Tomcat install should be 
supported first.


For a directory standard, I would say that a Fedora Web app should not 
have to provide a .war file, but should be able to use the tool to 
produce one .

Many web applications allow for post install customization.  THe 
simplest case is that a Company wants to theme the application with its 
own images and CSS.  If the web application is delivered in  a .war file 
and expects to deploy this way on the Servlet engine, there is no way to 
customize it.  Thus, Russ' approach listed above seems right on.  The 
one thing I would adjust is that deployment as a war file should be an 
option, but not necessarily the prefereed option.  MOst application 
servers have to unzip war files anyway, and it seems a waste and 
troublesome to zip up the file only to unzip it.  I say war is the 
exception but not the rule.

pkicreate is a Perl application.  As such, I don't think it will gain 
wide acceptance in the Java community.  But, it can server as a 
prototype for A Java based java-deploy-webapp.


Here's a short list of functions that I think the deployment tool should 
handle beyond what is listed in Russ' propsal:

1.  Configuring Security Realms
2.  Configuring JDBC connections (It would be nice if it configured 
Postgresql and MySQL for JDBC, too....)
3.  Configuring LDAP  connections
4.  Opening additional ports and providing SELinux configuration for them
5.  Creating Symlinks for shared libraries  to /usr/share/java and 
/usr/lib[64]/java
6.  Registering generic Global scoped components that can be accessed 
via JNDI names.


It  is possible that the workflow for java-deploy-webapp could best be 
done using either Ant or Maven.  However, I would not like to require a 
.pom or build.xml file as part of the deployment:  Web apps should 
follow the standard, and requiring additional configuration should be 
supported but not the norm.  Perhaps we look for something like 
/etc/webapp/name/pom.xml  and, if it doesn't exist, generate it from a 
skeleton.  Or, we can say that if they provide the pom.xml, then we 
support deploying this way, otherwise you are on your own.