On JSF, Struts, & Spring Part Deux

After a Saturday of messing around with Spring, JSF, & Hibernate I have a nice little application that does nothing more than retrieve an object from my local PostgreSQL database and display the value in a web page. While the end result isn't very exciting there is a whole symphony of integration going on under the covers.

Hibernate and Spring

I first created a couple business domain classes that use the latest and greatest Hibernate/EJB3 Java 5 annotations to describe how they map to database entities. This is currently supported in Hibernate 3.1 beta 3 so I didn't really expect to be able to use this stuff once I got to integrating it with Spring. I assumed I'd have to either write Hibernate mappings in XML or maybe integrate XDoclet to generate the mappings. Well to my surprise Spring has org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean!! So Spring was good to go! All I had to do was declare the sessionFactory and the transactionManager that I wanted in applicationContext.xml. I still haven't figured out a way to get it to autodiscover the annotated business model so I had to manually list the two classes but that wasn't too big of a problem.

I then moved on to creating a subclass of Spring's HibernateDaoSupport class and configuring it in applicationContext.xml where I learned about the declarative transaction management features of Spring. In this XML file I was able to wire together the DAO, the Hibernate sessionFactory, the transactionManager and indicate which DAO methods require a transaction. This simplified the code in the DAO by injecting the necessary Hibernate Session and Transactions at runtime. But this comes at the cost of using a HibernateDaoSupport method called getHibernateTemplate() whose returned object basically delegates to the injected Hibernate session and turns Hibernate exceptions into unchecked exceptions. This also has the unfortunate side effect of burying the native Hibernate API. I don't really care for that idea too much but it's a tradeoff for not having to manage session and transaction resources manually.

So I then created a little JUnit test, used the FileSystemXmlApplicationContext to start up Spring and then used the context to get the configured DAO from Spring and called a method. Everything worked as expected.

Spring and JSF

Next it came time to integrate JSF. This became a little more time consuming. First of all I needed to figure out how to initialize all the Spring stuff within a web application which in turn initializes all the Hibernate stuff. It was actually fairly simple. I only had to configure a listener in the web.xml file for org.springframework.web.context.ContextLoaderListener. Also by using context-param in web.xml I was able to tell this ContextLoaderListener instance where to find my spring applicationContext.xml files.

Secondly, JSF has its own Dependency Injection framework for configuring backing beans that have request, session or application scope and it was unclear to me how to integrate the two dependency injection frameworks i.e., If my DAO and Facade/Service classes are configured with Spring how would I go about injecting these instances into a JSF backing bean? Well as it turns out I can't. Not yet anyway. There is a little project appropriately enough named "jsf-spring" that aims to transparently aggregate these two frameworks. It's in beta. But Spring has a supporting class called FacesContextUtils which allows me to fetch an instance of WebApplicationContext (with the current FacesContext as a parameter). I can then use that Spring context object to fetch the DAO (or more typically a facade class) to do the work I need. Given all this dependency injection stuff this manual fetching of context objects and service objects seems like a very odd hack and is more like calling a singleton getInstance method. But it works and I was able to tie the business layer to the presentation layer.

Summary

So there you go, a display-only Spring/Hibernate/JSF application. It was a good lesson in making all the pieces work together. In the end I look at all this plumbing and I'm a bit surprised how simple and difficult it was to get everything going. The Spring stuff is well documented on the web and was easy to get going with Hibernate. But answers to my questions about adding JSF to the mix were a little harder to come by. I suspect the future holds a stronger integration for Spring and JSF (perhaps you can just use Spring as a replacement for the JSF injection framework) and I can see Java 5 annotations becoming more prevalent in Spring so that you don't have to write all that XML. Annotations work great for Hibernate so I don't see why they wouldn't work well for Spring too.

On JSF, Struts, & Spring

I started a new contract yesterday and got a bit of a taste of what to expect in the coming months. We're building web-based Java applications and the typical J2EE MVC, Facade, DAO, & (evil) DTO patterns are in full effect.

I'm fortunate enough to get to continue to use Hibernate for ORM which is very cool. I still think Hibernate and object relational mapping in general is a very good thing. The biggest "problem" I see is that it looks like people are opting to use the "TopLink" way of doing things by using Criteria objects instead of HQL. What are they thinking? Why anyone would choose to use a non expressive bunch of Java code to write a query is beyond me. HQL is way better and one of the reason I like Hibernate so much better than TopLink. I e-mailed my supervisor about this one and we'll see what kind of response I get.

