ServletException root cause

Java’s Throwable class defines the getCause() method for accessing the cause of the exception.  This method returns a Throwable object which itself could have a cause.  By traversing down this chain you can find the root cause of an exception.

However for some unknown reason in ServletException the getRootCause() method was added.  Therefore when trying to determine the root cause of an exception in a J2EE environment one has to check what type of exception you have.  I do this in the following code.

  /**
   * Logs all the nested exceptions for the specified exception.
   *
   * @param ex the exception
   */
  protected void logNestedExceptions(Throwable ex) {
    int count = 1;
    Throwable cause = getCause(ex);
    while (cause != null) {
      logger.error("Nested Exception " + count, cause);
      cause = getCause(cause);
      count++;
    }
  }

  /**
   * Gets the cause of the exception.
   *
   * @param ex the exception
   * @return the cause
   */
  protected Throwable getCause(Throwable ex) {
    Throwable cause;
    if (ex instanceof ServletException) {
      ServletException sex = (ServletException) ex;
      cause = sex.getRootCause();
    }
    else {
      cause = ex.getCause();
    }
    return cause;
  }

Finally you need to configure web.xml to use your SiteMap servlet.


    sitemap
    com.betweengo.servlet.SiteMap



    sitemap
    /sitemap.xml

Effective Java Collections

I thought this article, Effective Java Collections, was excellent.  Here is the summary of the article.

  1. Use the isEmpty() method of the collection.
  2. Avoid returning null to mean an empty collection.
  3. Create an empty collection using Collections.empty***() methods.
  4. Iterate through collections using the foreach form when possible.
  5. Use the proper collection, Collection, Map, Set, List.
  6. The left side is always an interface!  (So is the return type of methods.)
  7. If you’re explicitly casting, chances are something is wrong. Use generics.

Trim White Space from JSP

Untitled | FlickrSometimes the resultant HTML from JSP files has too much white space.  This is because a lot of JSP logic will result in only a few lines of actual HTML code and the rest is white space.

One efficient way to get rid of white space is to add this configuration to your web.xml on Tomcat/JBoss as described in this article, Trim Spaces in your JSP’s HTML.

/jboss/jboss-eap-4.2/jboss-as/server/atg/deploy/jboss-web.deployer/conf/web.xml
OR
/jboss/jboss-eap-5.1/jboss-as/server/atg/deployers/jbossweb.deployer/web.xml


    jsp
    ...

    
        trimSpaces
        true
    

    ...


However this sometimes has undesired side-effects. For example this DSP:


causes this undesired result:

Frank Kim


The work around is to do this.


Update 06-09-2010: The above problem might have been happening because we were running with a version of ATG that is for Servlet 2.3. When we run with a version of JBoss that runs with Servlet 2.4, e.g.  ATG 9.1 with JBoss EAP 4.2, we no longer see this problem.

There is another tip on removing white space in this JSP FAQ: Why I am getting extra whitespace in the output of my JSP?  In our code we had one file which included a bunch of tag libraries.  It originally looked like this.

<%/** Taglibs.jsp: include to pull in all taglibs */%>

<%@ taglib uri="/dspELTaglib" prefix="dspel" %>
<%@ taglib uri="/jstlCoreTaglib" prefix="c" %>
<%@ taglib uri="/struts-bean" prefix="bean" %>
<%@ taglib uri="/struts-tiles" prefix="tiles" %


When we changed it to this we saved about 5% in terms of page size in bytes.

<%@ taglib uri="/dspELTaglib" prefix="dspel"
%><%@ taglib uri="/jstlCoreTaglib" prefix="c"
%><%@ taglib uri="/struts-bean" prefix="bean"
%><%@ taglib uri="/struts-tiles" prefix="tiles" %>


You can use this tip with a DSP page and maintain indentation.

Name: 

Cygwin Bash Scripts and Java

Running Java scripts in Cygwin bash scripts becomes a little tricky because you want to treat most paths in Cygwin as normal UNIX paths but Java expects DOS paths.  Therefore to get around this you can use the mixed option for cygpath.

For example:

if [ -e /usr/bin/cygpath ] || [ -e /bin/cygpath ]
then
  export FOO=`cygpath --mixed "e:\work\betweengo/target/foo"`
else
  export FOO="e:\work\betweengo/target/foo"
fi

The result on Cygwin is that FOO will be set to “e:/work/betweengo/target/foo” which will work both in DOS and UNIX.

Repository creating tables automatically

Recently we noticed while running some ATG unit tests that tables were being created by the ATG repository if they had not already been created by our SQL scripts.  This was a functionality that I was unaware of but apparently it is not unique, Hibernate does this too.  I could not find any documentation about this nor could I determine how to turn it off.

The ATG repository creates these tables using the repository definition and the defaults for column width and data type.  It does not seem to warn that it is creating these tables.

Interface Members

Because interfaces are static, public and don’t change, by definition any members you declare in them are static, public and final. Therefore you don’t need to qualify such members.

For example:

public interface A {
  String FOO = "foo";
}

is the same as:

public interface A {
  public final static String FOO = "foo";
}

You can read some more about this in the forum Interface member variable by default static?

Covariant Return Types in Java

dolphin's dance on Flickr

(Photo: dolphin’s dance by kalandrakas

This article, Covariant Return Types, from java.sun.com and reprinted in a nicer format by Java Tips, explains well what covariant return types are.

You cannot have two methods in the same class with signatures that only differ by return type. Until the J2SE 5.0 release, it was also true that a class could not override the return type of the methods it inherits from a superclass. In this tip you will learn about a new feature in J2SE 5.0 that allows covariant return types. What this means is that a method in a subclass may return an object whose type is a subclass of the type returned by the method with the same signature in the superclass. This feature removes the need for excessive type checking and casting.

An example is:

public class Shape {
  private Shape shape;
  public Shape getShape() { return shape; }
}

public class Circle extends Shape {
  private Circle circle;
  @Override
  public Circle getShape() { return circle; }
}

Not the best example but a succinct one. 🙂