Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 170 posts at DZone. You can read more from them at their website. View Full User Profile

Some Hands on with JEE6/JSF2

09.04.2010
| 5093 views |
  • submit to reddit

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

Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

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

Nim Lhûg replied on Mon, 2010/09/06 - 1:59pm in response to: Reza Rahman

Once you end up with 12 annotations on top of a single method/property, you pretty much run back to XML :-)

Jose Maria Arranz replied on Tue, 2010/09/07 - 2:28am in response to: Nim Lhûg

Or too much instrumentation for no very much gain.

 

Henk De Boer replied on Tue, 2010/09/07 - 5:48am in response to: Reza Rahman

BTW, modularity is pretty high on the overall agenda for Java EE 7...

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 De Boer

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.