Blogging Roller

I have two complaints with the XML-file approach to webapp configuration approach that <a href= "http://freeroller.net/page/jduska/20021206#how_to_handle_configuration_information">Jeff and <a href= "http://www.raibledesigns.com/page/rd/20021206#webapp_configuration">Matt have been discussing (and the one that Roller currently uses):

• It does not work well in a distributed situation. If my application is distributed across multiple servers, then app instances cannot easily share one XML file. In that case, I'd need to copy the XML file to every server. If I want to make configuration changes while the app is running then I'm are out of luck. A better approach would be to store this type of information in a database, not a file.
• There is no meta-data. I would rather not have to write a configuration UI for every webapp that I write. But, to write a generic configuration editor UI, I need to have meta-data about each configuration property. For strings and string-list properties, I'd want a list of possible values. For integer properties , I'd want a range. For a real configuration API, I need meta-data about properties and acceptible values.

Is there a configuration or preferences API that supports meta-data? I don't believe that the Java 1.4 preferences API does this. I wonder why not? Maybe Sun was just trying to replicate the Windows Registry.

There is a very complementary review on Slashdot today of the Manning Press Struts in Action book.

Castor OIL, the GUI tool for creating Castor JDO mappings from existing database tables, has been brought back to life by Peter Kasson. It was originally written by Lance Lavandowska and donated to the Castor project.[Bruce Synder on the castor-dev mailing list]

As you can see below, Castor OIL takes a different approach than JDOMapper.

• Reads database and creates Castor mapping properties.
• Writes mapping.xml from Castor mapping properties.
• Reads mapping.xml and creates Castor mapping properties.
• Writes java source for each element in mapping.

Using the terms I discussed in my Java persistence frameworks post, Castor OIL supports a bottom-up development approach. The JDOMapper comes close to supporting the top-down approach, but it falls short because it does not generate a database schema (DDL).

I like the XDoclet approach to generating Castor mappings, but this new GUI from Shelly Mujtaba looks pretty cool.

JDOMapper provides a user interface for creating Castor JDO mapping files. The application allows user to import Java classes and map them to an Relational schema . The tool performs series of validations to ensure that classes and fields are correctly mapped. Existing mapping files can also be imported into the tool. [JDOMapper]

Forrester Research has published an interesting summary and analysis of the current state of the app server market.

After working some more with Castor persistence framework, I realized that Castor does not support all four of the development processes I discussed in my persistence framework comparison. Castor only supports "meet in the middle" and I've changed the table to reflect this.

Castor's Source Generator is not really part of Castor JDO, instead it fits in with Castor XML. The Source Generator can take an XML schema document and generate Java classes that represent that schema. This is neat, but it really does not have anything to do with O/R mapping and 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

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 <a href= "http://sourceforge.net/project/showfiles.php?group_id=47722">download Ag from SourceForge or just read the <a href= "http://sourceforge.net/project/shownotes.php?release_id=125110">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 <a href= "http://www.wrox.com/books/1861004958.htm">Professional JSP 2.0 book.

They are known as Value Objects, Data Objects, and now Sun calls them Transfer Objects. You only need these if you are doing EJB right? Is there any reason to have your DAO interfaces return Transfer Objects rather than full-fledged "Business Objects" or "Domain Objects" or whatever you call them. I think the answer is NO.

I'm sure this will upset any remaining EJB fans out there: even if you are doing EJB, you can hide the EJB/Transfer object mess behind a set of DAO interfaces.

I've gotten a number of responses on my DAO post. Thanks to all who responded. I think the general consensus is that DAO is a useful pattern, but it can limit your ability to make use of all of the cool features of your persistence framework. I'll try to summarize the responses for you below:

<a href= "http://freeroller.net/page/rickard/20021127">Rickard Oberg says DAO is a useful pattern, but he has not tried to implement it a O/R framework before. Somewhat predicably, he adds that Aspect Oriented Programming (AOP) can play a role in improving DAO implementations.

<a href= "http://roller.anthonyeden.com/page/jcarreira/20021126">Jason Carreirra says that the problem with DAO is that it requires fine grained objects, and that this makes it difficult to "streamline data access with bulk loading and caching."

