Some Hands on with JEE6/JSF2
Some Hands on with JEE6/JSF2
Join the DZone community and get the full member experience.Join For Free
Learn how to build stream processing applications in Java-includes reference application. Brought to you in partnership with Hazelcast.
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.
Opinions expressed by DZone contributors are their own.