So I said I'd blog over here more often in my last post didn't I? Well a combination of real-world trials and tribulations have made that a little difficult but what the heck!

Since I've been 'away', it's been nice to keep up with the releases of the Seam project flying in thick and fast - lots of nice new features for my favorite development framework and lots of discussions had with people promoting Seam in my travels.

It appears that a lot of Java developers who I speak to are all at approaching the same point; they have been working with Java for so long and they wonder what's coming next. The majority seem to have grown comfortable with Java over the years, but are hearing a lot about the new young upstarts like Flex and Ruby on Rails and I've been involved in a lot of discussions over the past few months about the pro's and con's of each approach and I have been fighting Seam's corner (and for Java in general) in these discussions.

Seam is Java. It's a nice, warm place for Java developers. Especially Java developers who have had their hands burned by EJB2. Mention 'enterprise' to many Java developers and they are likely to produce a sharp intake of breath between their teeth and regail you with tales of 2am debugging sessions that involved 4 or more XML files and a similar number of class files, only to find that the return value of a method differs between the Java and the XML. And that was the last time they looked at it; they've been cranking out DAOs ever since.

You can imagine the looks I get when I describe annotation. I imagine that any attempts to describe the new Bean Validation JSR discussed elsewhere on this site may involve me being burned at the stake for witchcraft!

Plus you get all this Web2.0 'stuff', but you also get the ability to cluster, cache, use business processes, integrate with legacy applications, add security features, use asynchronous messages, create PDFs, provide full-text searches and a whole bunch of other 'cool' features without having to bend over backwards to achieve it. And a lot of these features are required by real businesses that you may not read about in Wired, but have real world needs that we can solve without going right to the bleeding edge.

Anyway, I thought I'd just point you over to my other blog for the on-going adventures with Google Maps, Richfaces and Seam. Check out:

Since I've blogged on here. Such is life. I've been playing with the Red Hat Development Studio but it's been hampering my efforts due to

a) it not being available for OS X
b) it not having Seam 2.0

As I noted on the past on my Thinking in Seam blog, I was trying to work with the Parallels virtualisation software and this was going quite well but the default install of Seam 1.2 in the Beta 1 version of RHDS that I was using (Beta 2 ships with 1.2.1) meant that it wasn't really ticking all the boxes for me.

So Max Andersen posted on my blog about the JBoss Tools project shipping an OS X installable, I was very excited. However, the promised hasn't been fulfilled yet as it seems to want to consume all the memory it can and then fall over in a heap! If I don't use all the best bits at once (JSF editor, faces config editor and JBoss Server management) and just use one at a time, then it's not too bad. Hopefully these things will improve with time (and feed back from people like myself), but I do suggest that if you're wanting RHDS for Seam 2.0, then you should give JBoss Tools a try.

I've been bloggingelsewhere about validation in Seam recently and been getting some good feedback regarding what has been found out by myself and others, so I thought I'd kick off my blogging here with a quick summary of what has been discovered.

Let's imagine for a moment we have a simple form with a simple backing bean.

OK, when we submit this form without filling in the name, we will see a large stack trace and are redirected to the debug page (assuming you've got that configured). This is caused by no validation from the front end being performed so the value of 'name' is not being checked before being passed on to be persisted. At this point Hibernate then checks against its validation rules that DO take into account our @NotNull annotation and complains bitterly about 'name' being null.

Why is this happening? Well, the simple answer is that if you want your annotations to be used for front-end validation, you must add a required attribute to the form element and set it to true (ie: required="true"). This acts as a 'hint' to Seam to run the validation from the backing bean at the front end.

Now, let's consider that we have a @Pattern to validate on a null-able field. To check this you would still need to have the required attribute set to true. Even though the field is not, technically, required. This would then allow you to validate against the @Pattern as you would expect.