Matt Raible says DAO works well, but does not like having to modify so many files just to add one field to an object. He'd like to automate the whole process with end-to-end code generation.

Russell Beattie reminds us of his <a href= "http://www.russellbeattie.com/notebook/index.jsp?date=20021012#135748">complexity of J2EE post, but unlike Matt he says that tools and automation are not the answer - we need a better pattern.

If you use the DAO pattern, it is possible to completely hide your persistence mechanism from your application.  It is possible, but is it a good idea?  Separation of concerns and modularity are always good things, right? <a href= "http://www.freeroller.net/page/acoliver/20021125#excessive_over_engineering_flexibility_and">Andy Oliver argues that this is not always the case. I think he has a good point. You have to think about what you are trying to achieve. Sometimes separating concerns buys you nothing and just makes your system more complex.

In the case of the DAO pattern, the point is to separate the client portions of an application from the data access mechanisms and to allow the "data access mechanisms to change independently of the code that uses the data." I'm trying to understand the flexibility/complexity trade-offs of DAO. Here are the pros and cons I've assembled thus far:

Benefits of DAO pattern

• The data access mechanism can change independently of the rest of the application.  This makes it possible for you to switch persistence frameworks without upsetting the rest of your application. That sounds great to me because I like to experiment with different persistence framework, but is it generally useful?
• Another benefit is that you get an elegant and modular architecture, but that is pretty subjective. One man's elegant architecture is another man's spagetti-code mud-ball.

Drawbacks of DAO pattern

• Adding an extra layer of interfaces to hide your persistence mechanism adds complexity and could even effect performance.
• Completely hiding your persistence layer behind DAO interfaces may not be practical. For example, you'll want to use Castor's long transaction feature but in order to do so your persistent Java classes will have to implement org.exolab.castor.jdo.TimeStampable. Damn, your persistence engine just poked it's ugly head out from behind the curtain of DAO.
• Different persistence frameworks may have totally different development paradigms and forcing them into the DAO pattern may force you to make sacrifices.  You will end up supporting leveraging only the least common denominator features of your persistence framework.

Personally, I like the DAO pattern and I like the idea that DAO can help you achieve a pluggable persistence layer. I like the idea that you can switch from EJB to Castor, and then from Castor to Hibernate if you wish to do so.

What do you think? Is the DAO pattern a good thing? Is pluggable persistence a desirable design goal?

I'm not going to be able to make it to the RTP WebShere Users Group meeting tomorrow (Tuesday Nov. 26), but it sounds like an interesting meeting, especially the Struts Builder bit.

WSAD is the successor to IBM's VisualAge for Java. It was first released at the version 4 level about a year ago, and now, with version 5, it moves to an Eclipse 2.0 base, and adds full J2EE 1.3 support, as well as numerous enhancements. Roger's talk will introduce WSAD 5.0, with an emphasis on the Web Development side. He will also demonstrate some of the new items, including Struts Builder and Cheat Sheets.[From the RTP-WUG meeting annoucement]

<a href= "http://freeroller.net/page/jduska/20021125#managing_files_within_a_web">Jeff Duska is forgetting a couple of things that many Servlet/JSP developers (myself included) often forget. He is forgetting the distributed nature of Servlet apps and he is forgetting the WAR.

Someday, when your app becomes incredibly popular, you might find that you need to distribute the load across multiple worker processes on multiple computers. All the major app servers support this, does your app? In a distributed configuration, if your app writes a file to the file-system on one computer, you won't be able to get to that file on another computer. If you want all instances of your app to share a file, then this is a problem. If you are just writing a simple little temporary file, which sounds like Jeff's case, then this is generally not a problem.

Even if you are only writing a temporary file, you still don't want to write it inside your Servlet context. When your app is packaged in a WAR file, may not be able to open files inside the Servlet context. If you are just writing a temporary file, it might be better to use one of the static <a href= "http://java.sun.com/j2se/1.4/docs/api/java/io/File.html">java.io.File.createTempFile() methods to get a file.

