Bug #5145
closed
Logging of unsupported ACCESS_EXTERNAL_DTD when transforming through a JAXBSource
Fixed in Maintenance Release:
Description
Support for the property http://javax.xml.XMLConstants/property/accessExternalDTD
was introduced in Saxon 10.3 (see #4729).
But when using a transformation with a JAXBSource
, Saxon logs to standard error:
Selected XML parser javax.xml.bind.util.JAXBSource$1 does not recognize the property http://javax.xml.XMLConstants/property/accessExternalDTD
Multiple frameworks/libraries, namely Spring Framework, initialize their TransformerFactories
with this property set.
This was unexpected behavior, and the only workaround I've found is suppressing the message through a custom net.sf.saxon.lib.Logger
which seems hackish, transformations function normally otherwise.
I've attached a sample test project with a unit test.
Files
My immediate reaction is that if the application is trying to restrict access to DTDs, and the chosen XML parser ignores this (which presumably means that it will fetch the DTD despite the attempt to disallow it), then a warning is entirely appropriate.
I appreciate that this is caused by a conflict between off-the-shelf components that we're not able to change, but I don't think it's right to pretend that this conflict doesn't exist.
The issue is that the "chosen" XML parser is the same, I didn't change it. The only difference in the unit tests is the TransformerFactory
implementation, default vs Saxon. But maybe something else is escaping me...
- Category set to JAXP Java API
- Status changed from New to Rejected
- Assignee set to Michael Kay
I'm afraid we're seeing a lot of configuration issues in this area, because different parts of the XML jigsaw (even parts contained within the JDK) have advanced at different rates. Saxon is caught up in the middle here. The JAXP spec changed in JAXP 1.5 to require components to "support" some standard security-related properties such as ACCESS_EXTERNAL_DTD
-- including in this case an XSLT processor, which can't do anything with this property other than pass it on to an XML parser. The spec doesn't say what "support" means, but in my book it means it should accept the property and do its best to make sure that it has the intended effect, and if it finds that the underlying parser takes no notice, that merits at least a warning.
Sorry, but I think Saxon is doing the right thing here. Not a bug,
Please register to edit this issue
Also available in: Atom
PDF