Logging of unsupported ACCESS_EXTERNAL_DTD when transforming through a JAXBSource
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.
#1 Updated by Michael Kay about 1 month ago
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.
#3 Updated by Michael Kay 28 days ago
- 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