From JBoss to Glassfish: Part I
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.
Tags: glassfish, java, jboss, rest
This entry was posted on Monday, July 7th, 2008 at 10:48 am and is filed under Tech. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
July 14th, 2008 at 8:32 pm
I was just talking with someone today about the feasibility of running a production app on Glassfish. It’s pretty interesting, and I’ve had fun playing with it at home, but I still want to see it in the wild before I’d be willing to recommend it to clients. I hope that “Part 1″ in the title means you’ll continue to post your adventures.
July 14th, 2008 at 8:52 pm
Yup, the plan is for at least two more of them. Delivered at my usual glacial pace, of course. =)
July 17th, 2008 at 11:28 pm
Hi Mike - you may want to check out http://blogs.sun.com/stories for adoption stories. - eduard/o
March 30th, 2009 at 1:15 pm
Hi Justin,
It’s been a while since you made the switch from Jboss to Glassfish now. How have things worked out in practice?
I’m particularly interested in how you managed to do without being able to do any configuration (Glassfish can’t be configured) and how you lived without services (Glassfish supposedly doesn’t have any services, while Jboss of course does).
Where does things (no configuration, no services) a problem or did you somehow worked around it?
March 30th, 2009 at 7:49 pm
Peter,
I’ve been meaning to do a couple more posts on Glassfish, but things in my neck of the woods have been pretty busy and I just haven’t had time to do so.
To sum up, though, our experience with Glassfish has been pretty positive. We’ve run into a couple of known issues (one with Grizzly on certain versions of Windows, and another that affects connecting to Glassfish from another web container), but aside from that Glassfish has performed well.
I’m curious to know what you mean by “no configuration” and “no services” (though that right there probably answers your question).
April 4th, 2009 at 2:19 pm
>I’m curious to know what you mean by “no configuration” and “no services” (though that right there probably answers your question).
In a way it does. Where I work we aren’t allowed to use Glassfish, the reason given being the fact that it can’t be configured and doesn’t have services.
To be honest, I’m not sure at all what that means. I figured that if it was common knowledge people would immediately recognize those two shortcomings, but apparently they don’t. I can only guess at what it means though; probably it’s related to the fact that Jboss has a URL deployer where you basically deploy an .ear to a single URL and Jboss then takes care of deploying it to some number of underlying machines. That seems pretty ’service’-like to and this is perhaps something which is missing in Glassfish?