Project

Profile

Help

Bug #5145

closed

Logging of unsupported ACCESS_EXTERNAL_DTD when transforming through a JAXBSource

Added by Mário Martinho Dias about 3 years ago. Updated about 3 years ago.

Status:
Rejected
Priority:
Low
Assignee:
Category:
JAXP Java API
Sprint/Milestone:
-
Start date:
2021-10-26
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
10
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

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

saxontest.zip (3.25 KB) saxontest.zip Test project Mário Martinho Dias, 2021-10-26 13:19
Actions #1

Updated by Michael Kay about 3 years 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.

Actions #2

Updated by Mário Martinho Dias about 3 years ago

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...

Actions #3

Updated by Michael Kay about 3 years 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

Also available in: Atom PDF