Running application instead of application servers

Most of the time, Java web application are deployed on their own instance of an application server. Within shops that uses server virtualization, this approach is extended to have one virtual server per application. This is done to ensure that an application will not adversely affect another one running on the same physical server.

However, application server products always assume that you may deploy many application on the same server. Configuring the application server is then a lot more complicated than what would be required to configure just one application.

If most of the time we deploy only one application per application server, why do we not bundle application server in our application instead of installing application server and then configuring our application on top of them?

Here how I would see how it would work :

1. Develop the application as usual (deploying the application on an application server),
2. Use some tool provided by the application server product to create an installation/update package :
1. The tool would have a Wizard like interface (but you would also be able to run from the command-line after saving the settings from the Wizard),
2. It would ask for which application to deploy,
3. Based on the application deployment descriptor, it would preselect application server features that needs to be available,
4. Provide an interface to select additional application server features to activate,
5. Ask for default configuration parameters for the application (datasource, ...),
6. Generate an interface (web, fat, console) to configure that application when installing/updating it,
7. Generate the necessary installation script,
8. Package the whole thing into a platform specific package (DEB or RPM for Linux, MSI for Windows, ...),
3. Install/update the application on the targeted environment using the generated package.

Using this approach has the following benefits :

1. Smaller installation footprint. If the application server does not need to be installed with all it's feature activated, then they should not be installed,
2. Easier installation/update process for those who have to maintain the system,
3. Easier configuration has only configuration options required for the application will be exposed.

Food for thoughts...

Geronimo First Impression

I just installed Geronimo for the first time. I wanted to run Hudson and I'm a bit tired of Tomcat for many reasons. I could have used Jetty but I really wanted to try Geronimo.

Installation was quite easy. You just decompress the installation package in a folder and they you run it. First thing first, I changed the password of the system user (the default admin user) to something other than manager. It's still amaze me, that the default installation uses a default user/password for administration purpose.

The next step was to deploy the Hudson WAR file. So I went to Geronimo admin console and I click on the Application/Deploy New. There your are presented with a simple screen asking you for an archive to deploy and a plan. The plan is optional. So I put my hudson.war in there and click Install (shouldn't it say Deploy?). Bang! I got back an error message with some stack trace. It seems like I need a deployment plan to deploy (or is it install) this application. But there is no hint whatsoever as to what I should put in there.

My guess was that I needed to specify some security-role mapping and configure one of the environment entry for Hudson.

After some search in Geronimo documentation, I found out that I needed the following deployment plan to successfully install Hudson :

<?xml version="1.0" encoding="UTF-8"?>
<web-app

xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1"
xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1"
xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1"
xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1">

<security-realm-name>geronimo-admin</security-realm-name>
<security>

<default-principal>

<principal name="anonymous" class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"
/>

</default-principal>
<role-mappings>

<role role-name="admin">

<principal name="administrators" designated-run-as="true" class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
/>
<principal name="root" class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"
/>

</role>

</role-mappings>

</security>

</web-app>

This is not what I call something that is obvious, especially for the <principal .../> thingy.

And by the way, there is no way to configure any <env-entry> in your wen.xml with some other value. So you have to edit your web.xml before deploying your application if you want to change these.

Now, how could this be improved? First, if the administrative console does not provide a wizard or something to specify what is needed to properly configure the application (like it is on Geronimo), then the application server should first report meaningful error messages (instead of meaningless stack trace). Another proper of handling this kind of things would be to provide a sample deployment plan with all the elements that must be specified for the application being deployed.

Even with the EJB 3.0 specification, it seems that we are far from escaping the XML configuration hell of J2EE.

Better, I believe we should reverse the roles of application servers. Instead of deploying an application on an application server, we should bundle the application server with our application and run it like any other application. I will expand this thought in a soon to be published blog entry.

So my first impression of Geronimo? It's not most difficult to install than Tomcat but could provide better error reporting when deploying application. The deployment plan should also be simpler and more intuitive or else provide a configuration wizard.