Stuff I've learned recently…

The answer is, when it’s and EJB3 plug-in inside JBoss 4.

I’ve been playing with the EJB3 spec a lot recently, especially working with the Java Persistence API (JPA) portion for entities. I’ve said it before here, but I’ll say it again — I really like the way it’s put together.

(With one exception, of course, and I’ve talked about that, too. Someday someone will explain to me why the powers that be decided to make unidirectional one-to-many relationships impossible to implement with two tables related by a simple foreign key. My Order class has a collection of OrderLine instances. Why in the world should my OrderLine class have to know what Order it is a part of just so I can use the @ManyToOne annotation in the OrderLine class?? Or, equally silly, why should I have to use a link table in the database to connect Orders to OrderLines when a simple foreign key will do? Please, someone enlighten me.)

When I helped write the EJB 3.0 courseware for Capstone Courseware, we needed a container that supported the spec.  At the time, that meant the Java EE reference implementation — the Sun Java Application Server, also known as Glassfish.

Now, Glassfish is actually a pretty slick server. I like it, especially when compared to earlier versions of the reference implementation. I still plan to eventually move my site to it, once I get a free moment. The thing is, though, it has essentially zero market share.

Admittedly, I don’t actually have data to back that up. I only know what I encounter when I move from company to company in my training classes and occasional consulting engagements. My sense is that, sadly, WebSphere is still the market leader, though they must be losing market share as the new Java EE 5 spec gains popularity. I still meet a fair number of clients who love WebLogic, for good reason. Recently I did an Ajax class at a company that used Oracle 10g AS, which looks solid as well.

Ironically, given that they’re such a database company, Oracle’s commitment to Java is evident on many fronts. One of which, relevant for my purposes, is that by far my favorite EJB 3.0 book, Pro EJB3, was co-written by two Oracle employees, Mike Keith (the co-spec lead) and Merrick Schinariol, the lead engineer for Oracle’s EJB 3 offering. Of course, they better than anyone would be able to explain the bizarre unidirectional many-to-one problem described above, but that’s a different question.

I increasingly encounter companies that use the definitive open-source database, JBoss. Sure, Glassfish is open source too, but it’s taking time to catch on. The Apache foundation has Geronimo, but it’s still awfully new.  Most developers I encounter haven’t yet heard of it, much less considered adopting it.  JBoss, though, shows up in more and more companies. I don’t know if that has anything to do with the fact that it’s now a division of Red Hat or not, but there it is.

I’ve been using JBoss for a few years now, off and on. I really liked the book JBoss at Work and have even sent Scott Davis fan-boy email about it. 🙂 That book used a very early version of JBoss 4.0 and built an increasingly sophisticated application from the ground up. Maintenance is a breeze, configuration is easy, and performance seems to be fine, though I admit I haven’t had cause to push it hard.

That brings me, at long last, to my subject line. We would like to port our EJB 3.0 courseware to JBoss. Not that there’s anything wrong with Glassfish, but a lot of potential clients already use JBoss and they’re exactly the sort of people who like to adopt innovations like EJB 3. Sounds like a win all around.

Even better, the latest version of the O’Reilly book on EJBs (Enterprise JavaBeans 3.0, 5th edition) is now co-authored by Richard Monson-Haefel (of course) and Bill Burke. According to the author bios, Mr. Burke is the chief architect for JBoss, which is really saying something. The book even has a “JBoss workbook” built in, full of example programs to learn EJB 3.0.

So, I naively thought, I’ll just build one of our EAR files in our courseware, configure an appropriate datasource in JBoss, pop it into the server/default/deploy directory, and watch the magic happen.

Except it didn’t. Nothing happened, actually. The web tier ran and loaded all the JSPs and servlets, but no data was to be found.

The first thing I checked was to see that I had the right version of JBoss. The book recommends version 4.0.*, with the EJB 3.0 plug-in. Recently JBoss released version 4.2, which already had the EJB plug-in included, so I grabbed that. It still didn’t work.

I checked that the datasource was operational. Yup, no problem there.

The code compiled cleanly, and all the JSPs were displaying, just no data.

At long last, rooting around in the forums at JBoss, I discovered the problem. Here it is, in a nutshell:

JBoss 4.* is not a Java EE 5 container. It’s still just an old J2EE 1.4 container, with a plug-in to handle the EJB 3.0 stuff.

In practice, that meant that my nice little initialization servlet, which relied on dependency injection (the sweet @EJB annotation) to access the stateless session bean I used to get all the data, was coming up empty. No dependency injection, so no access to the bean, so ultimately no data. It’s back to the Bad Old Days of JNDI lookups, and I loath JNDI with a deep and abiding passion I normally reserve for airport security lines, patent trolls, and the New York Yankees.

My reactions to this realization were:

1. Duh. I knew that JBoss 4 was a J2EE container.   I’ve known it for years.  I hate when I have to learn the same lesson over and over again.  Duh, and duh again.

2. What the heck are they doing writing a book (with a JBoss workbook, no less, designed to be deployed on JBoss 4) on the EJB 3.0 spec if the app server doesn’t even support Java EE 5?

So I went to my downloaded code associated with the workbook, and what did I find? Lo and behold, they skipped the entire web tier! There ain’t a bloody servlet or JSP in the bunch. Every example, and I mean every single example, uses a client side Java class with a main method in it to access the EJBs. I mean, why not? After all, nobody ever does that in practice. They have to, though, because they can’t support the web tier normally associated with the Java EE 5 spec.

The natural move for us, therefore, is either rewrite our own web tier examples to use JNDI, or wait for JBoss to finally release JBoss 5, which is a Java EE 5 container. As you might imagine, I decided to download JBoss 5.0.0Beta2.

I don’t normally do that. Beta software makes me nervous. I’m very reluctant to recommend that a client classroom set up beta software, especially when I know I’m not going to be there to fix any problems. Still, if it’s truly a Java EE 5 container, and we really are relying on the spec, then everything ought to work right out of the box, right?

The answer is, yes and no.  I had some issues with the JDK version (it turns out that JBoss 5 doesn’t yet support JDK 1.6, which is the default in Glassfish), but once I resolved that my simple application worked fine.  My more complex application failed due to some constraint violation that I’m still trying to track down.

Of course, none of the apps work in JBoss 4 without additional modifications.  We’re currently evaluating whether the effort to do that is worth it or not.  I suspect not, especially when JBoss 5 is already out in beta.  The release version shouldn’t be too long in coming.

That also means that within a few months, I expect to see a version of JBoss, WebLogic, Oracle AS, Glassfish, and Geronimo all supporting the Java EE 5 specification.  The one major hold out will then be WebSphere.  Of course, as several IBMers have recently told me, according to their party line (1) IBM is not a technology driven company (!) and (2) their customers don’t want the new Java EE 5 spec anyway.

That’s a rather self-fulfilling prophecy, I’d say.  If I want Java EE 5, and I do, I know to avoid IBM.

Fortunately, soon that will leave me with lots of choices.  Now that MyEclipse 5.5 is out, I also have a development environment that supports the spec, too, and I’m sure Netbeans 6 will do the same.

In the meantime, I’ll stick with Glassfish.  The J2EE/EJB3 hybrid offered by JBoss causes me as many problems as it solves at the moment.