1 2 Previous Next

sekhar

18 posts

Migration Issue:

WebLogic application server supports sharing of utility classes in an ear file. The shared utility classes can be packaged in one of two directories :

  • APP-INF/lib : shared jar files can be placed here.
  • APP-INF/classes : individual classes can be placed here.

The problem is that APP-INF is proprietary to WebLogic and non portable.

Migration Path to GlassFish:

Use the portable mechanism for sharing introduced in Java EE 5 specification. Java EE specification defines the following.

"A .ear file may contain a directory that contains libraries packaged in JAR files. The library-directory element of the .ear file's deployment descriptor contains the name of this directory. If a library-directory element isn't specified, or if the .ear file does not contain a deployment descriptor, the directory named lib is used. An empty library-directory element may be used to specify that there is no library directory.

All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients. These libraries may reference other libraries, either bundled with the application or installed separately, using any of the techniques described herein."

To migrate a shared jar file, foo.jar packaged in APP-INF/lib/foo.jar, do one of the following:

  • move APP-INF/lib/foo.jar to lib/foo.jar .
  • use <library-directory> element in META-INF/application.xml to reference the current location where the shared jar files are packaged. 
    <application>
       <library-directory>APP-INF/lib</library-directory>
    </application>
        
    

Note that the <library-directory> is new for Java EE 5 and is defined by the XML Schema for Version 5 of application.xml ( http://java.sun.com/xml/ns/javaee/application_5.xsd ). The META-INF/application.xml being migrated might contain the DTD for the older version of application.xml. In this case, replace the DTD with the following:

 <application version="5" xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
              http://java.sun.com/xml/ns/javaee/application_5.xsd"> 

Otherwise, the deployment will fail with the following error in server.log.

Deploying application in domain failed; Deployment descriptor file META-INF/application.xml in archive [archive-file-name]. Element type "library-directory" must be declared.

To migrate shared individual classes in APP-INF/classes, package the classes into a jar file and add them to the lib directory.

Migration Issue: This migration issue is related to the inheritance of client view in a session bean. Consider the following code fragment where session beans A and B exposes local business interface ( or client views using EJB 3.X specification terminology).

    // Assume Foo is a local business interface         
    @Stateless
    public class A implements Foo { ... }

    // Assume Bar is a local business interface
    @Stateless
    public class B extends A implements Bar { ... }

So does session bean B expose Foo or not ? This was unclear on EJB 3.0, JBoss allows it while GlassFish v2 does not. Hence the migration issue.

EJB 3.1 clarified the inheritance semantics. According to EJB 3.1, session bean B will expose only Bar but not Foo i.e. there is no inhertiance of client views. EJB 3.1, Section 4.9.2.1, "Session Bean Superclass" states the following:

For the purposes of processing a particular session bean class, all superclass processing is identical regardless of whether the superclasses are themselves session bean classes. In this regard, the use of session bean classes as superclasses merely represents a convenient use of implementation inheritance, but does not have component inheritance semantics.

Migration Path:So, the migration path for this issue is to follow EJB 3.1 semantics. i.e. if you want session bean B to expose Foo, then explicitly include Foo in the interfaces exposed by session bean B as follows:

    @Stateless
    public class A implements Foo { ... }
   
    // Add Foo to expose Foo in session bean B's client views.
    @Stateless
    public class B extends A implements Foo, Bar { ... }

Recently, I came across the following JBoss -> GlassFish migration issue involving taglib-location in web.xml. Here is how I dealt with it.

In a web-application's web.xml, <jsp-config> element can be used to provide configuration information for JSP files. The following fragment works on JBoss 4.3 (or so it was indicated to me)

   <jsp-config>
     <taglib>
       <taglib-uri>example-html.tld</taglib-uri> 
       <taglib-location>WEB-INF/example-html.tld</taglib-location> 
     </taglib>
   </jsp-config>

But on GlassFish v2, the web application's deployment to failed with the following exception in GlassFish server.log file.

     javax.servlet.ServletException: PWC3039: Invalid TLD resource path /WEB-INF/WEB-INF/example-html.tld

To fix error, prefix a / to taglib-location

   <jsp-config>
     <taglib>
      <taglib-uri>example-html.tld</taglib-uri>
      <taglib-location>/WEB-INF/example-html.tld</taglib-location> 
     </taglib>   
   </jsp-config>

So is a leading / for taglib-location *required* ? After browsing through JSP & Servlet specs and xml schema files I interpreted that a / is not required but recommended. But I will defer to the Servlet spec lead for a more definite answer.

Recently there has been some questions regarding order in which Java EE modules in a Java EE eneterprise applications. The order in which Java EE modules are loaded varies between Java EE application servers. So it is a migration issue issue. This is the first of my blogs on this topic. In this blog, I have highlighted some aspects of order of loading of Java EE modules packaged in a *single* ear file deployed on GlassFish V2.

In GlassFish V2, currently, the modules in an ear file are loaded in the following order: connector modules, ejb modules and then web modules. If there are multiple modules of same type, the order in which they are loaded is random.

One interesting use is that of a message driven bean, which upon receiving a request, invokes an ejb which is part of the same enterprise application (ear file). In this case, it might look there is an ordering constraint ( ejb must be loaded before message driven bean). However, that is not the case because Java EE 5 spec requires that all parts of the application are enabled and ready for service before any *user* requests are delivered to the application. Section EE.8.4,"Deployment" of Java EE 5 spec has the following requirement:

"In all cases, the deployment of a Java EE application must be complete before the container delivers requests to any of the application's components. When an application is started, the container must deliver requests to enterprise bean components immediately. Containers must deliver requests to web components and resource adapters only after initialization of the component has completed."

You can control the order of initialization of servlets in web application, using <load-on-startup> element. Servlets marked with lower integers are loaded before servlets marked with higher integers. Servlet Spec 2.5, section SRV.13.4 "Deployment Descriptor Diagram" specifies this precisely.

That is it for now. I will be back later with more info on this topic.

GlassFish Migration: WebLogic's Split Directory To Ear

As I wrote in the blog on Verification Tools for Migration to GlassFish, GlassFish verifier tool is handy for verifiying the Java ]]> verifier --portablity archive

at seems simple enough to run, but it does require an archive (ear/war/jar/rar). The source application server (e.g. WebLogic ) from which the application is being migrated to GlassFish will usually provide a mechnism to generate an archive file. Here, I will examine the generation of an ear file on WebLogic 9.2 when split directory development is being used. A lot of the samples in WebLogic 9.2 distribution use the split directory development model. And I ran into a problem while trying to generate an archive file for the JSP Simple Tag samplethat I had migrated earlier. I will describe both the problem and the workaround.

Background on Split Directory Development

The split directory development model is targeted towards iterative development. The essence of this type of development is that there are two directories:

  • srcdirectory : This directory contains sources, including deployment descriptors.
  • build directory : This directory contains compiled classes.

WebLogic provides an Ant task - wlpackage - to package the src and build directory contents into a single EAR file or an archive directory in an exploded format. For e.g.

 <!-- package to an ear file --> <wlpackage srcdir="${src.dir}" destdir="${dest.dir} toFile="${ear.file}" /> <!-- package to an exploded directory --> <wlpackage srcdir="${src.dir}" destdir="${dest.dir} toDir="${ear.exploded.dir}" /> 

