Sign in

E-mail *, (xx@domain.com)
Password *

Register | Forgot password

Recent blogs

RSS - Blogs
December 24, 2008
The year has almost ended...
December 9, 2008
5 Spring pitfalls
December 9, 2008
Like A Version
October 22, 2008
New certification process
October 17, 2008
Search quest [3/3] - improvements

All Blogs...


GX WebManager on SpringSource Application Platform

May 27, 2008

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.

Giving the JVM enough memory

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.

Regards,

Bram


About the Author

Return to all blogs


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.

Read all Brams blog entries

Other blog entries:

December 9, 2008
5 Spring pitfalls
June 3, 2008
A few SDK tips & tricks
May 29, 2008
Maven secrets: Dynamic Maven properties with Beanshell
May 9, 2008
JavaOne 2008 wrapup
April 14, 2008
Maven secrets: assembling a WCB zip
April 11, 2008
ApacheCon EU 2008 impressions
March 29, 2008
Maven secrets: filtering sources
March 12, 2008
Did you catch the Tortoise today?
February 29, 2008
OSGi adoption on the rise!
February 26, 2008
Tabula rasa


Share:

del.icio.us
digg
Technorati
Slashdot
Reddit
YahooMyWeb
NewsVine
ekudos
© 2008 GX creative online development B.V.

Disclaimer

This website (GXdeveloperweb.com) may discuss or contain opinions, (sample) coding, software or other information that does not include GX official interfaces, instructions or guidelines and therefore is not supported by GX. Changes made based on this information are not supported.  GX will not be held liable for any damages caused by using or misusing the information, software, instructions, code or methods suggested on this website, and anyone using these methods does so at his/her own risk. GX offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this website, including any liability resulting from incompatibility between the content of this website and the materials and services offered by GX. By using this website you will not hold, or seek to hold, GX responsible or liable with respect to the content of this website.