When is EJB not Java EE?

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.

7 responses to “When is EJB not Java EE?”

  1. Thanks for sharing your thoughts on GlassFish. Note there was a related (JBoss 4.2) discussion on TSS (http://www.theserverside.com/news/thread.tss?thread_id=45553)
    On GlassFish adoption, we’re tracking a few production experiences here: http://blogs.sun.com/stories . If you want to share your migration to GlassFish experience we’d be feel free to contact us!

  2. Thanks for the TSS link. I didn’t know about that. Since my server is running (shudder, I know) Windows, I need a way to start up the app server as a Windows service. The reference implementation does that, I think. I’m not sure how to do that with Glassfish proper.

    Still, I like both the product and the direction it’s headed in.

  3. Emmanuel Bernard Avatar
    Emmanuel Bernard

    “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?”

    It perfectly works if the persistence provider supports it.

    Hibernate EntityManager supports such a constraint, I know some JPA providers that still need to catch up 🙂

    The spec is ambigious in what has to be supported, Hibernate supports all combinations of logical / physical mappings for associations

  4. Of course I would suggest Solaris, but we also have people using Windows in production too…
    https://glassfish.dev.java.net/javaee5/docs/AG/ablwx.html#ablwz has instructions on setting up GlassFish as a Windows Service (.exe files are in the \lib directory). Let me know if that works for you.

  5. Hi,

    The EJB book, now in its 5th edition, has never addressed servlets or JSP in detail for what is, IMO, a very good reason: EJB is so complicated that we can only do it justice by focusing on it exclusively. I think developers in general are smart enough to understand how to access EJBs from servlets and JSPs as their is plenty documentation on that subject – what O’Reilly’s EJB does is it provides very comprehensive coverage of a very complex topic. Anyway, I thought I would provide a reason as to why we don’t cover JSPs and Servlets in the EJB book.

    All the best,


  6. Hi Richard,

    First, let me say I’ve always been a great admirer of your books. Your writing style is clear and easy to read, and your code examples are always helpful and understandable. I learned much of the original EJB spec from an earlier edition of your book. Actually, I’m one of those people who’ve purchased your EJB book at least three times already, in different editions. I also take any opportunity to recommend your J2EE Web Services book whenever possible. I did that in a training course as recently as last week, where I convinced the training company to provide a copy for every person (15) in the class.

    I certainly agree that the EJB spec by itself is large and complex, though thankfully the 3.0 version is substantially easier than the previous ones. It’s quite natural that you chose to focus your book on the spec. As usual, the book did an excellent job of going through the various facets of it.

    My problem is that EJB 3 is really part of Java EE 5. While it makes sense to focus on a particular aspect of the Java EE technology when learning it, that’s not how I go about choosing an application server. Practically since the J2EE spec was created, and certainly since I learned the difference between a web container like Tomcat and an application server like JBoss, I’ve always looked at the Java EE version number when selecting an app server, not the version number of EJB, or JMS, or even JDBC. I select an app server based on the Java EE version I want it to support and go from there.

    The part that threw me was that your EJB book is co-written by a member of the JBoss family (which is great, of course), but that the workbook and all the examples necessarily use JBoss 4, which only supports J2EE 1.4. Yes, I understand that the EJB3 plug-in works and that JBoss 4.2 has it built-in by default, but it doesn’t support Java EE 5.

    That’s what threw me. Since the JBoss workbook associated with the text used JBoss 4, I “forgot” that JBoss 4 didn’t support anything else in Java EE 5 beyond the EJB3 plug-in. I didn’t care much about the difference until I tried to use the @EJB annotation in a servlet, which is where everything fell apart.

    Of course, if anyone understands that issue, it’s you. I also have to believe that you and your co-author must have discussed this while writing the book, and decided to work around any non-EJB3 requirements.

    You’re also right that I know how to do a JNDI look-up of an EJB from a servlet. It’s just that in Java EE 5, I (mostly) won’t have to do that, and I’m really looking forward to skipping it as often as possible. Since the vast majority of Java applications I encounter in practice are server-side applications, it might have been nice if you’d provided at least one example connecting them to EJB3. Otherwise I started to suspect you left them out on purpose because you didn’t want to remind everyone that your chosen app server doesn’t support the actual Java EE 5 spec.

    Once again, though, let me thank you for writing the book and for all of the other books you’ve written over the years. Frankly, I’m still kind of blown away that my little blog post attracted the attention of one of the Big Names in the field. I only hope I haven’t given any offense.

    I also intend to download and experiment with JBoss 5 as soon as it is released. You might want to consider releasing an updated JBoss workbook when that happens. I know none of the current examples would need to be updated, but you might add a few with a web tier at that point.

    Thanks again,


  7. Thanks for the valuable blog entry regarding JBoss 4 and it’s lack of complete support for Java EE 5. I encountered many of the same problems as you in using JBoss 4 and agree entirely that using beta software like JBoss 5 is not an option.

    I am seeing increased use and even production deployment of Glassfish instances to which our team is migrating to as well.

    Thanks Again!


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.