Tips: migrating Web Applications from Tomcat to Glassfish
Introduction
Java CAPS 6 includes the Glassfish Application server. It is easy to migrate existing web applications from Tomcat to Glassfish. By doing so, we eliminate the installation of Tomcat. We can consolidate integration projects built with Java CAPS 6 and Web applications on the same runtimes. The migration is easy for most of the Java code. In my experience, the only issues are for a few specific configuration items.
Class Loader delegation model
The Servlet specification recommends that the Web class loader look in the local class loader before delegating to its parent. This is what Tomcat does by default whereas Glassfish does the reverse by default. This feature is comonly used with the log4j library and its configuration file log4j.properties. We store this configuration file in the WEB-INF/classes directory so that each web application has its own logging configuration. With the default Glassfish configuration, if there is a configuration file in the main classloader, this file takes precedence other the configuration files inside each web application. You can have a file in the main classloader if one JAR library file which contains a log4j.properties is located in appserver/lib or domains/domain1/lib.
The solution is to configure the web application with the delegate="false" in the class-loader element of the sun-web.xml file. This makes the Web class loader follow the delegation model in the Servlet specification.
Reference information:
ClassLoaders in GlassFish - a FAQ
Class Loader Delegation in Sun Java System Application Server 9.1 Developer's Guide
Default Servlet for serving static content
Web application often contains static web files like HTML, CSS, JS in addition to dynamic content like JSP. To deliver this content from a Web Application it is very easy to use the Apache Tomcat Default Servlet. As a matter of fact this default servlet is integrated in Glassfish but not declared by default.
The solution to use the default serlvet for static content is to declare it in the "web.xml" file, as shown below:
Additional migration tips
Migration Guide for GlassFish
GlassFish equivalent to WebSphere's "shared libraries"
Java CAPS 6 includes the Glassfish Application server. It is easy to migrate existing web applications from Tomcat to Glassfish. By doing so, we eliminate the installation of Tomcat. We can consolidate integration projects built with Java CAPS 6 and Web applications on the same runtimes. The migration is easy for most of the Java code. In my experience, the only issues are for a few specific configuration items.
Class Loader delegation model
The Servlet specification recommends that the Web class loader look in the local class loader before delegating to its parent. This is what Tomcat does by default whereas Glassfish does the reverse by default. This feature is comonly used with the log4j library and its configuration file log4j.properties. We store this configuration file in the WEB-INF/classes directory so that each web application has its own logging configuration. With the default Glassfish configuration, if there is a configuration file in the main classloader, this file takes precedence other the configuration files inside each web application. You can have a file in the main classloader if one JAR library file which contains a log4j.properties is located in appserver/lib or domains/domain1/lib.
The solution is to configure the web application with the delegate="false" in the class-loader element of the sun-web.xml file. This makes the Web class loader follow the delegation model in the Servlet specification.
Reference information:
Default Servlet for serving static content
Web application often contains static web files like HTML, CSS, JS in addition to dynamic content like JSP. To deliver this content from a Web Application it is very easy to use the Apache Tomcat Default Servlet. As a matter of fact this default servlet is integrated in Glassfish but not declared by default.
The solution to use the default serlvet for static content is to declare it in the "web.xml" file, as shown below:
<servlet> <servlet-name>DefaultServlet</servlet-name> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>DefaultServlet</servlet-name> <url-pattern>*.html</url-pattern> </servlet-mapping>
Additional migration tips

Eric,
This is a question about JMX and JCAPS. Searching the support sites you appear to be the only one blogging about this topic. I am currently creating a Java Swing application to read the JMX beans on our JCAPS 5.1.3 server and display the info nicely on the screen. Part of the motivation is to provide an application that is a bit faster than the eManager and more user-friendly than JConsole.
I have noticed that the com.stc.codegen.mbeans.CollabMonitor JMX bean has an attribute called "NumberMsgProcessed". The return value is a java.util.Properties object. The Property's name is the name of a topic the collaboration subscribes to and the value is the number of messages dequeued from that topic.
If I have a collaboration that subscribes to 2 or more JMX topics, I expect that when I invoke a "get" on the attribute "NumberMsgProcessed" I will have a collection of two properties, one for each topic the collaboration subscribes to. However I find that this method only returns one topic. This behavior is the same if I use JConsole to display the attribute as well. I assume that there is a flaw in the JMX bean code provided by SeeBeyond? Have you encountered this?
Posted by Constance Barton on January 24, 2009 at 11:03 PM CET #
Could you please clarify how do you subscribe from 2 JMS topics?
Posted by Eric Lerognon on January 25, 2009 at 08:38 AM CET #