Blogging Roller

Roller 5 and JBoss 6

Dave Johnson — Thu, 20 Jan 2011 18:00:15 +0000

In my quest to make Roller work on Java EE 6, the next server that I tackled was JBoss 6. In this blog I'll describe how I approached the problem what I learned along the way.

Tested with Hibernate JPA

Roller uses JPA for database storage and specifically the Apache OpenJPA implementation. I knew that JBoss uses the Hibernate JPA implementation and I suspected that there would be JPA portability problems, so I decided to run Roller's JUnit tests against Hibernate JPA. There were many test failures and fortunately, the failures were easy to fix.

Where OpenJPA is lenient, Hibernate JPA is strict about declaring transients fields as transient. So, wherever Hibernate complained, I added the appropriate transient declaration and soon all tests were passing. There were a lot of changes, but they were all trivially easy. Since I first "ported" Roller to ElipseLink JPA, its possible that some of the changes I made for EclipseLink helped with the port to Hibernate JPA.

Those of you who are familiar with Roller's history might remember that this is the second time I worked to make Roller work with Hibernate. Early versions of Roller ran on Hibernate until Roller 4, when we ripped it out because Apache policy does not allow LGPL. With Java EE 6, Roller can run on Hibernate and we don't have to ship the Hibernate jars to do so.

Tried using the Java EE version of the Roller WAR

Since JBoss 6 is a Java EE 6 server, just like Glassfish, I figured I could use the same WAR that I created for Glassfish. That didn't really work out, as you will see below. When I attempted to deploy the Roller WAR to JBoss I ran into two problems:

Problem 1: Xerces and JavaAssist

When I tried to deploy the Roller WAR to JBoss, I ran into class-cast exceptions that indicated that the version the the Xerces XML parser included with Roller conflicts with the one that is included in JBoss. I encountered a similar problem for the JavAssist jars, which are also part of Roller. This was quite surprising to me. Apparently, JBoss uses Xerces and JavAssist internally and for some reason the JBoss internals bleed through and interfere with applications; seems like a bug to me. So, we have to have a special Roller WAR for JBoss without the Xerces and JavaAssist jars in the Roller WAR.

Problem 2: JNDI Datasource Name

The next problem that I encountered was the datasource name. Roller uses the JNDI naming API to lookup its JDBC datasource. In all of the other app servers, we tell people to setup a datasource with the JNDI name 'jdbc/rollerdb' but that name did not work for JBoss. For JBoss, I could only get names of names of the format "java:/name" to work. Unfortunately, with JPA the datasource name must be embedded in the persistence.xml file which is embedded in a JAR file which is embedded in the Roller WAR file. It's in there deep, so we have to produce a special Roller WAR for JBoss with a JBoss-friendly datasource name.

*Please* correct me if I'm wrong. I would love to be wrong about either of these two problems.

Created special Roller WAR just for JBoss

Due to those two problems, I modified the Roller build process to create a special Roller WAR for JBoss without the OpenJPA, Xerces and JavAssist JARs and with the JBoss friendly JNDI name java:/RollerDS inside all included persistence.xml files.

Deployed, tested and updated the docs

Once I worked around those two problems, installing Roller on JBoss was easy. I did the whole thing via the JBoss web console, which was not familiar to me but was pretty easy to understand and use. I documented the whole process in the Roller 5 Install Guide (2MB PDF), with screenshots.

Next up: Roller 5 on WebSphere 8 (beta)

Powered by Struts2 and OpenJPA

Dave Johnson — Mon, 18 Jun 2007 13:06:25 +0000

I stayed up a little too late last night upgrading this site (rollerweblogger.org) to the latest Roller 4.0 code base, which includes the new Struts2 based Admin UI and a new OpenJPA based back-end. No more Hibernate for me. The upgrade was a bit of a rocky road, but the site seems to be working OK now.

JPA JPA JPA

Dave Johnson — Thu, 8 Mar 2007 14:33:59 +0000

That's three JPAs. I've been fighting to get a new Roller back-end running, one that uses the Java Persistence API (JPA) rather than the native Hibernate API that we use now.

Craig Russell and Mitesh Meswani wrote the new JPA back-end and tested it against Toplink/JPA (JPA #1) and the Derby database. I've been refactoring it, updating it for Roller 4.0 and testing it against various other databases and JPA implementations with mixed results.

I tried to run it against MySQL, ran into a bunch of problems and fixed those. Allen switched out Toplink/JPA for Hibernate/JPA (JPA #2), ran into problems and fixed those. I switched out Toplink for Apache OpenJPA-incubating (JPA #3), ran into problems and fixed those. So now we have a back-end implementation that runs against OpenJPA, but requires two small code changes to work against Toplink -- not exactly an ideal situation.

I'm a JPA newbie for sure and still trying to figure this stuff out, but it does seem that switching JPA implementations is not as easy as it ought to be.

In other JPA news...

I didn't realize that the open source version of Toplink that Oracle contributed to Glassfish, Toplink Essentials, is the pee-wee version of the full and still closed source Toplink product. That's why I was somewhat surprised to hear that Oracle is open sourcing and donating the full version of Toplink to the Eclipse foundation.

Two observations about that news. First, this move appears to be a fork that will result in a CDDL licensed version of Toplink Essentials in Glassfish and an EPL version in Eclipse -- I hope I'm wrong about that. And second: apparently IBM will be soon be supporting two versions of JPA: OpenJPA via Geronimo and Toplink/JPA via Eclipse.