subject:"Re\: Oracle Java 8u161 regression in XML Schema Factory"

RE: Oracle Java 8u161 regression in XML Schema Factory

2018-03-01 Thread Langer, Christoph

Thanks, Joe.

> -Original Message-
> From: Joe Wang [mailto:huizhe.w...@oracle.com]
> Sent: Donnerstag, 1. März 2018 20:11
> To: Langer, Christoph 
> Cc: OpenJDK Dev list 
> Subject: Re: Oracle Java 8u161 regression in XML Schema Factory
> 
> Hi Christoph and all,
> 
> Just wanted to let you know that we're in progress to update the release
> notes for 6u181/7u171/8u161 with a doc for this change.
> 
> Thanks,
> Joe
> 
> On 2/22/2018 12:47 AM, Langer, Christoph wrote:
> > Hi Joe,
> >
> > thanks for the clarification. It would be good to have a place of
> documentation where one could refer customers to.
> >
> > Thanks
> > Christoph
> >
> >> -Original Message-
> >> From: Joe Wang [mailto:huizhe.w...@oracle.com]
> >> Sent: Mittwoch, 21. Februar 2018 21:50
> >> To: Langer, Christoph 
> >> Cc: Bernd ; OpenJDK Dev list  >> 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
> >>>> Subject: Re: Oracle Java 8u161 regression in XML Schema Factory
> >>>>
> >>>> Hello,
> >>>>
> >>>>
> >>>> 2018-01-25 17:41 GMT+01:00 Seán Coffey:
> >>>>
> >>>>> 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
> >>>&g

Re: Oracle Java 8u161 regression in XML Schema Factory

2018-03-01 Thread Joe Wang


Hi Christoph and all,

Just wanted to let you know that we're in progress to update the release 
notes for 6u181/7u171/8u161 with a doc for this change.


Thanks,
Joe

On 2/22/2018 12:47 AM, Langer, Christoph wrote:

Hi Joe,

thanks for the clarification. It would be good to have a place of documentation 
where one could refer customers to.

Thanks
Christoph


-Original Message-
From: Joe Wang [mailto:huizhe.w...@oracle.com]
Sent: Mittwoch, 21. Februar 2018 21:50
To: Langer, Christoph 
Cc: Bernd ; OpenJDK Dev list 
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
Subject: Re: Oracle Java 8u161 regression in XML Schema Factory

Hello,


2018-01-25 17:41 GMT+01:00 Seán Coffey:


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$PowerMockJUnit44M

RE: Oracle Java 8u161 regression in XML Schema Factory

2018-02-22 Thread Langer, Christoph

Hi Joe,

thanks for the clarification. It would be good to have a place of documentation 
where one could refer customers to.

Thanks
Christoph

> -Original Message-
> From: Joe Wang [mailto:huizhe.w...@oracle.com]
> Sent: Mittwoch, 21. Februar 2018 21:50
> To: Langer, Christoph 
> Cc: Bernd ; OpenJDK Dev list  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
> >> Subject: Re: Oracle Java 8u161 regression in XML Schema Factory
> >>
> >> Hello,
> >>
> >>
> >> 2018-01-25 17:41 GMT+01:00 Seán Coffey:
> >>
> >>> 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.
&

RE: Oracle Java 8u161 regression in XML Schema Factory

2018-02-22 Thread Langer, Christoph

Hi Bernd,

ok, your issue must be something different then.

Best regards
Christoph

> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
> Behalf Of Bernd Eckenfels
> Sent: Mittwoch, 21. Februar 2018 20:01
> To: OpenJDK Dev list 
> 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.w...@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-boun...@openjdk.java.net] On
> > Behalf Of Bernd
> > Sent: Dienstag, 13. Februar 2018 22:55
> > To: OpenJDK Dev list 
> > Subject: Re: Oracle Java 8u161 regression in XML Schema Factory
> >
> > Hello,
> >
> >
> > 2018-01-25 17:41 GMT+01:00 Seán Coffey :
> >
> > >
> > > 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

Re: Oracle Java 8u161 regression in XML Schema Factory

2018-02-21 Thread Joe Wang





@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
Subject: Re: Oracle Java 8u161 regression in XML Schema Factory

Hello,


2018-01-25 17:41 GMT+01:00 Seán Coffey:


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(PowerMockJUnit44RunnerDelegateImp

Re: Oracle Java 8u161 regression in XML Schema Factory

2018-02-21 Thread Bernd Eckenfels

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.w...@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-boun...@openjdk.java.net] On
> Behalf Of Bernd
> Sent: Dienstag, 13. Februar 2018 22:55
> To: OpenJDK Dev list 
> Subject: Re: Oracle Java 8u161 regression in XML Schema Factory
> 
> Hello,
> 
> 
> 2018-01-25 17:41 GMT+01:00 Seán Coffey :
> 
> >
> > 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
> >&g

