Scott Leberknight's Weblog

Ran across a nasty little detail using DynaActionForms in Struts today. When Struts populates an ActionForm from the request it uses the Jakarata Commons BeanUtils to accomplish this feat. BeanUtils, in turn, uses ConvertUtils, which converts String values to a specified class. (Actually BeanUtils uses BeanUtilsBean to do the actual population and ConvertUtils uses ConvertUtilsBean but that is another nasty little detail that is not important to this discussion.)

Anyway, in the DynaActionForm there was one property, which was a simple domain object (e.g. User) with several properties one of which was the id defined as a Long. This way you can define your form properties using dot notation, e.g. the HTML form property "user.id" translates to user.setId(Long id). For entering a new User the HTML form has a "user.id" property which contains no value, e.g. value="". When the form is submitted an interesting thing happens - the empty string gets converted by ConverUtils during the Struts form bean population process to a Long with the value zero, e.g. the equivalent code would be new Long(0). I dug through mounds of Struts and Commons code to find out why. It turns out the default converter for the Long type is in fact zero! In fact the default value for all numbers is zero. I am not sure if this is a bad thing or not. Should an empty string be converted by default to zero? That seems odd to me. I expected it to end up as null in the User object embedded in the DynaActionForm, but it instead ended up as zero. That caused me about 10 minutes of scratching my head at work and now has chewed up an hour looking at code and writing this entry on it. All in all a somewhat annoying "feature", but at least I'll never forget it again!

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.

Several years ago I heard about this new cool technology that was supposed to replace XML DTDs and allow you to define types in your XML documents which would get automatically validated according to the rules you specify. You could restrict values in your XML documents to integer, float, dates, times, etc. It was called XML Schema. I started doing some research and learning and found that it did seem to allow you to define your own types and use any of the 46 (yes, I did say forty-six) "primitive" data types in any imaginable combination. Then I learned about serialization space, parse space, lexical and values spaces. Then came whitespace processing, xs:string and xs:normalizedString, simple types and complex types. Then namespaces and derivation by restriction, qualified names, target namespaces, and a zillion more.

By this time I had enough, wrote a DTD for the piece of the project I was working on, and was done with it. XML Schema is horribly complicated and tries to provide way too much in my opinion. Think for a second. If schema is so wonderful, then why do most open source projects like Struts, Hibernate, and Spring all use DTDs? In addition, since the early days of the Servlet API web application deployment descriptors have used DTDs. Unfortunately the new J2EE API versions will use schema to define deployment descriptors. DTDs are simple and work very well for configuration files. You can write a DTD very quickly. Some people consider the fact that a DTD is not actually written in XML to be a negative. Perhaps, but it is very simple to learn to write a DTD and you can probably do it in less than a hour! The same can definitely not be said of XML Schema.

The current project I'm working is using off-the-shelf XML Schemas so this time I have to use them to validate and create instance XML documents. I have managed to avoid really learning and/or using XML Schema since about 2001 but this time there appears to be no escape.

Well, after a very long time I finally have a blog. After a year of talking about it, Singley and I finally sat down, downloaded Roller, and installed it. It went very smoothly and was up and running last week. Since I tend to procrastinate on almost everything, I am just getting to posting this a little less than a week later. Anyway, since Singley has been bugging me to post the first useless entry I am finally getting around to it.