As I reported in my previous post SpringSource, formerly known as Interface21 and the company behind the popular Spring Framework, has released the SpringSource Application Platform (S2AP) in beta. This new Java application server is build on top of an OSGi runtime (Equinox) providing a very nice runtime deployment model! Put a little Spring and Apache Tomcat in the mix and, needless to say, I just had to see what I needed to do to deploy GX WebManager on S2AP.
Deploying webapplications on S2AP
A nice feature of S2AP is that, although is promotes modularization, it has deployer support for basic WAR files. No need to OSGi-ify your legacy webapplication right away. Just start the application server, drop your WAR files in the '$S2AP_HOME/pickup' folder and the deployer will take care of the rest... in theory ;)
In fact not only in theory. The default S2AP distribution actually deploys its own admin console and sample splash application this way an that works. However, to get GX WebManager deployed properly I ran into a few small caveats.
Dealing with a deployment timeout
Deploying the GX WebManager backend webapplication for the first time on any platform takes some time as GX WebManager needs to initialize its JCR repository, databases, indexes, OSGi runtime and more. On SpringSource AP this results in a deployment timeout as this is set to 30 seconds by default. When this occurs GX WebManager actually finishes initialization, but because of the timeout SpringSource AP fails to register the webapplication with the servlet container. Up to SpringSource AP 1.0-beta3 release this timeout was actually hardcoded and waiting for initialization to complete and then a restart was required to get the GX WebManager backend registered. As of SpringSource AP 1.0-beta4 this issue is resolved as you may now configure a higher timeout for the deployer in the file '$S2AP_HOME/config/deployer.config'.
/*
* SpringSource Application Platform deployer default configuration file.
*
* bramk: Timeout set to 5 minutes to allow GX WebManager time to initialize
* at first deploy.
*/
{
"deployer" : {
"version" : 1.0,
"deploymentTimeoutSeconds" : 300
}
}
Configuring nice context paths
By default there is no information in the WAR file that tells the application server on what contextpath the webapplication should be deployed. Just like standard Tomcat, SpringSource AP will default to using the WAR filename without the extension. Thus, in my case, the applications are deployed under '/webmanager-static-webapp-1.0-SNAPSHOT' and '/webmanager-backend-webapp-1.0-SNAPSHOT' which is not very nice. Renaming the WAR filename would be a (lame) option for the backend as I want that under '/web', but what about the static webapp that I want under '/'?
Fortunately, SpringSource AP adopted a convention that allows us to specify the desired contextpath by placing it in the MANIFEST.MF file under the key 'Web-ContextPath'. So all we need to do is add that to our build by simply configuring the Maven war plugin to add this information. Simply adding the following fragment to the pom.xml files of the webapp modules will do just that.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<!-- Web-ContextPath>/</Web-ContextPath -->
<Web-ContextPath>/web</Web-ContextPath>
</manifestEntries>
</archive>
</configuration>
</plugin>
Note: Deploying the static webapp as a WAR file is not something I recommend for production environments. A better option is to let Apache HTTPD serve your static content so that the application server only needs to deal with dynamic content.
Finally, the first run I forgot to configure the JVM with a large enough heap resulting in an OutOfMemory during initialization of GX WebManager leaving it defunct. Actually, this has nothing to do with S2AP but it is an essential step in order to get a happy experience :) Simply configure the JAVA_OPTS environment variable or as a local fix add it to the startup scripts in the '$S2AP/bin' directory.
JAVA_OPTS=-Xms512m -Xmx1024m
Conclusion
This screenshot says it all. With a few minor tweaks GX WebManager will happily deploy on the SpringSource Application Platform. I must say it is kind of cool to have an application server, embedding an Equinox OSGi runtime, and deploying GX WebManager, embedding an Apache Felix OSGi runtime, on top of it and having that work out of the box. Now that is modularization in action!
Although the SpringSource Application Platform is only at version 1.0 and still in beta it looks very promising and we will certainly keep a close eye on it.
Bram
Bram de Kruijff is Product Architect and one of the co-architects of the GX WebManager framework with a focus on OSGi and services framework. Bram is part of the NAF Web 2.0 forum group to define standards on community technologies.
Other blog entries: