apache apachecon app apple asf atom atomprotocol atompub barcamprdu blogapps blogging businessblogging conferences family feeds foss general glassfish google humor ibm java javaone links linux mac microsoft movies music netbeans opensocial opensource photos politics rest roller rome rss socialnetworking socialsite socialsoftware sun triangle trianglebloggers vacation webdev webservices wiki


Saturday Nov 30, 2002

Dot-Net love child

Andy Oliver is on a frightening roll with his latest rants. Looks like it all started after Andy spent some time playing with Mono, a GPL licensed implementation of Microsoft's C# language and Common Language Runtime. Since then Andy has said that Dot-Net is awesome, Sun doesn't have any balls, and the best way for a Java programmer to help Java is to learn Dot-Net. He has also suggested that Microsoft and Apache hook up because of their joint love of money and BSD. This guy is a dyed-in-the-wool Linux and Java nut. What the hell happened?

Maybe it did not start with Mono. Perhaps something happened at ApacheCon. You know, Comdex was also in town and Microsoft certainly had a presence there. You remember that Andy got very sick with some kind of stomach bug? I think some Rosemary's Baby-like incident occured out there and now Andy is carrying the spawn of Redmond in his belly. He's got the beast in his belly.

Comments on Ag, DAO, and pluggable persistence?

Below is the email that I sent to the Hibernate and Castor mailing lists to ask for comments on Ag:

I've written a simple example application that shows how to create a simple web application (a newsfeed aggregator) with a pluggable persistence layer. I used the tried and true DAO pattern to hide the database access mechanism from the rest of the application. I implemented the DAO interface with both Hibernate and Castor.

I did this to learn:
  • What are the drawbacks of hiding powerful persistence engine behind a simple DAO interface. What do you loose? Will long transaction support work? What about lazy loading?
  • What are the differences between and strenghts/weaknesses of Castor and Hibernate?
  • What is the best way to implement DAO with each of the tools?

The code is very simple and (I hope) easy to follow, so if you have a chance please take a look. Look at the HibeAggregatorDAO and CastorAggregatorDAO implementations to see how I used Hiberate and Castor to implement the very same DAO. I'd love to get your opinions on the above topics.

Ag Download: http://sourceforge.net/project/shownotes.php?release_id=125110
Ag Readme: http://sourceforge.net/project/showfiles.php?group_id=47722

An example of pluggable persistence via the DAO pattern.

I decided that the only way to get a clue about pluggable persistence is to try and implement it, so that is what I did. I wrote a very simple JSP-based RSS aggregator with pluggable persistence via the DAO pattern. I implemented the persistence layer with both Hibernate and Castor and I used the RSS parser from Flock to parse RSS.

In the process I learned a lot about Hibernate and Castor. I am really impressed with Hibernate, but it is too late to go into any details. I do have time to say this: the Hibernate documentation is excellent, especially when you compare it to the incomplete hodge-podge of ad-hoc notes that comes with Castor. I did run into one snag that I have not yet worked around: Hibernate does not support CLOBs!

The aggregator is called, for lack of a better name, Ag. You can download Ag from SourceForge or just read the readme.txt.

Ag serves a number of purposes. I'll continue to experiment with Ag as I try to learn more about the advanced features of Hibernate and Castor. At some point, I'll probably merge Ag or some ideas from Ag into Roller. In the shorter term, I hope to use a portion of Ag as the example application for a chapter I'm writing on Data Access for WROX's new Professional JSP 2.0 book.

This work is licensed under a Creative Commons License.
Copyright 2002-2007, David M Johnson (dave.johnson at rollerweblogger.org)

This is a personal weblog, I do not speak for my employer.