Triangle-based Webperformance, Inc. has published a <a href= "http://webperformanceinc.com/library/ServletReport/index.html">Servlet Container Performance Report that compares Tomcat, Orion, Jetty, Resin, SunOne, and Websphere. The testing methodology and the results are interesting and really show off the Webperformance product. The conclusion is that there is no clear winner in the Servlet-only performance race. UPDATE: Webperformance left Weblogic out of the review, but Kasia did not.

The goal of this [BasicPortal] project is to leverage a combination of several of the Apache Foundation's Jakarta projects into a simple vertical sample application that contains the functionality common to 80% of web projects -- we let developers customize the last 20%.

On the Struts mailing list, somebody asked for Struts-based CMS and Basic Portal was the answer. BasicPortal aims to be a best practices sample app, so I'm going to take a close look at the persistence layer.

One other observation, is that IDEA can be more innovative on the GUI side, that's because Swing is definitely more maleable than SWT. SWT may be fast, however Swing is more agile, and just possibly with all these 2Ghz machines and up, it just won't matter.[Carlos Perez on SWT vs. Swing and IDEA 3.0]

This is a good point. I'm a GUI guy at heart and I've worked extensively with Swing. I really like it and Carlos is right, it is very flexible and extensible. With faster and faster processors and more and more memory, the performance problems with Swing will become less and less apparent.

I really missed the point of that <a href= "http://www.internetwk.com/shared/printableArticle?doc_id=INW20021112S0009">InternetWeek article yesterday. Oracle is not ready to ditch JDeveloper. They are joining Eclipse.ORG because they want to push their new Java Specification Request (JSR-198) that standardizes the way that tools plug-in to an IDE.

Oracle sees the possibility of the Eclipse dominates scenario and wants to try to ensure that Eclipse does not become the universal tools platform. JSR-198 attempts to level the playing field for IDEs in the plugin tools space.

<a href= "http://brainopolis.dnsalias.com/roller/page/lance/20021112#fear_newsmonster_br">Like <a href= "http://www.russellbeattie.com/notebook/index.jsp?date=20021112#212618">the <a href= "http://www.dominicdasilva.com/index.do?date=20021112#092011">others, I tried NewsMonster and got nowhere. It does look cool, but I am enjoying Aggie too much now to put much effort into working through the pre-release NewsMonster quirks.

<a href= "http://www.internetwk.com/shared/printableArticle?doc_id=INW20021112S0009">InternetWeek reports that "Oracle also today reportedly joined Eclipse.org". An Eclipse zealot might take this to mean that Oracle is going to ditch <a href= "http://otn.oracle.com/products/jdev">JDeveloper and switch over to Eclipse, but it is more likely that Oracle just wants to get the inside scoop on Eclipse direction. I'm not an Eclipse zealot. Nooooo, not me.

Lots of Struts articles and books swirling around the blogs and sites and bookstores and etc. OnJava has two articles: 1) <a href= "http://www.onjava.com/pub/a/onjava/2002/10/30/jakarta.html">Lessons from the Trenches by Chuck Cavaness author of O'Reilly's <a href= "http://www.powells.com/cgi-bin/biblio?inkey=62-0596003285-0">Programming Jakarta Struts and 2) <a href= "http://www.onjava.com/pub/a/onjava/pub/a/2002/11/06/struts1.html">Learning the New Struts 1.1, Part One by Sue Speilman author of <a href= "http://www.switchbacksoftware.com/struts.htm">The Struts Framework. The Server Side recently posted <a href= "http://www2.theserverside.com/resources/articles/StrutsFastTrack/StrutsFastTrack.pdf">The Fast Track to Struts (PDF).  And finally, looking at Powells I see that <a href= "http://www.powells.com/cgi-bin/biblio?inkey=62-0471213020-0">Goodwill, <a href= "http://www.powells.com/cgi-bin/biblio?inkey=62-1930110502-0">Husted, and <a href= "http://www.powells.com/cgi-bin/biblio?inkey=62-0672324725-0">Turner all have Struts books coming out as well. I haven't read any of them yet so please read them for me and tell me which ones are best.