Every WebLogic 9.2 server sample's build.xml contained an Ant target "package.exploded.ear" that packaged the src and build directory into an ear in exploded format. But there was no ant target for packaging into a J2EE ear. Note: The WebLogic 9.2 BuildXMLGen facility does generate a build.xml with an Ant target for building both ear file as well as a standard J2EE expoloded directory. I am not sure why the build.xml files in the samples do not have such a target.

So I thought I would use wlpackage to package an ear file. The problem I ran into is that the ear file generated was not Java EE compliant. The files for the web module were packaged in an exploded format rather than being packaged into a war file first, and then packaging the war file into the ear file. Thus, the web-uri XML element in the application.xml points to an exploded directory rather than a war file, causing the verifier to fail with an exception.

 <!-- Archive contents produced by wlpackage --> <!-- Note: jspSimpleTagWar is a directory not a war file --> META-INF/ META-INF/MANIFEST.MF META-INF/application.xml jspSimpleTagWar/ jspSimpleTagWar/ExamplesFooter.jsp ... <!-- META-INF/application.xml --> <?xml version="1.0" encoding="UTF-8"?> <application xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.4"> <description>JSP 1.2 Simple Tag API Example</description> <display-name>JSP 1.2 Simple Tag API Example</display-name> <module> <web> <web-uri>jspSimpleTagWar</web-uri> <context-root>jsp_simpleTag</context-root> </web> </module> </application> 

I worked around the above problem as described below.

  • Build the ear in exploded format on WebLogic 9.2. Every server sample in WebLogic 9.2 distribution has a build.xml file an ant target "package.exploded.ear", which will build package the contents of src and build directory into an EAR file in exploded directory format.
     <target name="package.exploded.ear"> <wlpackage srcdir="${dist}" destdir="${examples.build.dir}/${bean.ear}" toDir="${dist}" /> </target> 
  • Make a copy of application.xml to gf-application.xml and changefrom directory to a jar file name. This will replace the application.xml.
     <!-- META-INF/application.xml --> <?xml version="1.0" encoding="UTF-8"?> <application xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.4"> <description>JSP 1.2 Simple Tag API Example</description> <display-name>JSP 1.2 Simple Tag API Example</display-name> <module> <web> <web-uri>jspSimpleTag.war</web-uri> <context-root>jsp_simpleTag</context-root> </web> </module> </application> 
  • Run the WebLogic supplied ant target to create an ear in exploded directory format. In the JSP Simple Tag example, you can do this by:
     cd <weblogic92>/samples/server/examples/src/examples/webapp/jsp/tags/simple/ ant package.exploded.ear 

    This creates <weblogic92>/samples/server/examples/src/examples/webapp/jsp/tags/simple/jspSimpleTagEar exploded directory

  • Run the following target with will take the exploded directory and package the ear file correctly. (For simplicity, I hardcoded values for directories).
     <target name="all"> <!-- package the J2EE exploded ear into an archive --> <mkdir dir="archivedir"/> <jar destfile="archivedir/jspSimpleTag.war" basedir="jspSimpleTagEar/jspSimpleTagWar"/> <copy todir="archivedir/META-INF"> <fileset dir="jspSimpleTagEar/META-INF" excludes="**/application.xml"/> </copy> <copy file="gf-application.xml" tofile="archivedir/META-INF/application.xml"/> <jar destfile="jspSimpleTag.ear" basedir="archivedir"/> </target> 

The generated ear will look like this.

 Ear file format META-INF/ META-INF/MANIFEST.MF META-INF/application.xml META-INF/weblogic-application.xml jspSimpleTag.war 

Summary

WebLogic supports a split directory development. WebLogic provides ant taskfor packaging an ear file. But the ear generated cannot be processed by the ear file. I have showed one way to get around this problem using an ant script that packages the contents of an exploded archive directory into an ear file for consumption by verifier.

It would be useful if the verifier tool itself could be used on an exploded directory. But that is another topic for another day.

When migrating a Java EE/J2EE application to glassfish, often the first step is to determine if the application is using non portable Java EE/J2EE application features. In my previous GlassFish migration blogs, I demonstrated the use of the GlassFish verifier tool for this purpose. However, there are other tools that can also be used to verify the portability of a Java EE/J2EE application - NetBeans Package Archiver, Java AVK, Admin Console. I will highlight the verification support in these tools in the context of migrating applications to GlassFish . Thanks for my collegue Sahoofor his input on this topic.

GlassFish Verifier

The GlassFish verifier tool is part of the GlassFish distribution and can be found in the <gf-install>/bin directory. The verifier tool validates Java EE annotations, standard Java EE deployment descriptors and GlassFish server specific deployment descriptors of a Java EE application or module against the corresponding DTD or schema files. The validation performed are listed in the Assertion list. A validation failure will generate an error or a warning. Thus, the verifier, which can flag non compliant aspects of a Java EE application or module, is a useful tool when migrating from other application servers to GlassFish.

The verifier tool can be run from the command line and supports several options. One of the options specifies the mode in which the verifier tool can be run.

  • verifier.bat --portability archive-file(portability mode)
  • verifier.bat archive-file (appserver mode)

The archive-filecan be a EAR, WAR, RAR, and JAR file.

When the --portability swtich is specified, application is verified for Java EE compliance. When the --portability switch is omitted (appserver mode), the verifier tool performs additional checks on the correct usage of GlassFish application server features. The default is appserver mode. When migrating Java EE applications from other application servers, since we are concerned mostly with the use of verifier for detecting API extensions, the use of --portability switch is the most useful.

Another command line option is the -u | --gui option that can be used to run the verifier tool using a GUI. This option works but it is deprecated. A Warning message pops up when this option is used. Note that NetBeans "Packaged Archive" project supports this same functionality.

NetBeans Packaged Archive project

NetBeans "Packaged Archive" project allows one to open an archive, edit deployment descriptors, assemble and deploy the application on a Java EE server. It also supports a verification of the archive. The verification done is in the appserver mode. To verify using the Packaged Archive project,

Create the Archive project (specifying the archive being migrated).

 

nbpackage-screen1.jpg

 

 

Verify the archive. The following example shows a screen shot of an attempt to verify an WebSphere sample application, Plants. I generated the ear file by exporting the Plants application from within the WebSphere Admin console.

 

nbpackage-screen2.jpg

 

 

The NetBeans GUI provides the same options as (verifier.bat --gui ).

The NetBeans Package Archive project and the verifier tool are useful for verification at development time. However, it is possible to verify application at deployment time using ant scripts or the Admin Console.

Ant Task Integration

Ant provided with GlassFish application server contains server specific tasks for developing, deploying and undeploying Java EE modules and applications. These are described in GlassFish Developer's guide. One such ant task is the sun-appserv-deploy task that can be used for deployment. An application can be verified at deployment time using the "verify" attribute:

The verification is done in the appserver mode. There is no way to specify the --portability switch when using the ant task.

There is currently no ant task integrating verifier to be used at development time. However, you can use the ant exec task to invoke the verifier. For e.g.

 <target name="all"> <!-- verifiy the bean ear --> <exec executable="cmd"> <arg value="/c"/> <arg value="verifier.bat"/> <arg value="${bean.ear.name}"/> </exec> </target> 

