9:15 a.m.
I'm looking into why the cdi-tck is failing to run on wildfly-10.1.0.Final-SNAPSHOT
using java 9 and a common issue that I don't see in the Java 9 Problems &
Solutions FAQ is illustrated by the following exception trace. It appears that the class
loader that org.arquillian.container.chameleon.ContainerLoader is using is associated with
the java.base module, and thus cannot see anything but the java.base classes. Once I
figure out how the class loader for java.base is being obtained I'll raise a general
FAQ for the problems/solutions doc, but I thought I might be able to work around this by
using the -XaddReads:java.sql=java.base to allow java.base to see java.sql, but it does
not work. Similarly, -XaddExports:java.sql/java.sql=java.base does not work.
Is there a check to prevent circular references or am I just not understanding how these
calls change the module graph?
Tests run: 4, Failures: 1, Errors: 0, Skipped: 3, Time elapsed: 1.121 sec <<<
FAILURE!
arquillianBeforeSuite(org.jboss.arq_wf_test.CDITest) Time elapsed: 0.63 sec <<<
FAILURE!
java.lang.NoClassDefFoundError: java/sql/Date
at org.yaml.snakeyaml.nodes.Tag.<clinit>(Tag.java:64)
at org.yaml.snakeyaml.constructor.SafeConstructor.<init>(SafeConstructor.java:52)
at org.yaml.snakeyaml.constructor.Constructor.<init>(Constructor.java:77)
at org.yaml.snakeyaml.constructor.Constructor.<init>(Constructor.java:64)
at org.yaml.snakeyaml.constructor.Constructor.<init>(Constructor.java:54)
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base@9-ea/NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base@9-ea/DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(java.base@9-ea/Constructor.java:453)
at java.lang.Class.newInstance(java.base@9-ea/Class.java:569)
at
org.arquillian.container.chameleon.ContainerLoader.loadContainers(ContainerLoader.java:71)
at org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:45)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:117)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:70)
at org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:39)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:62)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:55)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachContainer(ContainerLifecycleController.java:209)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.setupContainers(ContainerLifecycleController.java:54)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at
org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:85)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at
org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75)
at org.jboss.arquillian.testng.Arquillian.arquillianBeforeSuite(Arquillian.java:71)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:514)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:215)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1169)
at org.testng.TestNG.run(TestNG.java:1064)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110)
at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.ClassNotFoundException: java.sql.Date
at java.net.URLClassLoader.findClass(java.base@9-ea/URLClassLoader.java:384)
at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:486)
at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
... 85 more
10:36 a.m.
So the problem is a change in behavior of a URLClassLoader that has a null parent class
loader. This seems like it is a big compatibility problem as classes defined by such a
class loader only have visibility into the java.base module rather than the entire
platform.
The simple fix is to pass in the new ClassLoader.getPlatformClassLoader() as the
URLClassLoader parent rather than null. However, this seems like what the ClassLoader
should be doing itself as I would expect a lot of code will break. I'll create a bug
report for the simple test case I have that shows the problem.
----- Original Message -----
From: "Scott Stark" <sstark(a)redhat.com>
To: wildfly-dev(a)lists.jboss.org
Sent: Monday, July 11, 2016 12:15:32 AM
Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9
I'm looking into why the cdi-tck is failing to run on wildfly-10.1.0.Final-SNAPSHOT
using java 9 and a common issue that I don't see in the Java 9 Problems &
Solutions FAQ is illustrated by the following exception trace. It appears that the class
loader that org.arquillian.container.chameleon.ContainerLoader is using is associated with
the java.base module, and thus cannot see anything but the java.base classes. Once I
figure out how the class loader for java.base is being obtained I'll raise a general
FAQ for the problems/solutions doc, but I thought I might be able to work around this by
using the -XaddReads:java.sql=java.base to allow java.base to see java.sql, but it does
not work. Similarly, -XaddExports:java.sql/java.sql=java.base does not work.
Is there a check to prevent circular references or am I just not understanding how these
calls change the module graph?
Tests run: 4, Failures: 1, Errors: 0, Skipped: 3, Time elapsed: 1.121 sec <<<
FAILURE!
arquillianBeforeSuite(org.jboss.arq_wf_test.CDITest) Time elapsed: 0.63 sec <<<
FAILURE!
java.lang.NoClassDefFoundError: java/sql/Date
at org.yaml.snakeyaml.nodes.Tag.<clinit>(Tag.java:64)
at org.yaml.snakeyaml.constructor.SafeConstructor.<init>(SafeConstructor.java:52)
at org.yaml.snakeyaml.constructor.Constructor.<init>(Constructor.java:77)
at org.yaml.snakeyaml.constructor.Constructor.<init>(Constructor.java:64)
at org.yaml.snakeyaml.constructor.Constructor.<init>(Constructor.java:54)
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base@9-ea/NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base@9-ea/DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(java.base@9-ea/Constructor.java:453)
at java.lang.Class.newInstance(java.base@9-ea/Class.java:569)
at
org.arquillian.container.chameleon.ContainerLoader.loadContainers(ContainerLoader.java:71)
at org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:45)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:117)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:70)
at org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:39)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:62)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:55)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachContainer(ContainerLifecycleController.java:209)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.setupContainers(ContainerLifecycleController.java:54)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at
org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:85)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at
org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75)
at org.jboss.arquillian.testng.Arquillian.arquillianBeforeSuite(Arquillian.java:71)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:514)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:215)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1169)
at org.testng.TestNG.run(TestNG.java:1064)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110)
at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.ClassNotFoundException: java.sql.Date
at java.net.URLClassLoader.findClass(java.base@9-ea/URLClassLoader.java:384)
at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:486)
at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
... 85 more
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:44 p.m.
This is one of known issues, see for details:
http://openjdk.java.net/projects/jigsaw/spec/issues/#module-graphs
http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources
http://openjdk.java.net/projects/jigsaw/spec/issues/#PlatformClassLoader
Some of this is being addressed as part upcoming jigsaw b126
--
tomaz
On Mon, Jul 11, 2016 at 10:36 AM, Scott Stark <sstark(a)redhat.com> wrote:
So the problem is a change in behavior of a URLClassLoader that has a
null
parent class loader. This seems like it is a big compatibility problem as
classes defined by such a class loader only have visibility into the
java.base module rather than the entire platform.
The simple fix is to pass in the new ClassLoader.getPlatformClassLoader()
as the URLClassLoader parent rather than null. However, this seems like
what the ClassLoader should be doing itself as I would expect a lot of code
will break. I'll create a bug report for the simple test case I have that
shows the problem.
----- Original Message -----
From: "Scott Stark" <sstark(a)redhat.com>
To: wildfly-dev(a)lists.jboss.org
Sent: Monday, July 11, 2016 12:15:32 AM
Subject: [wildfly-dev] common cdi-tck problem on wildfly with java 9
I'm looking into why the cdi-tck is failing to run on
wildfly-10.1.0.Final-SNAPSHOT using java 9 and a common issue that I don't
see in the Java 9 Problems & Solutions FAQ is illustrated by the following
exception trace. It appears that the class loader that
org.arquillian.container.chameleon.ContainerLoader is using is associated
with the java.base module, and thus cannot see anything but the java.base
classes. Once I figure out how the class loader for java.base is being
obtained I'll raise a general FAQ for the problems/solutions doc, but I
thought I might be able to work around this by using the
-XaddReads:java.sql=java.base to allow java.base to see java.sql, but it
does not work. Similarly, -XaddExports:java.sql/java.sql=java.base does not
work.
Is there a check to prevent circular references or am I just not
understanding how these calls change the module graph?
Tests run: 4, Failures: 1, Errors: 0, Skipped: 3, Time elapsed: 1.121 sec
<<< FAILURE!
arquillianBeforeSuite(org.jboss.arq_wf_test.CDITest) Time elapsed: 0.63
sec <<< FAILURE!
java.lang.NoClassDefFoundError: java/sql/Date
at org.yaml.snakeyaml.nodes.Tag.<clinit>(Tag.java:64)
at
org.yaml.snakeyaml.constructor.SafeConstructor.<init>(SafeConstructor.java:52)
at
org.yaml.snakeyaml.constructor.Constructor.<init>(Constructor.java:77)
at
org.yaml.snakeyaml.constructor.Constructor.<init>(Constructor.java:64)
at
org.yaml.snakeyaml.constructor.Constructor.<init>(Constructor.java:54)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base@9-ea
/NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base@9-ea
/DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(java.base@9-ea
/Constructor.java:453)
at java.lang.Class.newInstance(java.base@9-ea/Class.java:569)
at
org.arquillian.container.chameleon.ContainerLoader.loadContainers(ContainerLoader.java:71)
at
org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:45)
at
org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:117)
at
org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
at
org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:70)
at
org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:39)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:62)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$1.perform(ContainerLifecycleController.java:55)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachContainer(ContainerLifecycleController.java:209)
at
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.setupContainers(ContainerLifecycleController.java:54)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at
org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:85)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at
org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75)
at
org.jboss.arquillian.testng.Arquillian.arquillianBeforeSuite(Arquillian.java:71)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86)
at
org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:514)
at
org.testng.internal.Invoker.invokeConfigurations(Invoker.java:215)
at
org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1169)
at org.testng.TestNG.run(TestNG.java:1064)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110)
at
org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.ClassNotFoundException: java.sql.Date
at java.net.URLClassLoader.findClass(java.base@9-ea
/URLClassLoader.java:384)
at java.lang.ClassLoader.loadClass(java.base@9-ea
/ClassLoader.java:486)
at java.lang.ClassLoader.loadClass(java.base@9-ea
/ClassLoader.java:419)
... 85 more
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
7:48 p.m.
Ok, I'll look at those, but I am using the b126 build. Maybe the fix slipped.
[tmp 512]$ java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+126)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126, mixed mode)
----- Original Message -----
From: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
To: "Scott Stark" <sstark(a)redhat.com>
Cc: wildfly-dev(a)lists.jboss.org
Sent: Monday, July 11, 2016 6:44:36 AM
Subject: Re: [wildfly-dev] common cdi-tck problem on wildfly with java 9
This is one of known issues, see for details:
http://openjdk.java.net/projects/jigsaw/spec/issues/#module-graphs
http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources
http://openjdk.java.net/projects/jigsaw/spec/issues/#PlatformClassLoader
Some of this is being addressed as part upcoming jigsaw b126
--
tomaz
On Mon, Jul 11, 2016 at 10:36 AM, Scott Stark <sstark(a)redhat.com> wrote:
So the problem is a change in behavior of a URLClassLoader that has a
null
parent class loader. This seems like it is a big compatibility problem as
classes defined by such a class loader only have visibility into the
java.base module rather than the entire platform.
The simple fix is to pass in the new ClassLoader.getPlatformClassLoader()
as the URLClassLoader parent rather than null. However, this seems like
what the ClassLoader should be doing itself as I would expect a lot of code
will break. I'll create a bug report for the simple test case I have that
shows the problem.
8:59 p.m.
I don't see that those issues deal with the change in behavior regarding a null parent
class loader. They deal with the inability to add reads that are apparent cycles and the
addition of a ClassLoader.get PlatformClassLoader() method, which has been added in build
126. I have submitted a bug with the test example found here:
https://github.com/RedHatJava9Testing/URLClassLoader.git
----- Original Message -----
From: "Scott Stark" <sstark(a)redhat.com>
To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
Cc: wildfly-dev(a)lists.jboss.org
Sent: Monday, July 11, 2016 10:48:37 AM
Subject: Re: [wildfly-dev] common cdi-tck problem on wildfly with java 9
Ok, I'll look at those, but I am using the b126 build. Maybe the fix slipped.
[tmp 512]$ java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+126)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126, mixed mode)
----- Original Message -----
From: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
To: "Scott Stark" <sstark(a)redhat.com>
Cc: wildfly-dev(a)lists.jboss.org
Sent: Monday, July 11, 2016 6:44:36 AM
Subject: Re: [wildfly-dev] common cdi-tck problem on wildfly with java 9
This is one of known issues, see for details:
http://openjdk.java.net/projects/jigsaw/spec/issues/#module-graphs
http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources
http://openjdk.java.net/projects/jigsaw/spec/issues/#PlatformClassLoader
Some of this is being addressed as part upcoming jigsaw b126
--
tomaz
On Mon, Jul 11, 2016 at 10:36 AM, Scott Stark <sstark(a)redhat.com> wrote:
So the problem is a change in behavior of a URLClassLoader that has a
null
parent class loader. This seems like it is a big compatibility problem as
classes defined by such a class loader only have visibility into the
java.base module rather than the entire platform.
The simple fix is to pass in the new ClassLoader.getPlatformClassLoader()
as the URLClassLoader parent rather than null. However, this seems like
what the ClassLoader should be doing itself as I would expect a lot of code
will break. I'll create a bug report for the simple test case I have that
shows the problem.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:22 p.m.
On Mon, Jul 11, 2016 at 7:48 PM, Scott Stark <sstark(a)redhat.com> wrote:
[tmp 512]$ java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+126)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126, mixed mode)
You are using "wrong" b126, this is from main line, grab b126 jigsaw build
that was just published to
https://jdk9.java.net/jigsaw/
C:\development\tools\jdk\jdk-9\bin> ./java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+
126-2016-07-10-164835.javare.5266.nc)
Java HotSpot(TM) Client VM (build 9-ea+126-2016-07-10-164835.javare.5266.nc,
mixed mode)
9:38 p.m.
Ok, I just tried it and I don't see the --add-reads changing the behavior as I would
expect:
[URLClassLoader 558]$ $JAVA9_HOME/bin/java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+126-2016-07-10-165150.javare.5266.nc)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126-2016-07-10-165150.javare.5266.nc, mixed
mode)
[URLClassLoader 557]$ $JAVA9_HOME/bin/java -Xdiag --add-reads java.sql=java.base -cp bin
TestURLClassLoader
...
[Resolver] jdk.zipfs
rootURL=file:/private/tmp/URLClassLoader/bin/
Loaded class: class JavaSqlUser, loader=java.net.URLClassLoader@51565ec2
Exception in thread "main" java.lang.reflect.InvocationTargetException
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base@9-ea/NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base@9-ea/DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(java.base@9-ea/Constructor.java:453)
at TestURLClassLoader.main(TestURLClassLoader.java:26)
Caused by: java.lang.NoClassDefFoundError: java/sql/Date
at SqlDateUser.<init>(SqlDateUser.java:7)
at JavaSqlUser.<init>(JavaSqlUser.java:12)
... 5 more
Caused by: java.lang.ClassNotFoundException: java.sql.Date
at java.net.URLClassLoader.findClass(java.base@9-ea/URLClassLoader.java:384)
at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:486)
at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
... 7 more
----- Original Message -----
From: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
To: "Scott Stark" <sstark(a)redhat.com>
Cc: wildfly-dev(a)lists.jboss.org
Sent: Monday, July 11, 2016 12:22:34 PM
Subject: Re: [wildfly-dev] common cdi-tck problem on wildfly with java 9
On Mon, Jul 11, 2016 at 7:48 PM, Scott Stark <sstark(a)redhat.com> wrote:
[tmp 512]$ java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+126)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126, mixed mode)
You are using "wrong" b126, this is from main line, grab b126 jigsaw build
that was just published to
https://jdk9.java.net/jigsaw/
C:\development\tools\jdk\jdk-9\bin> ./java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+
126-2016-07-10-164835.javare.5266.nc)
Java HotSpot(TM) Client VM (build 9-ea+126-2016-07-10-164835.javare.5266.nc,
mixed mode)
2846
days inactive
2846
days old
6 comments
2 participants
participants (2)
-
Scott Stark -
Tomaž Cerar