Scott Leberknight's Weblog

Last January several coworkers introduced me to the Spring Framework. They were using it to configure business objects for an application they were building using Spring's BeanFactory. At first I was a little skeptical but as I learned more I found Spring to be really easy to work with, and as I used and tried it out more I became addicted. Last month I created a simple tool at work that was used to test a legacy application. I used the Spring BeanFactory to configure all the application objects - no ServiceLocators, no JNDI, no container!

Since then I have begun to learn a lot more about Spring by reading Spring Live (currently in Early Release Program-1) and articles at TheServerSide and Hibernate's web sites. Spring Live is written by Matt Raible in a tutorial style. What I like about it is that you can speed through the tutorial really quickly and get a good feel for Spring and how it can help simplify J2EE application development. If you want more depth simply dive into the Spring JavaDocs - they are extensive - or wait for the upcoming Professional Java Development with the Spring Framework, which is written by the Spring developers: Rod Johnson, Juergen Holler et. al.

Having written several J2EE applications using the more traditional architectures using the Core J2EE Patterns, it is easy to see how much simpler it is to do the same thing in Spring with a lot less code. Not only that, but Spring is very easily tested using simple JUnit tests - a good thing considering I now hate writing any code that doesn't have a corresponding unit test! This is obviously oversimplification and I don't think the Core Patterns are bad, it's just that I really don't want to write another EJB application! I am probably even going to scrap Struts in favor of Spring's MVC framework, which I think is more intuitive and more powerful.

Singley and I finally got Gallery installed tonight. We had failed in two previous attempts, the first time because we underestimated the amount of time it would take and the second time because we were having trouble getting NetPBM, an image manipulation toolkit, installed. It turned out the problem was that NetPBM was placing the .so library files in its own location, specifically in /usr/local/pbm/lib. Unfortunately this meant that the NetPBM executables were unable to find the .so libraries and therefore refused to work.

After mucking around a bit we had to change LD_LIBRARY_PATH for the Gallery installation to include /usr/local/pbm/lib. After that everything worked perfectly. Sometimes it is amazing anything actually works, what with all the ridiculous amounts of complexity and dependencies that are present in complex systems.

Later I came across this article by David Barr titled "Why LD_LIBRARY_PATH is bad". After reading it I tend to agree. The caveat is that I am a developer, not a systems adminstrator and would never claim to be any sort of an expert in these matters.

Anyway, the final result of our efforts is at our photo gallery.