Admin Console

You can also verify the archive at deployment time by enabling the Run Verifier check box.

 

admin-verify.jpg

 

 

Java AVK

Java AVK for Enterprise is a tool kit that can help with testing of portability of Java EE/J2EE application across different Java EE/J2EE application servers. Java AVK for Enterprise can perform both static verification and dynamic verification. From the point of view of testing portability of applications for migration, static verification is the most useful.

At installation time, Java AVK for Enterprise prompts the user to select either the Appserver bundled with the AVK or use an an Application server already installed. The Application Server must be 9 Platform Edition. As a result, GlassFish or SJSAS bundles installed separately cannot be used with Java AVK for Enterprise. Java AVK installation will fail with "Not a valid Application Server version. This is one of the reasons why I find it easier to use the GlassFish verifier rather than Java EE AVK in my migration examples. i.e. I prefer or have to use an existing GlassFish version (GlassFish, SJSAS 9.X, GlassFish + MySql bundle) which may not work with the Java AVK for Enterprise.

Java AVK for Enterprise does support a ArchiveTest ant task, which provides limited control over a few of the options.

Summary

For most of my migration examples (at least so far) I have found the GlassFish verfier to be useful and easiest to use.

As I outlined in Migrate to GlassFish acitivities , I am migrating samples from different application servers to GlassFish to illustrate migration to GlassFish. Here, I selected the WebLogic's "JSP SimpleTag" s ]]>Simple Tag Sample Application

The sample application that I migrated is the JSP Simple Tagsample from the WebLogic 9.2 distribution. The sample uses the Simple TAG API for iterating through a collection and accessing a database. I used the GlassFish + MySql bundle, resource injection, virtual directory mapping to migrate the application.

The source for the WebLogic sample is in the directory wls-install/weblogic92/samples/server/examples/src/examples/webapp/jsp/tags/simple.

To try the migrated sample to GlassFish

Deployment: WLS Split Directory -> GF Exploded Directory

This sample uses a split directory development structure. Thus, to deploy on GlassFish, I first generated a directory in exploded format using an ant build target in the build.xml for the WebLogic sample as follows:

  • cd wls-install/weblogic92/samples/server/examples/src/webapp/jsp/tags/simple
  • ant build
  • ant package.exploded.ear

The above will build a jspSimpleTagEar directory in exploded format as shown below:

 WebLogic: Exploded EAR jspSimpleTagEar META-INF .. application.xml .. weblogic-application.xml jspSimpleTagWar .. ExamplesFooter.jsp .. ExamplesHeader.jsp .. SimpleTag.jsp .. wls_examples.css ++ WEB-INF .. web.xml .. weblogic.xml ++ classes/examples/webapp/jsp/tags/simple .. ExecuteSql.class .. IteratorTag.class ++ tlds .. simpleTag.tld 

I repackaged the exploded directory as follows:

  • Removed weblogic-application.xml. It was empty in this example.
  • Replaced weblogic.xml with sun-web.xml. The mapping is described below.
  • Modified simpleTag.jsp to use datasource name
  • Modified ExecuteSql.java to use resource injection of DataSource.
  • Modified ExamplesHeader.jsp to handle relative path in virtual directories.

Thus, the exploded ear on GlassFish is as follows:

 GlassFish: Exploded EAR  jspSimpleTagEar META-INF .. application.xml jspSimpleTagWar .. ExamplesFooter.jsp .. ExamplesHeader.jsp .. SimpleTag.jsp .. wls_examples.css ++ WEB-INF .. web.xml .. sun-web.xml ++ classes/examples/webapp/jsp/tags/simple .. ExecuteSql.class .. IteratorTag.class ++ tlds .. simpleTag.tld 

Then I deployed the exploded directory gf_jspSimpleTag on GlassFish:

 asadmin deploydir gf_jspSimpleTag 

PointBase -> MySql

The WebLogic sample uses PointBase database. While GlassFish does support PointBase, I chose to use MySql and used the GlassFish + MySql bundle which can be downloaded from http://java.sun.com/javaee/downloads/index.jsp. Next, I prepared the MySql database for the example - creating, configuring and populating.

Database name change

The WebLogic sample uses a database "examples-dataSource-demoXAPool". This step is not necessary but I wanted a more suitable name related to my migration work.

Create and Populate wls92examples database

Next, I created the wls92examples and populated it. To populate the script I used a script that came with the WebLogic sample. So here are the steps:

 $ cd gf-install/mysql/bin $ mysql -u root mysql> create database wls92examples; mysql> grant all on wls92examples.* to 'sekhar'@'localhost' identified by 'secretpwd'; mysql> quit $ mysql -u sekhar -p Enter password: secretepwd mysql> use wls92examples; mysql> source wls-install/weblogic92/samples/server/examples/src/examples/common/ddl/demo_mysql.ddl mysql> quit 

Create a MySqlPool Connection Pool

Next, I created a new JDBC Connection Pool

  • Name: MySqlPool
  • Resource type: javax.sql.DataSource
  • Datbase vendor: MySQL

I set the following properties using the GlassFish Admin Console. The properties can be set either when the MySqlPool connection pool is created or after pool creation by

  • Navigate to: Resources -> Connection Pools -> MySqlPool
  • Goto AdditionalProperties tab
  • set the properties described below.

The properties that need to be set are:

    • RelaxAutoCommit = true
      This property needs to be set to true since ExecuteSql class implements the following method from javax.servlet.jsp.tagext.TryCatchFinally interface:
       public void doCatch(Throwable t) throws Throwable { if (conn != null) conn.rollback(); throw t; } 

      The code makes an assumption that the autocommit is false. If autocommit is true, the above method will result in an exception ( logged to <gf-domain>/server.log file ):

       com.mysql.jdbc.exceptions.MySQLNonTransientConnectionException: Can't call rollback when autocommit=true 
    • user, password properties
      Set the user and password used in creating and populating the "wls92examples" database.

 

  • URL property
    Set the URL property to jdbc:mysql://:3306/wls92examples . This URL will be used to connect to the wls92examples database.

 

Create JDBC Resource jdbc/wls92examples

Create a JDBC Resource as follows:

  • JNDI name : jdbc/wls92examples
  • Pool name : MySqlPool ( created in above step )
  • Description:

Source Code Changes

I modified the code as described here.

SimpleTag.jsp: Data source name change

Since I changed the database name to "wls92examples" (as described above), accordingly, I changed the datasource name accordingly here as well from

 // WebLogic String dataSourceName = "examples-dataSource-demoXAPool"; 

to

 // GlassFish String dataSourceName = "wls92examples; 

ExecuteSql.java: Resource injection of DataSource

The ExecuteSql.java class establishes a connection to a database has non portable code

  • use of weblogic.jndi.WLInitialContextFactory
  • JNDI lookup on t3://localhost:7001

I wanted to make the code more portable. So I rewrote the code to use resource injection in Java EE 5.

 //File name: ExecuteSql.java  import javax.sql.DataSource; import javax.annotation.Resource; public class ExecuteSql extends BodyTagSupport implements TryCatchFinally { .... @Resource(name="jdbc/wls92examples") DataSource wlsds; ... omitted other modifcations to code ... } 

