Missing ognl?

This article was originally published on the Encodo Blogs. Browse on over to see more!

Every once in a while, when adding a new component to or changing an existing one on a Tapestry page, you’ll make a mistake. Most of the time, the exception handler page is pretty good; sometimes the exception can be quite confusing. For example, suppose we have a custom component with a single property:

package com.encodo.blogs.samples;

class CustomComponent extends BaseComponent {
  public abstract SomeObject getCustomParameter();
}

To use this component in a page, you just write the following:

<span jwcid="@CustomComponent" customParameter="obj"/>

This looks ok[1], but when loaded in a browser causes the following error:

With this kind of error message, you’re ready to start imagining all sorts of horrible things:

• Is something declared with the wrong type? No … there’s no type declaration for properties; Tapestry reads the type from the class field.
• Is there a data squeezer problem? Is this class not supported? Does it need to be Serializable?
• Is Tapestry trying to store persist the property to the session or cookie? Not likely, but who knows?

The missing magic in the above example is ognl:. Tapestry uses the Object-Graph Navigation Language to process references to Java code in its templates and page/component definitions. However, the default for HTML attributes is literal:, which performs no extra processing. Since ognl: is missing, obj is simply a string, which Tapestry cannot convert to SomeObject. To fix the problem, just add ognl: before the object reference, like this:

<span jwcid="@CustomComponent" customParameter="ognl:obj"/>

This being such a common error, it would be nice if Tapestry could do some common-sense handling of it to help emit a better message. One simple way is to specify what, exactly, it was trying to convert to the target object. Compare to the following error message:

Once the developer sees how Tapestry interpreted the component declaration, it’s much easier to pinpoint the error. Now, for purely asthetic reasons, let’s make this message more user-friendly:

That error message, at least, should no longer inspire panic and desperate restarts of the testing server.

Using Java 1.5