Java EE reminds me of the government...

Don't get me wrong -- I like Java EE 5... I'm especially a big fan of being able to make a living working with it, but sometimes you run into some weird things that just make you scratch your head...

The government analogy comes from the fact that the @PostConstruct annotation cannot be used in conjunction with a transactional or a security context... It's almost like a bunch of possibly well meaning but badly misguided (and possibly well bribed) politicians just couldn't agree on the 'right' way to combine these features, so they did the worst thing that they could have done -- they simply failed to make a decision... (at least they didn't do what our esteemed New York State politicians have been doing lately)

I ran into this issue about a year ago while working with JSF Managed Beans... I wanted to use a @PostConstruct method to load data for a view page -- I needed to access a few repository beans to load the data properly, and I wanted the Managed Bean to act as a transactional boundary... seemed to be an eloquent way to provide for bookmarkable pages in JSF, which is notoriously difficult... Anyway, I was unable to do this directly, as the semantics for @PostConstruct don't allow it...

Turns out this is problematic with Spring's usage of @PostConstruct as well... while experimenting with Spring 2.5 a few nights ago, I setup a quick experiment with some JPA Entities and the new annotation-based dependency injection mechanisms (big fan so far, by the way)... I hacked together a test bean that had a method marked with @PostConstruct and @Transactional, which created a single instance of an Entity and persisted it to the database to test that everything was working... but it didn't work... no errors, just no data in the database...

I've seen this symptom before related to mis-configured transactions, so I looked there first -- I copied the JPA code into another method, and marked it with "@Transactional (propagation=Propagation.MANDATORY)", and it gave me an error because there was no existing transactional context... huh? A little research led me to several articles indicating that these two items can't work together... Oddly enough, if I put the JPA code into another class, everything worked fine...

This is one of those odd restrictions that makes working with Java EE just a little more annoying than it should be... it's not a huge deal but it does force you to change your programming style in some cases, and it forces you to think about things you shouldn't have to think about... Spring's implementation in this regard is somewhat surprising -- after all, Spring isn't a Java EE container... it seems that they could have made their implementation act a little closer to what you would expect, or, if they're not willing to distort how the standard annotations work, perhaps they aught to create their own version...

I'm just glad the Java EE standards committee hasn't figured out a way to tax us yet...

M

EJB Lite? Now I'm really confused...

Something smells a bit about the Java EE 6 'profiles' discussions from a few weeks back, triggered by Roberto Chinnici's blog entry here... I'm not talking about the contents of the profiles themselves -- although I do have some issues here, that's for later... what I'm talking about is this concept of EJB 'Lite'... huh?

Why is this needed? Isn't WebBeans supposed to provide a light-weight component model, without a lot of the advanced services that EJB provides such as remoting, messaging, etc, that simple websites don't require? It sounds to me that there is some major disjoint between the various JSR's that will be making up the Java EE 6 spec...

It's important to note that Roberto is very clear that the contents of this 'Lite' version is completely undefined, but let's look at the example he gives of "annotation-based programming model introduced in EJB 3.0, restricted to session beans with local interfaces (only)".

As far as I can see, the only feature that this will support that isn't explicitly defined by WebBeans is Container Managed Transactions... the WebBeans spec does define an interceptor model, and it would be relatively straight forward to provide a transactional interceptor to mimic this functionality -- I'm pretty confident that we'll see this functionality created by multiple vendors and open source projects in very little time if it's not explicitly defined in the spec...

So why the added complexity and confusion of an EJB Lite, when you have a brand-spanking new spec that is already poised to fill the need? It looks to me like a worst-case scenario of what can happen when a system is designed be committee, without any kind of strong leadership to identify this kind of problem... Can someone please introduce the Java EE JSR's left hand to its' right hand?

M

It figures...

Wouldn't you know it, one day after I write an entry about how development on JBoss' app server seems to be crawling, they release a new beta version of the 5.0 series! I figured that would happen, although my comments still hold true -- JBoss AS 5 is still in beta, and as far as I know, it has not been Java EE 5 certified (I could be wrong on that -- please correct me if I am)...

They've indicated that this is the last beta version before it reaches General Availability -- let's hope it gets to that point soon!

M

Um... Has anyone seen JBoss?

Ok, can anyone explain why JBoss seams to have dropped off the map? The 5.0 version of the JBoss Application Server has been in beta for over a year! What's going on? I see a lot of the JBoss folks active in blogs and articles, but JBoss appears to be one of the only major server vendor who has not released Java EE 5 compliant server -- for God's sake, even WebSphere has a Java EE 5 server (although to be fair, it appears to only be their community edition -- still, WebSphere has a history of being 2-3 years behind the most recent spec, and even they seem to have made more progress)...

A lot of development seems to be going into Seam and Hibernate, which are both great products, but the Application Server has to be considered JBoss' bread and butter product... what's going on?

I will say that I've been using the JEE 5 features that are in the 4.2 version for some time, and they are solid -- why hasn't JBoss been able to take that next step with their server and achieve compliance? The lack of progress here has definitely made me think twice before recommending the server...

M