commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [digester] Adding location support
Date Sun, 23 Apr 2006 00:24:19 GMT
On Sat, 2006-04-22 at 16:22 -0700, Don Brown wrote:
> When digester loads in an XML file, the objects created from it have no
> concept from where they came, making it difficult to provide accurate and
> helpful error messages down the line.
> I'd like to add location support for the Digester that would allow a calling
> application to capture the source uri, line number, and column number for
> every element encountered.  This information could then be used by the
> application to provide helpful error messages to their users.  I believe
> Howard calls this "Line-precise error reporting".  I've already added this
> capability to OpenSymphony's XWork, which powers both WebWork and Struts
> Action 2.  I'd like to bring this feature to Struts Action 1 and Commons
> Validator, and Digester is the key.
> My implementation is borrowed from Apache Cocoon (what good XML technique
> isn't ;)) and would be adapted to fit Digester better.  How it works is
> this:
>  1. Place a ContentHandler filter in between the parser and Digester, which
> adds separately-namespeced attributes to each XML element - uri, lineNumber,
> and columnNumber.
>  2. Then, the user can use the builtin namespace support of Digester to feed
> these values into their own Location object and inject it into their
> configuration objects in any way they choose.
> This technique would leverage Digester's rules to allow the parent
> application to have its own Location objects and therefore not require
> Digester imports to be scattered throughout their application.  Furthermore,
> it would only be enabled if namespace support was enabled, allowing for
> complete backwards compatibility.
> I am a Jakarta Commons commiter, so I guess I'm asking a) can I join and b)
> any objections to me adding this feature?

This feature sounds like an excellent idea to me.

I think I would prefer the first few patches to be posted to the list,
for feedback before committing them. But assuming everyone's happy with
the basic approach/api I'd then personally be happy for you to get stuck
in and commit the rest directly.

The namespacing approach might need some thought first. Digester's
namespace handling for pattern-matching pretty much sucks. This probably
isn't relevant here, as that's about matching an ELEMENT using a path,
while you are proposing introducing *attributes* with namespaces, not
elements that need to be matched by user paths. However I think you
*are* relying on CallParamRule(int paramIndex, String attrName) handling
namespaces correctly, so the uri/line/column stuff can be fetched, yes?
It's therefore necessary to make sure that can indeed be used to handle
namespaced data correctly.

Or maybe you're proposing a new "GetSourceInfoRule" that can be
associated with an element, and which retrieves the info from the
element attributes for passing (somehow) to a user object?

Anyway, I'm looking forward to seeing details, and would be happy to
help you get this feature into digester (assuming no-one else has any



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message