RE: Oracle Java 8u161 regression in XML Schema Factory

2018-02-21 Thread Langer, Christoph

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-boun...@openjdk.java.net] On
> Behalf Of Bernd
> Sent: Dienstag, 13. Februar 2018 22:55
> To: OpenJDK Dev list 
> Subject: Re: Oracle Java 8u161 regression in XML Schema Factory
> 
> Hello,
> 
> 
> 2018-01-25 17:41 GMT+01:00 Seán Coffey :
> 
> >
> > 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

Re: Oracle Java 8u161 regression in XML Schema Factory

2018-02-13 Thread Bernd

Hello,


2018-01-25 17:41 GMT+01:00 Seán Coffey :

>
> 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.java: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.JUnit4Te

Re: Oracle Java 8u161 regression in XML Schema Factory

2018-01-26 Thread Krystal Mok

Thanks Sean. It's more likely a JDK issue because my coworker simply
swapped the JAVA_HOME from 8u161 which failed with that error to 8u151 and
it worked fine.

I'll ask if he's got the cycles to distill a reproducer. If he does I'll
open a JBS ticket.

Thanks,
Kris

On Fri, Jan 26, 2018 at 12:06 AM, Seán Coffey 
wrote:

> I don't see them being related with data given below. Maybe there's a
> classpath configuration issue ?
>
> If you feel there's a bug in the JDK libraries, please report it via
> https://bugs.java.com/
>
> regards,
> Sean.
> On 26/01/2018 00:23, Krystal Mok wrote:
>
> Hi guys,
>
> A coworker of mine had hit this issue last night on 8u161 and it worked
> fine on 8u151:
>
> ERROR: /home/myuser/.cache/bazel/_bazel_myuser/some_hash_code/
> external/jackson_datatype_joda_shaded/BUILD:5:1: Building
> external/jackson_datatype_joda_shaded/libjackson-datatype-joda-class.jar
> (35 source files) failed (Exit 1)
> java.lang.InternalError: Cannot find requested resource bundle for locale
> en_US
> at com.sun.tools.javac.util.JavacMessages.getBundles(
> JavacMessages.java:128)
> at com.sun.tools.javac.util.JavacMessages.getLocalizedString(
> JavacMessages.java:147)
> at com.sun.tools.javac.util.JavacMessages.getLocalizedString(
> JavacMessages.java:140)
> at com.sun.tools.javac.util.Log.localize(Log.java:788)
> at com.sun.tools.javac.util.Log.printLines(Log.java:586)
> at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(
> JavacTaskImpl.java:170)
> at com.sun.tools.javac.api.JavacTaskImpl.doCall(
> JavacTaskImpl.java:96)
> at com.sun.tools.javac.api.JavacTaskImpl.call(
> JavacTaskImpl.java:90)
> at com.google.devtools.build.buildjar.javac.BlazeJavacMain.
> compile(BlazeJavacMain.java:105)
> at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder$1.
> invokeJavac(SimpleJavaLibraryBuilder.java:106)
> at com.google.devtools.build.buildjar.
> ReducedClasspathJavaLibraryBuilder.compileSources(
> ReducedClasspathJavaLibraryBuilder.java:53)
> at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.
> compileJavaLibrary(SimpleJavaLibraryBuilder.java:109)
> at com.google.devtools.build.buildjar.
> SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:117)
> at com.google.devtools.build.buildjar.BazelJavaBuilder.
> processRequest(BazelJavaBuilder.java:105)
> at com.google.devtools.build.buildjar.BazelJavaBuilder.
> runPersistentWorker(BazelJavaBuilder.java:67)
> at com.google.devtools.build.buildjar.BazelJavaBuilder.
> main(BazelJavaBuilder.java:45)
> Caused by: java.util.MissingResourceException: Can't find bundle for base
> name com.google.errorprone.errors, locale en_US
> at java.util.ResourceBundle.throwMissingResourceException(
> ResourceBundle.java:1573)
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.
> java:1396)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:854)
> at com.sun.tools.javac.util.JavacMessages.lambda$add$0(
> JavacMessages.java:106)
> at com.sun.tools.javac.util.JavacMessages.getBundles(
> JavacMessages.java:125)
> ... 15 more
>
> Resource bundle loading issue...could that be related to this XML issue
> here?
>
> Thanks,
> Kris
>
> On Thu, Jan 25, 2018 at 8:41 AM, Seán Coffey 
> wrote:
>
>> On 25/01/2018 11:58, Bernd wrote:
>>
>> Hello,
>>>
>>> some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and
>>> u162) but work with 8u152.
>>>
>>> I cant reproduce the fault in a stand-alone program so it seems to be
>>> related to classloader/reflection magic of those tools, sorry.
>>>
>>> Is this a regression of 8159240
>>>  (not public?)
>>>
>> Fixes in the CPU releases are kept private - hence the above bug is not
>> public. The changesets do become public once the release is made public
>> though. See : http://hg.openjdk.java.net/jdk
>> 8u/jdk8u/jaxws/rev/06086cb6c349
>>
>> I don't think it's a factor for what you're seeing.
>>
>> 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 ?
>>
>> regards,
>> Sean.
>>
>>
>>> 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.g
>>> etInstance(SchemaDVFactory.java:75)
>>>  at
>>> com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.g
>>> etInstance(SchemaDVFactory.java:5

Re: Oracle Java 8u161 regression in XML Schema Factory

2018-01-26 Thread Seán Coffey

I don't see them being related with data given below. Maybe there's a 
classpath configuration issue ?


If you feel there's a bug in the JDK libraries, please report it via 
https://bugs.java.com/


regards,
Sean.

On 26/01/2018 00:23, Krystal Mok wrote:

Hi guys,

A coworker of mine had hit this issue last night on 8u161 and it 
worked fine on 8u151:


ERROR: 
/home/myuser/.cache/bazel/_bazel_myuser/some_hash_code/external/jackson_datatype_joda_shaded/BUILD:5:1: 
Building 
external/jackson_datatype_joda_shaded/libjackson-datatype-joda-class.jar 
(35 source files) failed (Exit 1)
java.lang.InternalError: Cannot find requested resource bundle for 
locale en_US
        at 
com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:128)
        at 
