It’s 39 degrees Centigrade outside. Too hot to be outside. Too hot to hack code. Or to play DMC. Or to think.
Perfect time to murder the zmei and rebuild it from scratch. Pray for its successful resurrection!
Update: The Zmei is now reincarnated as a Fedora 11 box.
J2EE development has always been painful. The tedious plumbing required at every step, the error-prone maintaining of countless XML files, the slow build times, and even slower deployment times, the JAR hell, the portability issues between the myriad of J2EE implementations… have often made me wonder if J2EE is worth the time I have invested in it.
Enterprise Java Beans suck. The 3.0 version has improved things a lot, but they still suck. JSF is complex, and ridden with its own problems. Some JSF implementations (like ICEFaces) are immature, and others (like Woodstock) are dead. Whatever productivity you gain by drawing pre-packaged components using a visual designer are absolutely lost in deployment, performance, compatibility and stability problems, not to mention the pain involved when you need to do something outside of the component author’s original intentions. You can’t win. JSF is a good idea in theory, but a huge disappointment in my experience.
It is amazing how easy and straightforward the development of the same web-based, AJAX-enabled, relational database-backed applications is with TurboGears or Ruby-on-Rails. How did the creators of these frameworks solve all the painful problems, without sacrificing flexibility at the least? Why is it so easy to use any third party JavaScript library to add client-side functionality to a TurboGears web application, but it’s virtually impossible to do the same with an ICEFaces one?
Why do we poor J2EE developers need to suffer the full J2EE stack, while rubyist and pythonistas enjoy their cool high-productivity frameworks?
Here’s my answer: we don’t!
Not anymore 
Checkout my new project which will hopefully provide a better alternative to good old J2EE.
Less pain, more productivity.
I can only hope than JSF version 3.0 will be more like SlimWeb than JSF 1.2! That is, if SlimWeb (or another framework in the same vein) hasn’t made JSF and hopefully EJBs completely irrelevant by the time the next versions of their specs are finalized and implemented 
Did you know the sons of Sparda had a sister?
The Little Red Riding Hood defeating the final boss