Wednesday, August 18, 2010

Simple Java EE 6 project fails in different ways on Glassfish and JBoss AS 6

(Update: this issue was caused by a Glassfish bug. See Bug 13040 in the Glassfish tracker.)

I'm coming to really like Java EE 6 ... or at least, I would if anything worked properly. There seem to be an awful lot of quirks and bugs in even fairly basic functionality, though.

Take this simple project, where a @Stateless EJB that inherits from an abstract base is injected into a regular JSF2 backing bean. It's done two different ways - once using the new CDI/Weld injection facilities, and once with old-style JSF2 injection and EJB container management.

One works on glassfish, the other on JBoss. Neither works on both.

The glassfish failure is caused by a problem resolving methods inherited from superclasses in the Weld-generated local no-interface EJB proxies. The JBoss issue appears to be caused by issues with its local no-interface EJB support, too, though I'm not sure exactly what yet.

The point: Local no-interface EJBs were supposed to save time and pain for developers, yet all I'm finding so far is bugs, or at least quirks and inconsistent behaviour.

Sources to the sample can be found here and a deployable war is here.

Posted on StackOverflow and The Glassfish forums

.

2 comments:

  1. Update on June 2011: Both bugs are now fixed in Weld, so both methods should work on JBoss AS 7 and Glassfish 3.1.1.

    It took more than a year, though, and there are still plenty of other fun bugs I'm running into on a daily basis. My productivity with EE remains low because I'm wasting so much time on container bugs and weird spec holes.

    ReplyDelete
  2. Even after a year, now August 2012, I still run into container bugs and weird spec holes. The no-interface EJB and Stateful session beans with CDI scopes and injections are messy stuff with different containers behaving differently.

    ReplyDelete

Captchas suck. Bots suck more. Sorry.