Raible Designs

RE: ArrayList vs. Vector - which is better for webapps?

What the hell was I thinking?! I must've been tired this morning when I wrote the last post. I meant to say Serializable not Synchronized!! Yikes - what a blunder! Does this change your feelings? What if I have a UserForm (extends ActionForm) that has an ArrayList of children? I usually put a user's Form in the session, so I can access their information at any time.

ArrayList vs. Vector - which is better for webapps?

I've always thought that it's best to use Vectors in Beans or ActionForms because they are synchronized. However, everytime I write one, I get the feeling that I might as well just use an ArrayList. What do you think? The different between the two is that an ArrayList is unsynchronized (seems strange to me since the it does implement Synchronized - the JavaDocs don't lie do they?). It is easy enough to create a synchronized ArrayList using the following code:

Collections.synchronizedList(new ArrayList());

I like ArrayList better, and I'd like to use it - should I just synchronize it on creation, or use Vectors?

Tomcat and Apache References

This site seems to get a lot of hits for the Apache 2 + Tomcat 4 HowTo I updated. Therefore, you might want to check out Bruno Vernay's list of resources on this topic.

Middlegen now supports Hibernate

I saw this on the Middlegen mailing list this afternoon:

I have created a Hibernate plugin for Middlegen, modeled loosely upon the JDO plugin. Many features of Hibernate are not supported, but this at least generates classes with basic properties and associations (one-to-one, one-to-many, many-to-one, many-to-many). Composite keys are NOT supported, partly because they are not currently supported by the Hibernate XDoclet module.

As described by Max Anderson, here:

http://hibernate.bluemars.net/52.html#16

this approach is somewhat inconvenient and indirect from the point of view of the full Hibernate toolset. It would make much more sense from our point of view to generate a .hbm.xml mapping document with middlegen and then delegate to our CodeGenerator tool to generate the Java code. (CodeGenerator supports a larger subset of Hibernate functionality than XDoclet.) However this is not the kind of approach taken by middlegen elsewhere.

Anyway, this plugin is a good start and should already be useful for some people.

(The plugin was developed against the latest middlegen CVS and has NOT yet been rigorously tested.)

Gavin

What are you up to on the first day of this new year? I'm reading blogs and we just ordered a pizza. I hope to relax the rest of the day, maybe watch a movie, and order/post some pictures of Abbie.

[ANNOUNCEMENT] Struts 1.1 Beta 3 Released

The Struts team is proud to announce the release of Struts 1.1 Beta 3. This release includes significant new functionality, while retaining full backwards compatibility with earlier versions of Struts. It also incorporates fixes for a number of bugs which were reported against earlier versions.

The binary distribution is available at:

  http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b3/

and the source distribution is available at:

  http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b3/src/

In addition, the library distibution, which contains updated binaries without the sample applications, is available at:

  http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b3/lib/

Details of the changes in this release are available in the Release Notes, which can be found here:

  http://jakarta.apache.org/struts/userGuide/release-notes-1.1-b3.html

Sweet! Now I can stop downloading the nightly build for a while! Thanks Struts Developers - what a great New Years Eve present!

[ANNOUNCE] Hibernate 1.2.1 Released!

Hibernate 1.2.1 features support for Blob and Clob properties, a new FlushMode API, toolset improvements and fixes for a number of bugs found in version 1.2.

Download now!

commons-lang just made it easier

I got some advice from Max Anderson (via hibernate-devel mailing list) for implementing the following methods in a BaseObject class for my hibernate objects (or any objects FTM):

public boolean equals(Object o) {
  return EqualsBuilder.reflectionEquals(this, o);
}

public String toString() {
  return ToStringBuilder.reflectionToString(this);
}

public int hashCode(Object o) {
  return HashCodeBuilder.reflectionHashCode(this);
}

Boy, that sure makes things easier, huh? Especially when you compare the toString() method to my old one:

public String toString() {
    StringBuffer results = new StringBuffer();
    Class clazz = getClass();

    results.append(getClass().getName() + "\n");

    Field[] fields = clazz.getDeclaredFields();

    try {
        AccessibleObject.setAccessible(fields, true);

        for (int i = 0; i < fields.length; i++) {
            results.append("\t" + fields[i].getName() + "=" +
                           fields[i].get(this) + "\n");
        }
    } catch (Exception e) {
        // ignored!
    }

    return results.toString();
}

They both use reflection, but my old one might catch security excaptions. The Javadocs for HashCodeBuilder warn us about this problem:

Alternatively, there is a method that uses reflection to determine the fields to test. Because these fields are usually private, the method, reflectionHashCode, uses Field.setAccessible to change the visibility of the fields. This will fail under a security manager, unless the appropriate permissions are set. It is also slower than testing explicitly.

I'll be using these on Tomcat and I'll let you know if I run into any problems.

RE: Ant's jspc task - doesn't work on Tomcat 4.1.18

A week ago, I reported that Ant's <jspc> task doesn't work with Tomcat 4.1.18. I posted a message to the ant-user mailing list (which is very low traffic BTW, a nice feature in my book) describing my issue. Last night, I received a reply from Steve Loughran, co-author of Java Development with Ant (BTW Steve - great book, you've already got my respect!) The short story is that there is something wrong with the Ant task and someone needs to "sit down and spend an evening looking at [Tomcat's] jasper." The real hope is that a Tomcat Developer could take over maintaining the <jspc> task, and then these types of issues wouldn't occur.

[ANNOUNCE] XDoclet 1.2 Beta 2 Released

XDoclet 1.2 beta 2 is out! You can download it from SourceForge. Just to clarify, I've been calling the 1.2 beta 1 release beta 2 - guess I screwed up there. Unfortunately, the beta 2 contains neither of the bugs I want fixed. The first bug is something I need fixed to upgrade Roller to use the latest XDoclet, and the second is to generate ActionForms from POJOs. Now that I've been hacking some XDoclet code, I might be able to submit a patch for the first bug, I'll check it out if I get so inclined. Too much to do right now, and that's not a priority.

RE: PlugIns and Struts Nightly Build

It turns out that I didn't need to add the setCurrentPlugInConfigObject method to struts-menu's MenuPlugIn.java. I just needed to compile struts-menu with the latest struts.jar. This told me that the init(ActionServlet, ApplicationConfig) had been removed and I had to implement init(ActionServlet, ModuleConfig). The ApplicationConfig interface has been deprecated in recent weeks in favor of ModuleConfig, but you would think that this method would be deprecated as well, not removed! Oh well, I've fixed my local version of Struts Menu, but don't know how to handle making a Struts 1.1-compliant version, and a Struts 1.0.x-compliant version. Any ideas are appreciated. You can track this issue in Struts' Bugzilla.