I think this is the same problem I found a few weeks ago, but have been
unable to spend any time looking further into it's cause.
I'd definitely support this fix.
At 7/15/2001 09:05 PM -0700, you wrote:
>Ah, this was when I converted to SAX 2.0. I did not know that the localName
>would be null. This would possibly explain why Xerces would not process my
>rules, but Crimson would, I would hope.
>
>As far as the proposal, I think that is fine. Someone will speak up if it
>is not...
>
>Scott
>
>PS I will work on updating this Tuesday or Wednesday.
>
>
> > If you will recall, Scott changed the Commons version of Digester to
> > support JAXP/1.1, including namespace-awareness support. However, when
> > trying to port Struts to use the Commons version of this package, I
> > discovered a problem in the 1.0 release of Digester -- it *only* works
> > when setNamespaceAware(true) is called!
> >
> > The reason for this is in the argument values passed to startElement() and
> > endElement(). When namespace-awareness is turned on, you get:
> > - localName = "local" part of the name
> > - qName = fully qualified name (including the prefix and ':')
> >
> > but when namespace-awareness is turned off, you get:
> > - localName = zero-length string (!)
> > - qName = "local" part of the name
> >
> > The problem comes from the fact that Digester is currently using localName
> > as the basis for matching which rules should be fired. So, with namespace
> > awareness turned off, you never fire any rules ...
> >
> > I propose to change startElement() and endElement() to work as follows:
> > - If namespace-awareness is turned on, match on localName
> > (i.e. the current behavior)
> > - If namespace-awareness is turned off, match on qName
> >
> > This will have the effect that matching patterns for rules will always be
> > specified with only the "local" portion of an element name, and matching
> > will ignore namespace prefixes entirely. (I will make sure that the same
> > principle is used in matching property names for the SetPropertyRule and
> > SetPropertiesRule mechanisms).
> >
> > Any problems with this?
> >
> > Craig
> >
> >