Resource injection works with managed classes. I was able to resource injection since ExceuteSql class is a managed class. ExecuteSql extends BodyTagSupport which in turn implements javax.servlet.jsp.tagext.Tag interface.

weblogic.xml -> sun-web.xml Mapping

I migrated the appserver specific deployment descriptor : weblogic to sun-web.xml as follows (Additional details ater the mapping).

 <!-- weblogic.xml --> <?xml version="1.0" encoding="ISO-8859-1"?> <weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"> <jsp-descriptor> <page-check-seconds>1</page-check-seconds> <verbose>true</verbose> </jsp-descriptor> <!-- Use the virtual-directory-mapping element to specify document roots other than the default document root of the Web application for certain kinds of requests, such as image requests. All images for a set of Web applications can be stored in a single location, and need not be copied to the document root of each Web application that uses them. For an incoming request, if a virtual directory has been specified servlet container will search for the requested resource first in the virtual directory and then in the Web application's original document root. --> <virtual-directory-mapping> <local-path>C:/bea/weblogic92/samples/server/</local-path> <url-pattern>/examples/*</url-pattern> </virtual-directory-mapping> <virtual-directory-mapping> <local-path>C:/bea/weblogic92/samples/server/examples/build</local-path> <url-pattern>images/*</url-pattern> </virtual-directory-mapping>  <!-- sun-web.xml --> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd"> <sun-web-app> <jsp-config> <property name="modificationTestInterval" value="1"/> <property name="verbose" value="true"/> </jsp-config> <property name="alternatedocroot_1" value="from=/examples/* dir=C:/bea/weblogic92/samples/server/"/> <property name="alternatedocroot_2" value="from=/images/* dir=C:/bea/weblogic92/samples/server/examples/build"/> </sun-web-app> 

Virtual Directory Mapping

The example uses virtual directory mapping to locate the BEA logo in the example. The GlassFish equivalent for WebLogic's virtual-directory-mapping is the alternatedocroot property. I also had to make two more changes to bring up the BEA logo. Of course, I could have replaced it with a GlassFish logo once I was done :-) but I am trying to show migration issues here.

URL Pattern

