-----Original Message-----
From: Joe Wang [mailto:huizhe.w...@oracle.com]
Sent: Mittwoch, 21. Februar 2018 21:50
To: Langer, Christoph <christoph.lan...@sap.com>
Cc: Bernd <e...@zusammenkunft.net>; OpenJDK Dev list <core-libs-
d...@openjdk.java.net>
Subject: Re: Oracle Java 8u161 regression in XML Schema Factory
@Joe: Is there some documentation for this change in default behavior
that came with JDK8u161? I assume it is for higher security and cannot be
reverted (e.g. by setting the feature default for
Djdk.xml.overrideDefaultParser to true).
It is indeed. It was a customer's request. Customers' complaints were
that a factory created through the official API could in many cases,
unknowingly to the customers, load 3rd party parsers that didn't
necessarily implement the security features added since JDK7u40 and 8.
For customers, this behavior was a security concern. It was particularly
inconvenient to users who might have some 3rd party libraries that just
happen to be in their environment.
This change was not mentioned in the release notes. I'll check whether
we could find a right place for a note of this change. The 8u161 release
notes would have been a good place to do so.
Best,
Joe
Best regards
Christoph
-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
Behalf Of Bernd
Sent: Dienstag, 13. Februar 2018 22:55
To: OpenJDK Dev list<core-libs-dev@openjdk.java.net>
Subject: Re: Oracle Java 8u161 regression in XML Schema Factory
Hello,
2018-01-25 17:41 GMT+01:00 Seán Coffey<sean.cof...@oracle.com>:
Classes nearer to those below were touched via JDK-8186080: Transform
XML
interfaces
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/cb84156d54b2
http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/08a44c164993
This may be connected with some tools trying to redefine the classes
perhaps. Needs more investigating. Perhaps the XMLSchemaLoader
changes are
a factor ?
I have ben able to extract a minimal reproducer. It is not related to
XMLUnit, only to powermock. If it instruments com.sun but not javax.xml
(and other combinations) then it fails.
For details see the readme in this maven project:
https://github.com/ecki/reproduce-schemaex
I also found a way to make it work with both versions, so its no longer an
issue for me, but there is definitely some changes (which might also be
triggered in AppServers or OSGi containers with partially reconfigured
implementations. Not sure if you want to investigate deeper).
Gruss
Bernd
Here is the stacktrace anyway:
com.sun.org.apache.xerces.internal.impl.dv.DVFactoryException:
Schema
factory class
com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl
does
not
extend from SchemaDVFactory.
at
com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.
getInstance(SchemaDVFactory.java:75)
at
com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.
getInstance(SchemaDVFactory.java:57)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.
reset(XMLSchemaLoader.java:1024)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.
loadGrammar(XMLSchemaLoader.java:556)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.
loadGrammar(XMLSchemaLoader.java:535)
at
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchema
Factory.newSchema(XMLSchemaFactory.java:254)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.
java:638)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.
java:654)
at
com.seeburger.api.test.helpers.BuilderTestHelper.getCRSchema
Validator(BuilderTestHelper.java:57)
at
com.seeburger.api.test.helpers.BuilderTestHelper.validateAnd
Compare(BuilderTestHelper.java:73)
at
com.seeburger.api.test.KSMBuilderTest.testDeletePGP(KSMBuild
erTest.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
ssorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
thodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.internal.runners.TestMethod.invoke(TestMethod.java:68)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44R
unnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod
(PowerMockJUnit44RunnerDelegateImpl.java:310)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.
java:89)
at
org.junit.internal.runners.MethodRoadie.runBeforesThenTestTh
enAfters(MethodRoadie.java:97)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44R
unnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(P
owerMockJUnit44RunnerDelegateImpl.java:294)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47R
unnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestIn
Super(PowerMockJUnit47RunnerDelegateImpl.java:127)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47R
unnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(P
owerMockJUnit47RunnerDelegateImpl.java:82)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44R
unnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThe
nTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:282)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie
.java:87)
at
org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:50)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44R
unnerDelegateImpl.invokeTestMethod(PowerMockJUni
t44RunnerDelegateImpl.java:207)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44R
unnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.ja
va:146)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44R
unnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassR
oadie.java:34)
at
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44R
unnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
at
org.powermock.modules.junit4.common.internal.impl.JUnit4Test
SuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:106)
at
org.powermock.modules.junit4.common.internal.impl.AbstractCo
mmonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
at
org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.
java:59)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.
run(JUnit4TestReference.java:86)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(
TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
sts(RemoteTestRunner.java:539)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
sts(RemoteTestRunner.java:761)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
RemoteTestRunner.java:461)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
RemoteTestRunner.java:207)
on the classpath jaxb-impl-2.2.5.jar but the specific packages are only
loaded from rt.jar and redefined. I asume the later is done by
Powermock.
Line 611: [Loaded
com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory from
C:\Program
Files\Java\jdk1.8.0_161\jre\lib\rt.jar]
Line 616: [Loaded
com.sun.org.apache.xerces.internal.impl.dv.xs.BaseSchemaDVFactory
from
C:\Program Files\Java\jdk1.8.0_161\jre\lib\rt.jar]
Line 617: [Loaded
com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl
from
C:\Program Files\Java\jdk1.8.0_161\jre\lib\rt.jar]
Line 618: [Loaded
com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory from
__JVM_DefineClass__]
Line 619: [Loaded
com.sun.org.apache.xerces.internal.impl.dv.xs.BaseSchemaDVFactory
from
__JVM_DefineClass__]
Line 620: [Loaded
com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl
from
__JVM_DefineClass__]
Is that something you are concerned?
Gruss
Bernd
