JWUG BOF36 JBoss SEAM & JSF

Last Wednesday (16th April) saw the 36th London Java Web User Group get together. The subject for discussion was JBoss SEAM described admirably by Sebastien Degardin, his English being much better than my French!

The upshot of the evening was that SEAM a framework for developing web applications can quickly produce usable web applications - the API being open source, the dev environment might cost if you go to JBoss and get their dev IDE.

The best thing Sebastien demonstrated was that SEAM could automatically reverse engineer a CRUD web application from an existing database schema pointing the IDE at a database resource the application then generates all the necessary pages and persistence architecture based on Hibernate. Although SEAM has it's own it was written by the same guy who did Hibernate. The web interface is built using JSF which, in this version, now hides all JSP and simply uses tags in a similar way to wicket. It effectively means that you're using web components instead of coding HTML.

One nice feature of SEAM is the way it manages session data, we all know about the application context and the session context in web applications. SEAM however, introduces the concept of a "Conversation", such that if you need to store session data across multiple interactive sessions that can be done. Think of an application such as an online auction, you might want to share bid information across a number of sessions spanning a much longer period that a single user session. The "Conversation" concept allows this. I thought that's nice if I have some processing that the user starts but that is completed by an administrator such as signing up a customer and provisioning a service of some kind.

Finally an interesting comment was that, apparently, you can run EJB3.0 in Tomcat. How, when it's not an EJB container? JBoss have an embedded EJB3.0 container. I'm going to look into this further, it's a good one to trick people with but with so many EJB compliant Application Servers I'm not sure why you'd want to. Maybe a phased scaling up of an existing application? There's another one called easybeans which works with java 1.5+ and tomcat 5.5+.

Anyway many thanks to Sebastien for his presentation and to Peter and Evans for organising the event, and "Hi" to Dave Snowdon at ecube who I enjoyed chatting to until I had to dash off for a train.

Unit Testing Getters and Setters

Interesting one this. I'm sitting here wondering whether to test all my getter and setter methods. Since I let Eclipse do all the work should I test them all? Two theories here. One, Test everything that can go wrong. Two, don't explicitly test them because you'll test them implicitly in the tests for more complex application testing. Further more if I don't use the get/setter in my test code do I need the get/setter in the first place? That's just a bonus.

It seems to me that Scott Leberknight has the right idea. I'd like to see his solution incorporated in JUnit. Then I surfed around and saw that there was some question as to whether get/setters were in fact OO or not. Interesting comments, brighter people than me are suggesting not always. I can see the point. Read the "Why Getter and Setter Methods are Evil" on JavaWorld by Allen Holub and have a think about it.

Now I'm thinking I should revisit the whole thing.