In alternatedocroot_2, I changed the URL pattern from images/* to /images/*. Withtout the preceeding / , the following WARNING is generated in the GlassFish server.log file (i.e. gf-install/domain/domain1/logs/server.log )

 [#|2008-05-15T17:57:49.500-0400|WARNING|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=24;_ThreadName=httpWorkerThread-4848-1;images/*;_RequestID=1b29dda8-9133-4863-b0ef-9b7ec44c8576;|WEB0504: URL pattern images/* for alternate docbase is invalid|#] 

Relative Path in URL

Another issue I ran into was related to use of a relative path in ExamplesHeader.jsp. This file contains a reference to SRC using a relative path as shown in the following fragment.

 <!-- weblogic : ExamplesHeader.jsp fragment --> ... <!-- TITLE --> <table border=0 cellspacing="18" cellpadding="0"> <tr> <td valign="top"> <a HREF="http://www.bea.com"><IMG SRC="../../../../images/logo_tm_onwt.jpg" alt="BEA Logo" width="161" height="96" border="0"></a> <h3><%=request.getParameter("title")%></h3> </td> </tr> </table> ... 

The relative path used for SRC did not work (the BEA logo won't come up). I changed the SRC reference to images/* .

 <!-- GlassFish : ExamplesHeader.jsp fragment --> ... <table border=0 cellspacing="18" cellpadding="0"> <tr> <td valign="top"> <a HREF="http://www.bea.com"><IMG SRC="images/logo_tm_onwt.jpg" alt="BEA Logo" width="161" height="96" border="0"></a> <h3><%=request.getParameter("title")%></h3> </td> </tr> </table> ... 

Summary

Except for the rewrite of the code to take advantage of resource injection for injecting a datasource, the code changes were minimal.

As always, feedback is welcome. For questions and feedback, visit <a h

As I outlined in Migrate to GlassFish acitivities , I am migrating samples from different application servers to GlassFish to illustrate migration to GlassFish. Here, I selected the WebLogic's "JSP TagHandler" sample to migrate to GlassFish.

JSP Tag Handler Sample Application

The sample application that I migrated is the JSP Tag Handler sample from WebLogic 9.2 distribution. The JSP Tag Handler application is an Address Label Maker that uses JSP custom tags, tag handlers, virtual directory mapping, split directory development.

The source for the WebLogic sample is in the directorywls-install/weblogic92/samples/server/examples/src/webapp/jsp/tags/taghandler.

To try the migrated sample to GlassFish

Deployment: WLS Split Directory -> GF Exploded Directory

The JSP TagHandler example uses a split development directory structure. In this approach, there are two directories - source and build and supporting ant scripts and config files. The source and build directory together contains the file for the J2EE/Java EE application. GlassFish ,on the other hand, supports deployment of a Java EE application from a directory that is an exploded format of a deployable archive. Thus, to deploy on GlassFish, I first generated a EAR file in exploded format using an ant build target in the build.xml for the WebLogic sample as follows:

  • cdwls-install/weblogic92/samples/server/examples/src/webapp/jsp/tags/taghandler
  • ant build
  • ant package.exploded.ear

The above will build a jsfTagHandlerEar directory in exploded format as shown below:

WebLogic: Exploded EAR 
jspTagHandlerEar
++++ META-INF
     .... application.xml
     .... weblogic-application.xml
++++ jspTagHandlerWar
     .... ExamplesFooter.jsp
     .... ExamplesHeader.jsp
     .... TagHandler.jsp
     .... wls_examples.css
     ++++ WEB-INF
          .... web.xml
          .... weblogic.xml
          ++++ lib
               .... jstl.jar
               .... standard.jar
          ++++ tags
               .... tagHandler.tag

Next, I repackaged the EAR file to replace WebLogic specific artifacts with GF artificats by the making the following changes:

  • Removed jstl.jar. jstl.jar is the JavaServer Pages Standard Tag Library (JSTL) and is already included ingf-install/lib/javaee.jar.
  • Removed standards.jar. The tags are distributed ingf-install/lib/appserv-jstl.jar .
  • Removed WEB-INF/lib since neither jstl.jar nor standard.jar are required to be packaged.
  • Removed weblogic-application.xml. It was empty in this example.
  • Replaced weblogic.xml with sun-web.xml. The mapping is described below.

Thus, the exploded directory for deployment on GlassFish is as follows:

GlassFish: Exploded EAR 
gf_jspTagHandlerEar
++++ META-INF
     .... application.xml
++++ jspTagHandlerWar
     .... ExamplesFooter.jsp
     .... ExamplesHeader.jsp
     .... TagHandler.jsp
     .... wls_examples.css
     ++++ WEB-INF
          .... web.xml
          .... sun-web.xml
          ++++ tags
               .... tagHandler.tag

Then, I deployed the exploded directory gf_jspTagHandlerEar on GlassFish:

  • asadmin deploydir gf_jspTagHandlerEar

weblogic.xml -> sun-web.xml Mapping

The following is how I mapped the weblogic.xml to sun-web.xml. Additional details are after the mapping.

  <!-- weblogic.xml -->

  <?xml version="1.0" encoding="ISO-8859-1"?>
  <weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90">
  <jsp-descriptor>
    <page-check-seconds>1</page-check-seconds>
    <verbose>true</verbose>
  </jsp-descriptor>
    <!--
  Use the virtual-directory-mapping element to specify document roots other
  than the default document root of the Web application for certain kinds of
  requests, such as image requests. All images for a set of Web applications
  can be stored in a single location, and need not be copied to the document
  root of each Web application that uses them. For an incoming request, if a
  virtual directory has been specified servlet container will search for the
  requested resource first in the virtual directory and then in the
  Web application's original document root.
  -->
  <virtual-directory-mapping>
    <local-path>C:/bea/weblogic92/samples/server/</local-path>
    <url-pattern>/examples/*</url-pattern>
  </virtual-directory-mapping>
  <virtual-directory-mapping>
    <local-path>C:/bea/weblogic92/samples/server/examples/build</local-path>
    <url-pattern>images/*</url-pattern>
  </virtual-directory-mapping>


  <!-- sun-web.xml -->
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
  <sun-web-app>
    <jsp-config>
      <property name="modificationTestInterval" value="1"/>
      <property name="verbose" value="true"/>
    </jsp-config>
    
    <property name="alternatedocroot_1" value="from=/examples/* dir=C:/bea/weblogic92/samples/server/"/>
    <property name="alternatedocroot_2" value="from=/images/* dir=C:/bea/weblogic92/samples/server/examples/build"/>
  </sun-web-app>

Virtual Directory Mapping

The example uses virtual directory mapping to locate the BEA logo in the example. The GlassFish equivalent for WebLogic's virtual-directory-mapping is the alternatedocroot property. I also had to make two more changes to bring up the BEA logo. Of course, I could have replaced it with a GlassFish logo once I was done :-) but I am trying to show migration issues here.

URL Pattern

In alternatedocroot_2, I changed the URL pattern from images/* to /images/*. Withtout the preceeding / , the following WARNING is generated in the GlassFish server.log file (i.e.gf-install/domain/domain1/logs/server.log )

    [#|2008-05-15T17:57:49.500-0400|WARNING|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=24;_ThreadName=httpWorkerThread-4848-1;images/*;_RequestID=1b29dda8-9133-4863-b0ef-9b7ec44c8576;|WEB0504: URL pattern images/* for alternate docbase is invalid|#]

Relative Path in URL

Another issue I ran into was related to use of a relative path in ExamplesHeader.jsp. This file contains a reference to SRC using a relative path as shown in the following fragment.

<!-- weblogic : ExamplesHeader.jsp fragment -->
...

<!-- TITLE -->
<table border=0 cellspacing="18" cellpadding="0">
  <tr>
    <td valign="top">
      <a HREF="http://www.bea.com"><IMG SRC="../../../../images/logo_tm_onwt.jpg" alt="BEA Logo" width="161" height="96" border="0"></a>
      <h3><%=request.getParameter("title")%></h3>
    </td>
  </tr>
</table>
...

The relative path used for SRC did not work (the BEA logo won't come up). I changed the SRC reference to images/* .

<!-- GlassFish : ExamplesHeader.jsp fragment -->
...

<table border=0 cellspacing="18" cellpadding="0">
  <tr>
    <td valign="top">
      <a HREF="http://www.bea.com"><IMG SRC="images/logo_tm_onwt.jpg" alt="BEA Logo" width="161" height="96" border="0"></a>
      <h3><%=request.getParameter("title")%></h3>
    </td>
  </tr>
</table>
...

Summary

The code changes were minimal. I plan to followup up and provide more details on the migration issues outlined above.

As always, feedback is welcome. For questions and feedback, visit Migrate To GlassFish project and follow the "Discussion Forums" link .

As I outlined in Migrate to GlassFish acitivities , I am migrating samples from different application servers to GlassFish to illustrate migration to GlassFish. Here, I selected a WebSphere Application Server V ]]>WebSphere Sample Application

The sample application I selected is BasicCalculator from the WebSphere Application Server V6.1 Technology Samples (part of the Samples Gallery). Note that it is WebSphere V6.1 not WebSphere Application Server Community Edition (WAS CE). The Technology Samples demonstrate the use of Java EE/J2EE and WebSphere technologies. So I thought these would be good candidates to illustrate migration of WebSphere applications to GlassFish. Also, since WebSphere Application Server V6.1 supports J2EE 1.4, I expect the migration example to be of interest to developers working on for e.g. production applications based on J2EE 1.4

The Technology Samples is a collection of following samples (packaged in a single TechnologySamples.ear file):

  • Enterprise Beans - A basic calculator application using a stateless session bean, performs arithmetic operations (+, -, * , / )
  • J2EE Application Client - A basic calculator application that uses the stateless session bean.
  • Security - Consists of two samples FormLogin and JAASLogin .

For simplicity, I migrated only the Enterprise Beans sample to GlassFish. I plan to migrate the rest of them at a later date. To try the migrated sample on GlassFish,

Summary: The migration was straight forward. No code changes were required. The application used standard J2EE 1.4 features - stateless beans, JSP, ejb references and so on. The only problem was with the url-pattern used in the WEB-INF/web.xml. Most of the work was in verifying WAS ear file, generating Sun Deployment Descriptors from WAS ear, and then packaging an ear for deployment on GlassFish.

WAS BasicCalcualtor Ear file

In order to migrate only the BasicCalculator, I used the Ant's build scripts in the Technology Samples to repackage the classes, WAS deployment descriptors and other files and generate a BasicCalculator.ear file containing only the Enterprise Beans sample. The layout of the WAS ear file is as follows:

 WebSphere Application Server BasicCalculator Ear file  BasicCalculator.ear .... META-INF/ application.xml ibm-application-bnd.xmi ibm-application-ext.xmi MANIFEST.MF .... BasicCalculator.jar .... META-INF/ .... MANIFEST.MF .... ejb-jar.xml .... ibm-ejb-jar-bnd.xmi .... ibm-ejb-jar-ext.xmi .... com/ibm/websphere/samples/technologysamples/ejb/stateless/basiccalculatorejb/ .... BasicCalculator.class .... BasicCalculatorBean.class .... BasicCalculatorHome.class .... BasicCalculatorWeb.jar .... BasicCalculator.jsp .... META-INF/ .... MANIFEST.MF .... WEB-INF/ .... ibm-web-bnd.xmi .... ibm-web-ext.xmi .... web.xml .... classes/com/ibm/websphere/samples/technologysamples/ejb/stateless/basiccalculatorwar/ .... BasicCalculatorJspBean.class .... BasicCalculatorServlet.class 

Verification of WAS Ear file

Next, I ran the GlassFish verifier on the WAS ear file to save time by catch any errors before deployment:

$ verifier was-BasicCalculator.ear

The GlassFish verifier generated the following error. It is turning out to be handy tool in migrating to GlassFish. The GlassFish verifier generates an output file was-BasicCalculator.ear.txt in the directory where it is invoked.

 --------------------------- STATIC VERIFICATION RESULTS --------------------------- ----------------------------------------------------- ERRORS THAT OCCURRED WHILE RUNNING STATIC VERIFICATION ----------------------------------------------------- ---------------------------------- NUMBER OF FAILURES/WARNINGS/ERRORS ---------------------------------- # of Failures : 0 # of Warnings : 0 # of Errors : 1 Error Name : Could not verify successfully. Error Description : java.lang.IllegalArgumentException: Invalid URL Pattern: [BasicCalculatorServlet] 

So, I looked in WAS WEB-INF/web.xml and found the following URL pattern:

 <web-app id="WebApp_1"> .. <servlet-mapping id="ServletMapping_1"> <servlet-name>BasicCalcServlet</servlet-name> <url-pattern>BasicCalculatorServlet</url-pattern> </servlet-mapping> </web-app> 

It is not immediately obvious why the url-pattern works on WebSphere but not on GlassFish. The Servlet DTD in the WAS web.xml was as required by Servlet 2.5 spec

 <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> 

and SVR 11.2 of Servlet Spec indicates an exact match of the url-pattern. I was guessing a leading / might fix it. Instead of going down this path, I let GF migration tool fixed the problem for me.

Migration tool for GlassFish

I ran the Migration Tool for GlassFish (download here ) on the WAS ear file as:

$ asmigrate -S ws50 -T glassfish -t was2gf TechnologySamples.ear

The Migration Tool for GlassFish currently supports WAS 4.x, 5.x but I was using WAS 6.1. There are some differences in WAS 5.x and WAS 6.1 deployment descriptor files. Nonetheless, the GF Migration Tool took the deployent descriptors ( Java EE standard as well ibm*.xmi files) and generated the following files for GlassFish:

  • web.xml
  • ejb-jar.xml
  • sun-web.xml
  • sun-ejb-jar.xml

The generated web.xml had the following url-pattern - note the leading / . This fixed the problem.

 <web-app> .. <servlet-mapping> <servlet-name>BasicCalcServlet</servlet-name> <url-pattern>/BasicCalculatorServlet</url-pattern> </servlet-mapping> </web-app> 

GlassFish BasicCalculator ear file

Next, using Ant build script I repackaged compiled classes, GF Migration Tool generated files etc into an ear successfully deployed on GlassFish. The GF Migration Tool generates build scripts (although it did not in this case - I will be investigating this). Notethat the only difference between the WAS ear and the GlassFish ear were the GF Migration Tool generated files. So here is what the BasicCalculator.ear for GlassFish looks like.

 GlassFish Application Server BasicCalculator Ear file  BasicCalculator.ear .... META-INF/ .... application.xml .... MANIFEST.MF .... BasicCalculator.jar .... META-INF/ .... MANIFEST.MF .... ejb-jar.xml .... sun-ejb-jar.xml .... com/ibm/websphere/samples/technologysamples/ejb/stateless/basiccalculatorejb/ .... BasicCalculator.class .... BasicCalculatorBean.class .... BasicCalculatorHome.class .... BasicCalculatorWeb.jar .... BasicCalculator.jsp .... META-INF/ .... MANIFEST.MF .... WEB-INF/ .... sun-web.xml .... web.xml .... classes/com/ibm/websphere/samples/technologysamples/ejb/stateless/basiccalculatorwar/ .... BasicCalculatorJspBean.class .... BasicCalculatorServlet.class 

JNDI names: ibm-*-bnd.xmi files

WAS uses binding files that contain JNDI names to reference other components in the application. In this particular example, they are ibm-ejb-jar-bnd.xmi, ibm-web-bnd.xmi . The GF Migration Tool migrated the JNDI names to sun-ejb-jar.xml and sun-web.xml as shown below.

  <!-- ibm-ejb-jar-bnd.xmi -->  <ejbbnd:EJBJarBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:ejbbnd="ejbbnd.xmi" xmlns:commonbnd="commonbnd.xmi" xmlns:ejb="ejb.xmi" xmi:id="ejb-jar_ID_Bnd"> .... <ejbBindings xmi:id="Session_1_Bnd" jndiName="WSsamples/BasicCalculator"> <enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#Session_1"/> </ejbBindings> </ejbbnd:EJBJarBinding> | V  <!-- sun-ejb-jar.xml -->  <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD ..."> <sun-ejb-jar> <enterprise-beans> <ejb> <ejb-name>BasicCalculator</ejb-name> <jndi-name>WSsamples/BasicCalculator</jndi-name> </ejb> </enterprise-beans> </sun-ejb-jar> 
  <!-- ibm-web-bnd.xmi -->  <?xml version="1.0" encoding="UTF-8"?> <webappbnd:WebAppBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappbnd="webappbnd.xmi" xmlns:webapplication="webapplication.xmi" xmlns:commonbnd="commonbnd.xmi" xmlns:common="common.xmi" xmi:id="WebApp_1_Bnd" virtualHostName="default_host"> <webapp href="WEB-INF/web.xml#WebApp_1"/> <ejbRefBindings xmi:id="EjbRefBinding_1" jndiName="WSsamples/BasicCalculator"> <bindingEjbRef href="WEB-INF/web.xml#EjbRef_1"/> </ejbRefBindings> </webappbnd:WebAppBinding> | V  <!-- sun-web.xml -->  <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD ..."> <sun-web-app> <ejb-ref> <ejb-ref-name>WSsamples/BasicCalculator</ejb-ref-name> <jndi-name>WSsamples/BasicCalculator</jndi-name> </ejb-ref> </sun-web-app> 

Id Mapping

As I noted above, in WAS every XML element in the deployment descriptor has an XML id attribute used to reference an XML element (for either standard or ibm* files). For e.g.

 <!-- WAS : web.xml --> <web-app id="WebApp_1"> .... <servlet-mapping id="ServletMapping_1"> .... </servlet-mapping> .... </web-app> 

It looks like XML id attributes are automatically generated by a WAS assembly tool (e.g. Application Server Toolkit and Rationale Application Developer) . Any input from WebSphere developers ?

GF Migration Tool drops the XML id attributes since they are not used by the Sun specific deployment descriptors. Here is the generated web.xml.

 <!-- Generated by Migration Tool for GlassFish: web.xml --> <web-app> .... <servlet-mapping> .... </servlet-mapping> .... </web-app> 

Summary

So,to summarize, migrating J2EE/Java EE compliant applications such as this one involve minimal or no code changes. Furthermore GlassFish verifier and Migration Tool for GlassFish are helpful in migrating to GlassFish. You feedback on the tools would be valuable. The GlassFish verifier is part of the GlassFish distribution and is in /bin directory. You can download the Migration Tool from here. Use Migrate To GlassFish Issuetracker to file issues against the GF Migration Tool. I have started to do this myself and encourage others to do so as well. I will be back with more examples. As always, your feedback is welcome.

As part of the Migrate to GlassFish acitivities, I migrated a JBoss sample to GlassFish. I am going to describe what I had to do to migrate the application.

Sample Application

The sample application I migrated is "Sample JSF-EJB3 Application" from JBoss Getting Started Guide. The sample can be obtained by downloading Examples Download, unzipping and cding to gettingstarted/jsfebj3 directory. To summarize the sample is a Todo application that uses JSF, facelets, Java Persistence, EJB 3 sessions beans. For more detailed documentation on the sample seeSample JSF-EJB3 Application . Refer to this documentation for additional context as you read the rest of the blog. For most part, the migration was easy.

If you would like to try out the migrated sample on GlassFish,

  • download the migrated Glassfish JSF-EFJ3 ear.
  • Start database: asdmin start-database
  • Start server : asadmin start-domain
  • Deploy : asadmin deploy --user admin --passwordfile file-with-admin-pwd ear
    The component name after deployment is gf-jsfejb3 (used for e.g. in listing, undeployment).
  • Access http://localhost:8080/jsfejb3

Facelets

The sample uses Facelets. For the purposes of this example, Facelets:

  • work with JSF 1.2 and GlassFish supports JSF 1.2 (requirement of Java EE 5).
  • run on GlassFish but jsf-facelets.jar is needed
  • use <faces-config.xml> for configuration. In particular the only required intergration point between JSF and Facelets is <view-handler> in < face-config.xml>. The JBoss sample uses: 
       <faces-config>
          <application>
            <view-handler>
              <com.sun.facelets.FaceletViewHandler
            </view-handler>
          </application>
        </faces-config>
    

The JBoss sample bundles jsf-facelets.jar "jsfejb3.ear ! app.war#WEB-INF/lib/jsf-facelets.jar". I continued to do the same for GlassFish sample in "gf-jsfejb3.ear ! app.war # WEB-INF/lib/jsf-facelets.jar".

JNDI Lookup of local ejb

The JBoss sample contains a TodoBean that uses JNDI to lookup a local ejb as follows:

    public class TodoBean {

        private Todo todo;
        ...

        private TodoDaoInt getDao () {
        try {
            InitialContext ctx = new InitialContext();
            return (TodoDaoInt) ctx.lookup("jsfejb3/TodoDao/local");
        } catch (Exception e) {
            e.printStackTrace();
            throw new RuntimeException("couldn't lookup Dao", e);
        }
    }
   
    @Stateless
    public class TodoDao implements TodoDaoInt { ... }
  
    public interface TodoDaoInt { ... }

The JNDI name "jsfejb3/TodoDao/local" is nonstandard. I changed it to "java:comp/env/ejb/TodoDao" and added ejb-local-ref to web.xml

     // code changes to TodoBean class
     InitialContext ctx = new InitialContext();
     return (TodoDaoInt)ctx.lookup("java:comp/env/ejb/TodoDao");

    // added to web.xml
    <ejb-local-ref>
        <ejb-ref-name>ejb/TodoDao</ejb-ref-name>
        <ejb-ref-type>Session</ejb-ref-type>
        <local-home/>
        <local>TodoDaoInt</local>
    </ejb-local-ref>

Java EE 5 allows injection of entities into a managed class using dependency injection. GlassFish supports dependency injection (For JBoss support - see Sessions Beans and EJB3 Caveats). I will explore using dependency injection for migrating the sample to GlassFish at a future date.

Persistence Provider

The sample uses Hibernate as the persistence provider and HSQL database, while for GlassFish default persistence provider is Toplink and the database is Java DB . For this particular example, I chose to switch to Toplink and Java 2DB. (Other GF forum threads, blogs etc describe integration of Hibernate in GlassFish.)

So here is the "jsfejb3.ear ! app.jar # META-INF/persistence.xml" from the JBoss sample:

  <persistence>
    <persistence-unit name="helloworld">
      <provider>org.hibernate.ejb.HibernatePersistence</provider>
      <jta-data-source>java:/DefaultDS</jta-data-source>
      <properties>
        <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
        <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
      </properties>
    </persistence-unit>
  </persistence>

And here is "jsfejb3.ear ! app.jar # META-INF/persistence.xml" for GlassFish migrated sample.

  <persistence>
    <persistence-unit name="helloworld">
      <jta-data-source>jdbc/__default</jta-data-source>
      <properties>
        <property name="toplink.ddl-generation" value="drop-and-create-tables"/>
      </properties>
   </persistence-unit>
  </persistence>

I did notice two differences as a result of swtiching persistence providers.

Pre-population of database at deployment time: The example contains an import.sql file containing SQL statements which prepopulates the database with a list of items. For e.g.

     insert into Todo (id, title, description) values (1, 'This is a title', 'The description is here!')
It appears that Hibnerate will execute the import.sql if found on classpath. Does such a similar mechanism exist in Toplink ? I looked but could not find any.
I would love to hear feedback from Toplink developers. 

Warning message on dropping of tables: During deployment a warning message is generated. It does not impact the deployment or running of the application. I started an email thread on this. But my analysis so far. In the following entity class:

    @Entity
    public class Todo implements Serializable {
        ...
        @Id @GeneratedValue
        public long getId() { return id;}
        ...
    }

the @GeneratedValue defaults to @GeneratedValue.AUTO which leaves the primary key mapping to the persistence provider. And in Toplink seems to generate a Table for @GeneratedValue.AUTO . When the sample application is deployed, the actual data tables are dropped but not the table generated for the primary key. Hence the warning message. However, as I said, it does not prevent the application from working.

Packaging changes

Here is a summary of packaging changes I made to JBoss ear (by modifying build.xml).

  • In app.war moved TodoBean.class from WEB-INF/ to WEB-INF/classes.
    In JBoss sample, TodoBean.class is packaged as "jboss-jsfejb3.ear ! app.war ! TodoBean.class" . However, app.war failed verification by GlassFish verifier. So I moved it TodoBean.class to "gf-jsfejb3.ear ! app.war # WEB-INF/classes/TodoBean.class"
  • excluded "jsfejb3.ear # META-INF/jboss-app.xml" It is specific to JBoss and deals with class loader repositories.

As always, feedback is welcome. For questions and feedback, visit Migrate To GlassFish project and follow the "Discussion Forums" link .

Here is a list of activities related to the Migrate to GlassFish project that I am working on. There is a timeline towards the end of activities. Let me know your feedback. Oh, by the way, here is the full quote:

Four steps to achivement: "Plan purposefully. Prepare prayerfully. Proceed positively. Pursue persistently." William A. Ward.

Examples

I am going to be taking some examples and migrating them to GlassFish. The purpose is to show migration issues and solutions. Here are some examples to get started. I plan to migrate at least one example from each application server and to cover different Java EE technologies.

  • Tomcat 6.x -> GF : Helloworld from Tomcat 6.x distribution. Actually this is already done. See here.
  • JBoss 4.2.2 -> GF: Todo example from JBoss 4.2.2 "Getting Started Guide". This example uses JSF, facelets, localejbs, Persistence API. I am close to finishing this.
  • Websphere 6.x -> GF: The Samples Gallery (installed by default on a typical Websphere installation) contains several examples. I plan to pick one or two samples - most likely from Tech Samples & Web services samples - to cover different Java EE/J2EE technologies.
  • Weblogic -> GF: I will be looking for an example. If you know of a good example, feel free to suggest.

I can add to that list based on feedback.

Watch for my blogs for more information on the migration examples.

Tools

There are several tools that can assist in migrate to GF. The Migration tool is obviously an important one. More on this shortly. But there are a few others that I have found useful while working on migration examples.

  • verifier tool included in GlassFish distribution. This can be used to verify an ear/war file.
  • Netbeans project (Enterprise -> Packaged Archive). This project allows opening of binary archives, editing of run time deployment descriptors, verification of ear/war and deploying to GlassFish.
  • Java AVK to verify application's use of Java EE/J2EE compatible APIS.

Watch for my future blogs for more information on the tools and examples on when and how to use them in migrating an application to GlassFish.

Migration Tool

The Migration Tool assists in migration to GF through support for migration of deployment descriptors, some custom JSPS and so on. (See herefor details). Some of the plans here are:

  • Run Migration Tool on ears/wars in Examples and capture issues in IssueTracker.
  • Add support for newer versions of application servers.
  • bug fixes and enhancements based on the usage of tool. I started to use the IssueTracker for filing issues with the tool.
  • Make the tool more extensible/pluggable.
  • Examples showing the use of Migration Tool on ears/wars generated on other application servers.

I will blog when I have more information on above.

Migration Guide

I plan to start a migration guide. The idea is that over time this guide will cover a list of migration issues to GF and solutions to them. For example, a search through the GF forums and mailing lists turns up a list of migration issues. The questions have been answered, or under discussions or have RFEs filed against them and so on. It would be useful to start collecting these different issues/answers. So, initialy, I plan to start compiling a list of GF migration issues and start adding them to the migration guide. This can evolve over time to include additional text, examples, etc.

To get an idea of what the guide might contain, here is a sample of topics on which questions related to JBoss -> GF migration that I found on GF forums:

  • Migration of SAR (Service Archives)
  • MBean deployment
  • Multiple questions on SEAM on GlassFish
  • Deployment of resources in EAR
  • Entity caching
  • Dynamic creation of JMS topic
  • Virtual directory mapping - how to on GF.
  • Dynamic Role Handling

You get the idea. I plan to host this "guide" in a wiki format on Migrate to GlassFish . Anyone with a java.net id will be able to edit this guide. So, we really welcome any contributions to this guide.

Watch for my future blog on this topic with additional details.

Migration Tool : On Line Documentation and Online Help

Currently the migration tool comes with two sets of documentation: 

The duplication of content means more maintenance work. So, going forward, we plan to remove the duplication as follows.

Watch for my future blog on the topic.

Timeline of activities

Here is a rough timeline of different activities: 
  • Feb 08, 2008: JBoss -> GF example
  • Feb 15, 2008: Websphere 6.x -> GF example
  • Feb 19, 2008: Verifier example
  • Feb 22, 2008: Weblogic -> GF example
  • Feb 22, 2008: Netbeans plugin for verifier
  • Feb 26, 2008: Java AVK example
  • Feb 11, 2008: Start Migration Guide - ongoing
  • Feb 11, 2008 - Feb 29, 2008: Run migration tool and capture issues in IssueTracker
  • March 1, 2008: Start Migration Tool bug fixing
  • March 1, 2008: Start removal of duplication of Migration Tool Online Documentation and Help menus
  • March 1, 2008: Start investigation of making the tool pluggable/extensible

So there is the plan. Let me know your feedback.

Earlier I introduced the Migrate to GlassFish project. Periodically, I will be taking examples to illustrate migrations to GlassFish. Here, I took the Tomcat example application and migrated it to GlassFish. Even though this is a simple example, it nonetheless illustrates a few of the deployment aspects of GlassFish.

First point to note is that no changes are necessary for the Tomcat sample application itself. Apache Tomcat version 6.0 implements the Servlet 2.5 and JavaServer Pages 2.1 specifications. GlassFish V2 implements which Java EE 5 which requires JSP 2.1 and Servlet 2.5. So you can can simply take the war file and deploy it as shown below:

  • Download and configure GlassFish V2
  • asadmin start-domain
  • asadmin deploy --user admin --passwordfile sample.war

Note:

  • I used the command line admin commands but you can use the admin console GUI.
  • The password file contains the admin password in the form AS_ADMIN_PASSWORD=password-value .

Note that no other GlassFish server specific deployment descriptors (e.g. sun-web.xml ). The context root for the web application is derived from the war file name (in this case "sample"). You can acccess the sample application at http://localhost:8080/sample . If you access the URL, you should see "Hello World" application with two links to "JSP Page" and "Servlet" .

When deployed as shown above, the JSP in the sample application are compiled at runtime the first time the "JSP Page" link is accessed. However, it is possible to precompile JSP at deployment time as follows:

  • asadmin undeploy --user admin --passwordfile passwordfile sample
    asadmin deploy --user admin --passwordfile passwordfile --precompilejsp sample.war

You will find the compiled JSP files can be found ingf-appserver-domain-dir/generated/jsp/j2ee-modules/sample . There are other ways to precompile JSP files. The above was just one way to do it.

Instead of war, you can deploy the sample application in an unpacked form. This is useful during development To do this:

  • unpack the sample.war into sample-dir
  • asadmin deploydir --user admin --passwordfile passwordfile sample-dir

I will be back with more examples.

If you are migrating applications to GlassFish, post your questions and feedback to Migrate To GlassFish forum and visit Migrate To GlassFish project.

We have started a new project Migrate To GlassFish . While J2EE/Java EE specifications cover broadly requirements for developing portable applications, other aspects (e.g. vendor-specific deployment) are application server dependent. The goal of this project is to provide help (tools, documentation, and tech tips) in the migration of J2EE/Java EE applications to the GlassFish application server.

The Migration Tool for GlassFish is a GUI based tool that helps with the migration of application server specific aspects (e.g. config files) to GlassFish application server. See the Overview of Migration Tool for GlassFish for details. To use the Migration Tool

To learn more about the migration tool, see:

You can also find the above links on the Migrate To GlassFish project page

Some migration issues are better addressed by documentation than the migration tool. So another goal of this project is to provide improved documentation on solutions to migration issues. I will be building and hosting the documentation and tech tips on Migrate to GlassFishproject page. I will also be blogging on migration issues/topics regularly.

We are very interested your feedback and participation on your experience with migration of J2EE/Java EE applications to GlassFish application server - problems you encountered, solutions you adopted etc. We will use the feedback from the community to evolve the current Migration Tool and the documentation, tech tips. Use Migrate To GlassFish Forum for feedback. The forum can also be accessed by the "Dicussion forums" link on the Migrate To GlassFish project page . Let us know if you would like to contribute to the project.

The Web Services Stack consists of invididual technologies (e.g. JAX-WS, JAXB, WSIT, XWSS, JAXP) for developing Web services and clients. These technologies are being developed as Java.net projects and ship in multiple releases. To make it easier to locate, navigate, contribute, support these technologies, the existing Java Web services web site has been redesigned. The content on Java Web Services web site is now organized in a tabbed format. And we have added additional content as well. Under the tabs, you will find information related to Web Services technologies such as links to Java.net projects, blogs, tutorials, samples, Java.net Issue tracker, technical articles and tips, downloads and much more.

So spend a few minutes and check out the site. And as always, we welcome your feedback. To provide feedback click on "Contact Us" at the bottom of a page which will take you to Contact Us page. Then select "Web Site or Program Feedback" from the "Feedback" category. Complete the form and submit.

WSIT clients and service providers use JAX-WS/JAXB for interoperating with WCF clients and service providers. JAXB and WCF serialization mechanisms while similar in some aspects, differ in others such as the support for XML schema constructs, datatype <-> XML schema mapping. The Data Contracts chapter in WSIT tutorial discusses some of the common databinding differences between JAXB and the different WCF serialization mechnisms and recommends some guidelines. So, check out the Data Contracts chapter and let us know your feedback at Web Services Interoperability Technology Forum . I will evolve the guidelines based on the feedback.  

Filter Blog

By date: