Fedora and Debian play the role where many chaotic projects get a degree of charm school: they learn to play nice with a lot of other projects. In Fedora, as near as I can tell, there is only one Java based web application packages as part of the distribution: Dogtag, the Public Key Infrastructure server. As we look at how PKI should look in the future, the dearth of comparable applications packaged for Fedora leaves us with the opportunity for defining a logical and simple standard packing scheme. While I am not there yet, this post is the start of my attempts to organize my thoughts on the subject. I’m looking for input.
Some one has already started discussing this for Debian.Â I’ll use this http://dep.debian.net/deps/dep7/Â as a starting point.
I think that, if the application is deployed as a war file from the get-go, fine,Â butÂ generating the war file afterÂ deployment is heavy weight.Â Lets treat this as a “last resort” approach if we can’t come up with a better one.Â Most application servers need to extract the files from the .war file if it is deployed that way.Â It makes more sense to try and get a method together for merging the configuration files with rest of the code
Many of the resources that the application requires should actually be external to it.Â The two that are most common are the authentication mechanism and the configuration for database connections.
What is more common is for an application to be “Themable”Â which means that some aspect of the CSSÂ and the images can beÂ customizedÂ after the install.Â There does not seem to be a decent standard in the JEE world for extending and application this way.
Another common pattern is for an application to specify a plugin architecture.Â A plugin is implemented as a Java package that implements a set of interfaces specified by the project.Â The package that implements the pluginsÂ can go into a common location, such as the Tomcat lib/ext directory,Â external to the web app.Â But, in the Java world, if nothing attempts to refer to a class in this package, all the code will lay inactive during deployment.Â So, it is necessary to register theÂ package with the application server.Â Taken to its logical continuation, we have OSGi, and JBoss containers,Â but for simple Tomcat apps, there is no standard way to do this.Â The best we have is MBeans, with are really supposed to be the management API for Tomcat, not a shared business component.
Some of the problems people have typically had in deploying applications involved Jar conflicts.Â The Standard Fedora setup is designed around the compromise that people can link to the system libraries in known locations:Â /usr/share/java/Â for pure java files and Â Â /usr/lib/javaÂ if there is JNI involved.Â If an application needs a version of a library different from the ones provided by the platform, they can put it inÂ webapps/appname/WEB-INF/lib.Â However, the applications packaged with Fedora should only use the packages from the distribution.
There are a couple things that the Fedora Tomcat distribution doesn’t do for us yet:
- Generate the symbolic links for required libraries
- configure SSL,
- configure HTTPD as a proxy so we can serve on ports 80/443
- Perform the SE Linux configuration for the web apps that allows us to run the web server in enforcing mode
So here is the starting point for a deployment standard for web applications in Fedora.Â These should be orthogonal to other Java development factors:Â it shouldn’t change how the project development is done.
- AllÂ supporting libraries go into /usr/share/java.Â Typically, they will have the name of the webappÂ as some aspect of the jar file.
- JSPs and other clear text files will be put into a WAR directory structure in expanded form in the directoryÂ /usr/share/java/webapps.Â All files in this directory will be owned by the RPM that creates them.Â Supporting librariesÂ will be symlinked from jar files inÂ /usr/share/java.
- A zippedÂ war file is optional.Â If provided, it also goes intoÂ /usr/share/java/webapps.
- Configuration files for the application go into /etc/java/webapps.Â A subdirectory for each webappÂ contains the files that belong to the webapp, but that are editable. If a webapp requires an editable server.xml file, that file isÂ held in /etc/java/webapps/<appname>.
- Deployment to a Tomcat instance is done via symlinks.Â The webapp in /usr/share/java/webappsÂ will have a symlink to the config files in /etc/java/webapps/<appname> if required.Â The WEB-APP itself willÂ be deployed via a symlink fromÂ /var/lib/tomcat6/webapps to /usr/share/java/webpass/<appname>.Â Note that if a war file is provided, the expectation is that this will be used for deployment, but the choice is up to the system administrator.
- All files are owned by root and set as readable by the tomcat user.Â Modifications of files in the Tomcat directory is not allowed.Â If a web app needs a local file repository,Â it will be created underÂ /var/lib/tomcat6/temp/<appname> and be owned by the tomcat user.Â SELinux system policy will reflect this.
This is the simplest form of deployment.Â More complex deployments are allowed, but require the rationale to be explained in the spec file for any deviations.Â The most common change will be where the end user is expected to customize the web application.Â In those cases,Â deployment of the webapp will happen like this:
- TheÂ code in expanded form from /usr/share/java/webapps/<appname>Â is copied intoÂ Â /var/lib/tomcat6/webapps/<appname>
- /var/lib/tomcat6/webapps/<appname>/WEB-INF/*Â are copied from fromÂ /etc/java/webapps/<appnam>.
- Upgrades of the RPM will only replace filesÂ outside of the realm of the webapp.Â Upgrades from Changed RPM controlled files to the webapp are done by the system administrator.
- File ownership rules as stated above still apply.
Tool support would expedite adoption of this standard.Â But adoption does not require tool support.Â The simplest cases can be deployed via a single symbolic link. Â More complex deployments can be managed by a script, providing that the script is agnostic of the Servlet container location.Â While Tomcat6 is the only web container that ships with Fedora today,Â that is not going to be the case indefinitely.Â Efforts to package up other Servlet containers are underway.Â Thus, the deployment approach should be agnostic of targeted servlet container.Â If the webapp RPM maintainer wants to perform additional Tomcat specific configuration, that should be done in a separate RPM from the main code, with a title of:Â <appname>-tomcat6-<version>.rpmÂ where the version is the App version, not the tomcat6 version.Â If the end user chooses to deploy this way, it is acceptable, but not required, for the app to be in the deployed state after RPM installation.Â This choice should be documented in the Spec file info.
Fedora should provide a series of scripts, a-la JPackage, that perform Servlet container specific actions.Â These are:
- Create a JDBC Database pool
- Create an LDAP connection pool
- Set up an Authentication Realm
- Register a Globally scoped JNDI named component.
- deploy a war file or expanded webapp directory
- Enable SSL on port 8443
- Configure apache to work as an AJP proxy
- Add a webapp to the AJP proxy definition
Please provide feedback.