justin-shepard.net

This is the first in a multi-part post about my experiences migrating from JBoss to Glassfish.

First, a bit of background. We’ve recently started swapping our backend over to a service-oriented architecture based on RESTful services. All of our recent development has been involved in the creation of new RESTful services, but we still have a lot of legacy code that happens to take the form of EJBs and RPC-based web services. Faced with the need to either upgrade JBoss or switch to Glassfish, we chose the latter (which will probably make a fine post in the future). This meant we had to make changes to all three service types to get them all working in the new app server.

I’m going to start with the RESTful service migration, mostly because they were far and away the easiest part of the migration. So easy, in fact, that there were only two major issues I ran into.

The first came about because we were prepending numbers on the names of our web application archives. This was done for ordering reasons, and in JBoss, the number was ignored for determining things like context root. Glassfish, on the other hand, uses the entire war name. So while the services were working, and deploying correctly, you needed to have the correct number in the URL when accessing the service. Rather than change all the services to include numbers in the URL, I went looking for another solution. Thanks to the java.net forums (which I found to be an excellent resource throughout the project) I discovered that you could set the context root in the sun-web.xml file of the web app (which then sprung into existence for all our services).

A fairly obvious solution, to be sure, but less so when you’re learning.

The second was finding a deployment solution for our JDBC resources (this, of course, covered more than just the RESTful services, as the EJBs also used them, but this was the first area I hit the problem in). Adding and configuring resources via the Glassfish admin console is very easy, and I had no trouble setting up the resources, but navigating a web console isn’t the most friendly method for a more automated install process. The java.net forums once again proved their worth, leading me to the solution. In this case, the solution is the add-resources command that is part of the command line administration tool.

This solution was doubly nice because we already had XML files for defining our resources in JBoss, and the formats were similar enough that creating the new files was mostly a matter of XML wrangling. This solution also nicely covered other resources, such as the few queues and topics we use for communication.

With those two things taken care of the RESTful services happily took up residence in Glassfish. And with the RESTful services out of the way, it was time to tackle the EJBs.