On the web framework front, we're using JSF (MyFaces specifically) instead of the defacto standard Struts. While fundamentally I don't have anything against Java Server Faces (it does have some nice features) I have to wonder why they made the decision to use it. David Geary (co-author of the book "Core Java Server Faces") once gave a talk at our local Java User Group meeting once and said something to the effect that "JSF was a standardized Struts that IDE vendors could rally around to create JSP visual editing tools". Part of that goal was to compete with ASP.NET. Coding up JSP pages is a bit mundane and who wouldn't rather have a tool write that junk for you? Well apparently the people where I'm working made that decision! It's still all hand-coded. So now we're using a framework nobody understands and I suspect productivity is lower. Where's the logic in that?

MyFaces seems very similar to Struts so conceptually it's easy to grasp but it's the details and the peculiarities of how things work that slow you down. It also seems to be at a higher level abstraction from the lower level request/response and the HTML it generates (the theory is that you can generate something other than HTML). But I think I prefer Tapestry's idea of staying close to HTML and only injecting the dynamic content. Tapestry allows you to use any HTML editing tool and HTML is well understood. JSF on the other hand is this parallel universe of tags that look a bit like HTML but can only be edited in a text editor or a JSF visual editing tool and at the moment there doesn't seem to be any tools that play nice with the MyFaces implementation. Secondly, staying close to HTML allows you to take advantage of advances in HTML like XHTML and AJAX. JSF, like ASP.NET, gives you a component model that will likely adapt to support advances in the underlying technology but there will always be a time lag. Perhaps the other minor benefits will outweigh the losses. We'll see... Right now it looks like change for the sake of change.

They also bought into the whole Spring IoC (a.k.a., Dependency Injection) idea. At first glance this seems like a good idea. You design to interfaces in an attempt to hide implementation details. Theoretically it should enable unit testing and allow us to switch between POJOs, Web Services and EJBs with greater ease. Of course it comes at a cost of greater complexity for questionable gain. For example if you create a DAO interface and then only ever create one implementation of that interface what have you gained? And then you have all the XML gunk to wire everything together. Theoretically, a meta data approach to wiring stuff together is better but not having experienced it before I'm a bit skeptical. The fortunate part about Spring is that they seem to understand that they need to play nice in a bigger community and support all the major Java frameworks out there so integration looks to be pretty straightforward.

My feelings are a bit mixed... Sometimes I believe that the dynamic, competitive, multi-vendor Java community is more vibrant than the MS .NET community and that the variety of tools is our attempt to find the most effective method for developing software. But sometimes I believe that we're all just chasing the next trend and running around in circles and I envy the single voice (Borg like as it may be) leading MS development. Anyway, I have some things to learn and I'll withold my final judgement until I've been using JSF and Spring for awhile. Maybe there are some pleasant surprises to come.

Open Surfin Safari

People seem to give Apple a lot of flak for being a proprietary software company and while it'd be ridiculous to argue the fact that Apple is to a large degree closed source, what most don't realize is that they are a very active user of and contributor to open source projects. The kernel of the OS is based on FreeBSD and the source code is available for download at Apple's OpenDarwin website. It's been like that since the first release of Mac OS X.

Secondly Apple's Webkit, their HTML engine used in the Safari web browser, is based on KHTML from KDE, the desktop environment for Linux. The source code for Webkit is also available for downloading from the OpenDarwin website. And as a matter of fact I followed the instructions in this article to get the source code from the CVS repository, compile it and run the latest code. Very cool. It's even the first (and currently the only) browser to pass the ACID2 test which tests a browser's support of web standards (try that with IE).

So yes Apple is proprietary in many respects but they understand when it makes sense to be part of the open source community.

Lube, Rods, Scoring, oh my!

I was told by a couple of people who read my blog that it's too "boring" so I figured I'd spice it up a bit and talk about lubing your rod. All your partners will oooOOOOooo and aaaaAAAAAaaaa...

Get your mind out of the gutter...

I'm talking about foosball again! LOL. In addition to the new men on our foos table I had enough money left over from our "foos-aid" office collection to buy a can of 3-in-1 silicone spray lubricant from Canadian Tire for the foosball table rods. What a difference maintaining your uh "equipment" can do for you.