Some Hands on with JEE6/JSF2
I have been doing JSF since 2004. I blogged for a long time on here about some of the shortcomings of JSF 1.x, but overall, have always sustained that a flawed framework is better than a tinkertoy one that is not really a framework at all (Struts). Seems like I have been waiting for JSF2 for ever. Finally, getting to put my hands on it, it feels pretty nice so far, though there are some things that are still the same.

The Weld getting started doc kind of sucks. They were showing a login screen, which I needed, so I figured I would follow along. Spent a bunch of time flipped over in a ditch getting database errors until I went to look at the Producer class from the stupid Widget class that‘s included in the JEE6 generated project and found that instead of annotating a public instance, they had a getter with a note about Weld closing the connection if you referenced the field (as is shown in their own getting started doc). Sure enough, as soon as I changed to that, things started working. Overall, I am still queasy about the degree of annotation-fatted addenda these JEE6 approaches entail, but I can see the logic of the approach. I have had my own way of doing Repository classes for some time. This looks pretty straightforward, though it does seem kind of weird to be calling things by names in an annotation (e.g. WidgetRepository) that are actually just the bare knuckle object that you would usually have behind such a component (the EntityManager).
The cynic would argue that DI spends a LOT of time trying to elegantly make things appear places magically, when in fact, the range of objects that require this type of delivery is probably extremely narrow, with the EntityManager being chief among them.
In doing the registration page, I had to have a password and confirm inputs and check that they matched, so I delved into JSR303 a bit. One of the big complaints about JSF 1.x was that validation was confined to a single component so broader validation required methods in the controller or a custom validator class. The annotations that have been added are useful, and there is one that allows you to even do things like scripting, but that kind of stuff does not get me excited: I would literally rather add a validation method to a controller than to put some ugly script code into the body of an annotation. It did occur to me though that something like DbC might have been nice here. Instead of wasting a bunch of cycles in Sillyland talking about closures in Java 7, there should have been a movement to really put basic contracts into Java with annotations. Would not be hard, then you could just define an invariant for conditions like these. (The new validation constraints look like they should be part of a generalized DbC mechanism already.)

The real star of the JEE6 adventure so far is Glassfish. I was kind of pissed when I first started out because i very quickly figured out that the Weld main page was getting a banner from a css file, so I found it and replaced it with my own banner image, but could not get the rig to see mine. It was very strange and I am not settled about the resolution, which was basically to change other elements on the page, then finally, it did change the banner. While doing so, I tested the amount of pillow fluffing the system required to recognize a css change, and it appears the answer is it doesn't automatically, but a mere publish (Command-Option-p) will suffice, but the best news is, that happens VERY quickly. Which brings me to the altar of another wish I've had forever. Whenever I have seen quick cycles like this, and gotten drunk on them, another part of my brain chimes in to remind me 'dude, the app has 3 or 4 forms in it; once it does something, it'll come back down to earth and you'll be wanting to go break things..' Have not read about this yet, but that is one of my great hopes for OSGi: that we don‘t have to put all interface components into one big pile of components or into one big war file for the one big project we are working on. (Maybe there is a maven archetype for a components project based on JSF2…?)
It‘s also a relief to just have a bunch of the JEE6 baked into the server. We had lots of fun in the past flopping back and forth with conflicting version issues, or marking certain parts as provided when going out to JBoss, and back to inside the war targeting Tomcat.
Someone needs to figure out why the JSF train was in the tunnel for 6 years, then the Java world should just make do with what there is. JSF2 is a good framework, and whatever remaining ills it has should be easy to dispatch.
From http://www.jroller.com/robwilliams/entry/some_hands_on_with_jee6
- Login or register to post comments
- 3999 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)




Comments
Reza Rahman replied on Mon, 2010/09/06 - 12:02pm
Rob,
Thanks so much for your continued Java EE 6 coverage - it is much needed, especially from someone neutral. I agree with you that the needless gymnastics in the CDI examples are getting a little out of hand and we should keep things in XML deployment descriptors where they realy make the most sense instead of going too whole-hog on annotations. I try to do this for my own Java EE 6 examples, but it is not always easy since annotations are the "nifty new tool" that the inner geek sometimes get's too attached to :-).
I hope that you will be similarly impressed with Resin and JBoss once they are out of the gates in the next few months. BTW, modularity is pretty high on the overall agenda for Java EE 7...
Cheers,
Reza
Bram Harrumpf replied on Mon, 2010/09/06 - 1:59pm
in response to: rrahman
Jose Maria Arranz replied on Tue, 2010/09/07 - 2:28am
in response to: BrammarB
Or too much instrumentation for no very much gain.
Henk De Boer replied on Tue, 2010/09/07 - 5:48am
in response to: rrahman
Speaking of which, is there already some info page about this? There are some scattered tidbits of information around the web, but nothing really cohesive.
Andy Gibson replied on Tue, 2010/09/07 - 10:42am
With CDI/JSF I've rarely (if ever) used more than 3 annotations (@produces, @named, @scope). I could see having one additional qualifier on there which would usually replace the @named, but not always.
Also, I agree, Glassfish is really quite excellent for hot redeployments.
Andy
Reza Rahman replied on Tue, 2010/09/07 - 2:08pm
in response to: henk
Henk,
The best source of information right now is to go to the related Java EE sessions at JavaOne. In particular, there is a panel on Java EE 6 where we will discuss Java EE 7. Things will likely begin to spin up some time after JavaOne. As soon as they do, I'll probably start writing about it on one of the Java news sites (and so will other folks I a sure). Stay tuned and do have feedback and ideas ready :-).
Cheers,
Reza