commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown" <>
Subject Re: [digester] Adding location support
Date Sun, 23 Apr 2006 02:16:28 GMT
I've created the ticket, completed the code and tests, and it all seems to
be working correctly.  The second unit test on
o.a.c.d.pipeline.LocationTransformerTestCase shows how this would most
likely work in reality.

An application would probably define a Location object that has contains the
source uri, the line number, and the column number.  Then, a Locatable
interface that has a single getter/setter for location, would be defined,
allowing configuration objects to implement it.   Then, either the toString
of Location could be included in the toString of the config object, or
exceptions could manually call pull the location out of the config object
and include its info in its message.  The end result is the location
information is now included in all applicable exceptions and messages.

Looking forward to your feedback,


On 4/22/06, Don Brown <> wrote:
> On 4/22/06, Simon Kitching <> wrote:
> >
> > 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.
> Ok, I haven't looked into that part yet.  My goal is to make this
> capability as transparent to Digester as possible.  In fact,  the code I
> just wrote implements a (optional) SAX pipeline (ala Cocoon) that allows a
> user to add "Transformers" to modify the SAX events before they hit
> digester.  I'm thinking of the Location injection to be simply a Transformer
> that the user can create and add to the Digester, so the Digester class
> won't even know of its specific existence.
> This pipeline opens to doors to greater things, such as multi-schema
> support, meaning the code can be written to one XML schema (schema in its
> generic meaning), but support multiple older schemas through transformations
> that trigger if an older format is detected.  For example, project foo has a
> config file format version 1.  For version 2, they add some elements and
> move things around.  Rather than requiring everyone to use the new format,
> they can just add a transformer that triggers only for version 1 files,
> transforming the XML to meet the new format.  The digester rules never know
> any different.
> The pipeline code, as you'll see when I post the patch, only adds 15 or so
> lines to Digester and is itself very small and minimal.
> As CallParamsRule, I'm a digester newbie so I'm new to this.  If that rule
> doesn't support namespaces, I'll see what I can do about fixing that.
> Don

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message