RFR (JAXP) 8158084: Catalog API: JAXP XML Processor Support
huizhe.wang at oracle.com
Mon Jul 25 17:40:17 UTC 2016
Thanks Christoph. Fixed those headers. I wished to get these classes
free from warnings, but had to find a balance between fixing warnings
and adding too much noise to the patch. We could definitely make some
dedicated warning patches.
On 7/25/2016 8:27 AM, Langer, Christoph wrote:
> Hi Joe,
> looking good to me at a glance and contains some nice cleanups/warning fixes. But of course I'm not a reviewer.
> I think in
> you forgot to add the year 2016 to the copyright header.
> Also in
> the $id tag under the header can be removed.
> Best regards
>> -----Original Message-----
>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf
>> Of huizhe wang
>> Sent: Montag, 25. Juli 2016 06:45
>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>> Subject: RFR (JAXP) 8158084: Catalog API: JAXP XML Processor Support
>> This is an enhancement to support the Catalog API (javax.xml.catalog)
>> throughout the JAXP processors. All of the CatalogFeatures are supported
>> by the JAXP factories and processors (e.g. SAXParser), and corresponding
>> System properties as specified in the CatalogFeatures. An additional
>> javax.xml property "USE_CATALOG" is added to allow switching on/off the
>> Catalog support for a processor or all of them (through the System
>> properties or jaxp.properties).
>> The USE_CATALOG feature is on by default for all processors. The only
>> thing needed then, to resolve external references with a catalog, is
>> setting the path to the catalog on the processor. While the USE_CATALOG
>> is on by default, the Catalog support is noninterference. As long as no
>> catalog is set, the Catalog is mute. Catalog, even if one exists, will
>> not interfere with custom resolvers, it is simply ignored if a custom
>> resolver is present.
>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8158084/webrev/
>> Tests: 140ish new test cases; all existing SQE/unit tests pass. JCK has
>> a large number of failures due to one Catalog API test that left a
>> configuration file behind. I'll discuss that with the JCK team.
More information about the core-libs-dev