Jason,
it seems I forgot to disable the "endorsed" directory in my 1.5.0_03 JDK
when I did the test. Sloppy me. Sorry. The problem does occur with
an unpatched 1.5.0_03. All the worse for Sun. :-)
On 24.02.2006 22:07:14 Jason R Briggs wrote:
> Hi Jeremias
>
> I'm running 1.5.0_06 (linux) so it's strange the the problem doesn't
> occur for you with 1.5.0_03. Also seems a bit odd that there would be
> differences between linux and windows (assuming you're using windows)
> xml parser/xslt versions.
>
> Anyway, I copied the jars into endorsed as specified, and indeed that
> does fix the problem. Good news!
>
> Thanks for the prompt reply and your efforts.
>
> Kind regards
> Jason
>
>
> Jeremias Maerki wrote:
> > Horrible! Here's what I found out:
> >
> > It's Sun's fault. :-) Mostly, anyway.
> >
> > I've recently changed FOP to use the JAXP/TRaX API (javax.transform) to
> > build (SVG) DOMs from a SAX stream. If Xalan-J is the primary XSLT
> > implementation, org.apache.xml.utils.DOMBuilder is used internally to
> > build the DOM. So much for the context.
> >
> > The symptom: The BridgeException happens because Batik cannot find the
> > "r" attribute. Batik cannot find the "r" attribute because
> > org.apache.batik.dom.AbstractElement.get(String, String) encounters a
> > mismatch: The "r" attribute has been specified with an empty String ("")
> > as the namespace URI but is now looking for "r" with a null namespace
> > URI. This means that the attribute was set on the DOM element using an
> > empty String in the namespace URI by DOMBuilder.
> >
> > If you let the SAXSVGDocumentFactory (a Batik class) do the same job, an
> > empty String reported by a SAX parser will be converted to a null value.
> > No error happens. So, for SVG, this would be a work-around we could
> > implement.
> >
> > Even the latest Sun JDK 1.4.2_10 contains an ancient version of Apache
> > Xalan-J as its XSLT implementation. With bugs, of course. Xalan-J
> > versions (Apache versions that is) after 2000-12-31 have a change that
> > convert the namespace URI from a null namespace URI to an empty String
> > [1]. (This tells something about how old the code in Sun JDK 1.4.2_10 is).
> > Note, this is actually the opposite of what we would expect, since the
> > DOM Level 2 specification says that null represents the right value for
> > an attribute that is in no namespace. However, the SAX AttributesImpl [2]
> > expects an empty String to indicate the same. It's interesting thing is
> > a change [3] on 2002-07-10 which suddenly starts to convert empty
> > Strings to null values (which is actually my expectation).
> >
> > I see several ways to go:
> > - The easiest (and my recommendation) is to use the endorsed standards
> > override mechanism to replace the XML parser and XSLT implementation.
> > - Change SVG building to use SAXSVGDocumentFactory. Downside: this only
> > helps with SVG and not with any other namespace.
> > - Look into the Batik source code if a defensive check could be added so
> > empty Strings are converted to null values. Downside: Is available only
> > after the next Batik release and it may not be the right thing to do.
> > But I can still let them know about the issue.
> > - Create our own DOMBuilder. Downside: Code duplication, a lot of work,
> > potential bugs etc.
> >
> > Woa, a lot of text. My opinion: Mark this as "WON'T FIX" and rely on
> > replacing the buggy Xalan implementation as described earlier.
> >
> > [1] http://svn.apache.org/viewcvs.cgi?rev=334122&view=rev
> > [2]
> > http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-745549614
> > (see setAttributeNS)
> > [3] http://svn.apache.org/viewcvs.cgi?rev=336570&view=rev
> >
> > On 24.02.2006 10:02:24 Jeremias Maerki wrote:
> >
> >>Jason, after some tests I found out that this only fails with JDK 1.4.2
> >>without any overridden endorsed libraries [1] in place. It doesn't
> >>happen with an unpatched JDK 1.5.0_03, for example. I always use the
> >>latest Xerces and Xalan version which is why I didn't stumble upon the
> >>problem when I changed the way SVG is parsed in FOP Trunk recently. I'll
> >>try to track down the problem because this is still a little suspicious.
> >>But since the XML parser and XSLT implementation shipped with JDK 1.4
> >>are known to have issues I suggest you replace those in your JDK
> >>installation. Despite the problem at hand it is (IMO) generally a good
> >>idea to do.
> >>
> >>To replace the JARs:
> >>Create a directory called "endorsed" under the jre/lib directory of your
> >>JDK installation (applies to all versions >= 1.4.0) and put all the
> >>XML-related JARs shipped with FOP in there, i.e. "xml-apis", "xercesImpl",
> >>"xalan" and "serializer".
> >>
> >>[1] http://java.sun.com/j2se/1.4.2/docs/guide/standards/
> >>
> >>On 23.02.2006 09:17:23 Jason R Briggs wrote:
> >>
> >>>Anyone else experiencing problems with SVG with the trunk version of fop?
> >>>
> >>>For example, the FO below works perfectly in 0.91beta, but doesn't
> >>>throws an error (see below FO) in the latest trunk version.
> >>>Unfortunately I can't use 0.91 because I have some really odd layout
> >>>problems that completely vanish in trunk.
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
