From JBoss to Glassfish: Part II
Welcome to the second post in a three part series about my experience migrating from the JBoss application server to the Glassfish application server. This post details the migration of our EJB-based services, and the trials and tribulations that occurred along the way. I will say that I ran into an interesting problem when writing this post, mostly stemming from the fact that I couldn’t remember what all I had done (SVN history gave me some of that), but various things that I did have been lost to the ether (like the results I had using the verifier tool). In the future, I should keep notes when I’m doing something like this. Anyway, on with the post.
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.
This entry was posted on Wednesday, August 27th, 2008 at 3:43 pm 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.