Oracle Java 8u161 regression in XML Schema Factory
Langer, Christoph
christoph.langer at sap.com
Thu Feb 22 08:45:14 UTC 2018
Hi Bernd,
ok, your issue must be something different then.
Best regards
Christoph
> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of Bernd Eckenfels
> Sent: Mittwoch, 21. Februar 2018 20:01
> To: OpenJDK Dev list <core-libs-dev at openjdk.java.net>
> Subject: Re: Oracle Java 8u161 regression in XML Schema Factory
>
> Hallo Christoph,
>
> Yes the Tests fail with -Djdk.xml.overrideDefaultParser=true (and false) as
> well.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> Von: Langer, Christoph
> Gesendet: Mittwoch, 21. Februar 2018 16:16
> An: Bernd; OpenJDK Dev list; huizhe.wang at oracle.com
> Betreff: RE: Oracle Java 8u161 regression in XML Schema Factory
>
> Hi Bernd,
>
> would your test still fail with system property "-
> Djdk.xml.overrideDefaultParser=true"?
>
> I debugged a similar issue (if not the same) today and found that with change
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jaxp/rev/08a44c164993 the
> default behavior for Xalan changed a bit.
>
> Before that change, the services mechanism was enabled to load the SAX
> and DOM implementations for the use of Xalan. E.g. when
> TransformerFactory.newInstance() was called, the services mechanism was
> used and in the TransformerFactory (at least if it was the default JDK
> implementation), the property to use the services mechanism was set as
> well - wich was used to retrieve SAX and DOM parser implementations.
>
> And what hit me even more was that SAX2DOM had its private field
> "DocumentBuilderFactory _factory" automatically initialized by a call to
> DocumentBuilderFactory.newInstance() which in turn would resolve any
> custom DBF implementation if it were on classpath. Now, with the new
> implementation, the _factory in SAX2DOM will be initialized with the
> "overrideDefaultParser " setting coming from the Transformer Factory. So,
> by setting -Djdk.xml.overrideDefaultParser=true, you will restore the old
> behavior.
>
> @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).
>
> Best regards
> Christoph
>
> > -----Original Message-----
> > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> > Behalf Of Bernd
> > Sent: Dienstag, 13. Februar 2018 22:55
> > To: OpenJDK Dev list <core-libs-dev at 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.coffey at 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
> > >>
> > >
More information about the core-libs-dev
mailing list