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