I’ll say up front that I haven’t spent a lot of time working with EJBs. Most of what I’d done prior to this was modifying existing EJBs. The creation and deployment of EJBs was handled by other developers (all of whom had moved on by the time this project began). So I had some learning to do.

Our EJB modules pre-date 3.0 with its annotations, which meant lots of XML wrangling for me. The first thing that came up was that the ejb-jar.xml files were missing local EJB reference definitions. I don’t know if JBoss is more permissive than Glassfish or what, but the JNDI lookup in Glassfish failed without the ejb-local-ref elements. I didn’t discover the verifier tool until later on in the migration, so all the missing local references were found by deploying the EJB apps and uncovering them as I tested the system.

A related problem was also that the string constants used to reference the EJBs were often incorrect. I found this especially odd because we were using XDoclet to dynamically generate the EJB interfaces at compile time, and you think it would have gotten it correct. At any rate, I removed the compile-time generation, checked the interfaces into SVN and went on my way (they don’t really change enough to require compile-time generation).

The other big problem was doing the JNDI lookups for the EJBs. Fortunately, perhaps 80% of our JNDI lookups were handled by a single utility class, and it was easy enough to clean up that single class. The remaining JNDI lookups were scattered throughout the client and server code. And in pretty much every case, the initial context factory was passed to the InitialContext as a constant string (referencing the JBoss context factory, naturally) instead of letting that value be found in the environment. While I don’t expect us to change app servers all that often, letting the environment define as much as it can is certainly better than having lookups fail because they’re statically looking for the wrong classes.

Ultimately, I’d say most of our problems stemmed from an assumption that the app server would never change, or relying on vendor-specific behaviors (no doubt fed by the previous assumption). There are still a few places where we’re doing questionable things (several EJBs read configuration information from files, for example) but I have plans to take care of those.

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.