com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:147)
        at 
com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:140)

        at com.sun.tools.javac.util.Log.localize(Log.java:788)
        at com.sun.tools.javac.util.Log.printLines(Log.java:586)
        at 
com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:170)
        at 
com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:96)
        at 
com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:90)
        at 
com.google.devtools.build.buildjar.javac.BlazeJavacMain.compile(BlazeJavacMain.java:105)
        at 
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder$1.invokeJavac(SimpleJavaLibraryBuilder.java:106)
        at 
com.google.devtools.build.buildjar.ReducedClasspathJavaLibraryBuilder.compileSources(ReducedClasspathJavaLibraryBuilder.java:53)
        at 
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.compileJavaLibrary(SimpleJavaLibraryBuilder.java:109)
        at 
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:117)
        at 
com.google.devtools.build.buildjar.BazelJavaBuilder.processRequest(BazelJavaBuilder.java:105)
        at 
com.google.devtools.build.buildjar.BazelJavaBuilder.runPersistentWorker(BazelJavaBuilder.java:67)
        at 
com.google.devtools.build.buildjar.BazelJavaBuilder.main(BazelJavaBuilder.java:45)
Caused by: java.util.MissingResourceException: Can't find bundle for 
base name com.google.errorprone.errors, locale en_US
        at 
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1573)
        at 
java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)

        at java.util.ResourceBundle.getBundle(ResourceBundle.java:854)
        at 
com.sun.tools.javac.util.JavacMessages.lambda$add$0(JavacMessages.java:106)
        at 
com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:125)

        ... 15 more

Resource bundle loading issue...could that be related to this XML 
issue here?


Thanks,
Kris

On Thu, Jan 25, 2018 at 8:41 AM, Seán Coffey > wrote:


On 25/01/2018 11:58, Bernd wrote:

Hello,

some of our unit tests (using PowerMock and xmlunit) fail with
8u161 (and
u162) but work with 8u152.

I cant reproduce the fault in a stand-alone program so it
seems to be
related to classloader/reflection magic of those tools, sorry.

Is this a regression of 8159240
> (not
public?)

Fixes in the CPU releases are kept private - hence the above bug
is not public. The changesets do become public once the release is
made public though. See :
http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/06086cb6c349


I don't think it's a factor for what you're seeing.

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 ?

regards,
Sean.


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

Re: Oracle Java 8u161 regression in XML Schema Factory

2018-01-25 Thread Krystal Mok

Hi guys,

A coworker of mine had hit this issue last night on 8u161 and it worked
fine on 8u151:

ERROR: 
/home/myuser/.cache/bazel/_bazel_myuser/some_hash_code/external/jackson_datatype_joda_shaded/BUILD:5:1:
Building
external/jackson_datatype_joda_shaded/libjackson-datatype-joda-class.jar
(35 source files) failed (Exit 1)
java.lang.InternalError: Cannot find requested resource bundle for locale
en_US
at
com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:128)
at
com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:147)
at
com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:140)
at com.sun.tools.javac.util.Log.localize(Log.java:788)
at com.sun.tools.javac.util.Log.printLines(Log.java:586)
at
com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:170)
at
com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:96)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:90)
at
com.google.devtools.build.buildjar.javac.BlazeJavacMain.compile(BlazeJavacMain.java:105)
at
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder$1.invokeJavac(SimpleJavaLibraryBuilder.java:106)
at
com.google.devtools.build.buildjar.ReducedClasspathJavaLibraryBuilder.compileSources(ReducedClasspathJavaLibraryBuilder.java:53)
at
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.compileJavaLibrary(SimpleJavaLibraryBuilder.java:109)
at
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:117)
at
com.google.devtools.build.buildjar.BazelJavaBuilder.processRequest(BazelJavaBuilder.java:105)
at
com.google.devtools.build.buildjar.BazelJavaBuilder.runPersistentWorker(BazelJavaBuilder.java:67)
at
com.google.devtools.build.buildjar.BazelJavaBuilder.main(BazelJavaBuilder.java:45)
Caused by: java.util.MissingResourceException: Can't find bundle for base
name com.google.errorprone.errors, locale en_US
at
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1573)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:854)
at
com.sun.tools.javac.util.JavacMessages.lambda$add$0(JavacMessages.java:106)
at
com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:125)
... 15 more

Resource bundle loading issue...could that be related to this XML issue
here?

Thanks,
Kris

On Thu, Jan 25, 2018 at 8:41 AM, Seán Coffey  wrote:

> On 25/01/2018 11:58, Bernd wrote:
>
> Hello,
>>
>> some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and
>> u162) but work with 8u152.
>>
>> I cant reproduce the fault in a stand-alone program so it seems to be
>> related to classloader/reflection magic of those tools, sorry.
>>
>> Is this a regression of 8159240
>>  (not public?)
>>
> Fixes in the CPU releases are kept private - hence the above bug is not
> public. The changesets do become public once the release is made public
> though. See : http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/06086cb6c34
> 9
>
> I don't think it's a factor for what you're seeing.
>
> 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 ?
>
> regards,
> Sean.
>
>
>> 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.ap

Re: Oracle Java 8u161 regression in XML Schema Factory

2018-01-25 Thread Seán Coffey


On 25/01/2018 11:58, Bernd wrote:


Hello,

some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and
u162) but work with 8u152.

I cant reproduce the fault in a stand-alone program so it seems to be
related to classloader/reflection magic of those tools, sorry.

Is this a regression of 8159240
 (not public?)
Fixes in the CPU releases are kept private - hence the above bug is not 
public. The changesets do become public once the release is made public 
though. See : http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/06086cb6c349


I don't think it's a factor for what you're seeing.

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 ?


regards,
Sean.


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.XMLSchemaFactory.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.getCRSchemaValidator(BuilderTestHelper.java:57)
 at
com.seeburger.api.test.helpers.BuilderTestHelper.validateAndCompare(BuilderTestHelper.java:73)
 at
com.seeburger.api.test.KSMBuilderTest.testDeletePGP(KSMBuilderTest.java:196)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:310)
 at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:89)
 at
org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:97)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:294)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:127)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:82)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(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.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:207)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:146)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
 at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
 at
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
 at
org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:106)
 at
org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
 at
org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:59)

RE: Oracle Java 8u161 regression in XML Schema Factory

Re: Oracle Java 8u161 regression in XML Schema Factory

RE: Oracle Java 8u161 regression in XML Schema Factory

RE: Oracle Java 8u161 regression in XML Schema Factory

Re: Oracle Java 8u161 regression in XML Schema Factory

Re: Oracle Java 8u161 regression in XML Schema Factory

RE: Oracle Java 8u161 regression in XML Schema Factory

Re: Oracle Java 8u161 regression in XML Schema Factory

Re: Oracle Java 8u161 regression in XML Schema Factory

Re: Oracle Java 8u161 regression in XML Schema Factory

Re: Oracle Java 8u161 regression in XML Schema Factory

Re: Oracle Java 8u161 regression in XML Schema Factory

12 matches

Site Navigation

Mail list logo

Footer information