From igor.nunes at eldorado.org.br Wed Nov 16 17:51:30 2016 From: igor.nunes at eldorado.org.br (Igor Henrique Soares Nunes) Date: Wed, 16 Nov 2016 17:51:30 +0000 Subject: Setting nativepath correctly Message-ID: <216ed07c1360457199b0e813e94cba85@serv030.corp.eldorado.org.br> Hi all, I'm currently working on openjdk9 (hs) and some of my tests are failing (error) because of wrong nativepath. See the following line: JT_JAVA=/usr/lib/jvm/java-8-openjdk-amd64/ jtreg-tip/bin/jtreg -agentvm -Xmx40m -conc:10 -va -a -ignore:quiet -w:test/hotspot/JTwork -r:test/hotspot/JTreport -jdk:./build/linux-x86_64-normal-server-release/jdk/ -timeout:3 ./hotspot/test/ In this first command nativepath is not being set. So that "./hotspot/test/runtime/StackGuardPages/testme.sh" fails because $TESTNATIVEPATH is empty, and also other ".java" (like "./hotspot/test/compiler/calls/TestDirtyInt.java") tests fail because a nativepath is being expected in -Dtest.nativepath. If I set nativepath to "-nativepath:./build/linux-ppc64le-normal-server-release/support/test/hotspot/jtreg/native/lib/", tests that expect a correct path in -Dtest.nativepath, start to pass. But "./hotspot/test/runtime/StackGuardPages/testme.sh" still fails. Otherwise, if I set nativepath to "-nativepath:./build/linux-ppc64le-normal-server-release/support/test/hotspot/jtreg/native/bin/", testme.sh passes but the others fail. How can I solve this? For now I am copying the "./build/linux-ppc64le-normal-server-release/support/test/hotspot/jtreg/native/bin" files to "./build/linux-ppc64le-normal-server-release/support/test/hotspot/jtreg/native/lib" so that I can set nativepath to "jtreg/native/lib". Regards, Igor Nunes From jonathan.gibbons at oracle.com Wed Nov 16 18:04:29 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Nov 2016 10:04:29 -0800 Subject: Setting nativepath correctly In-Reply-To: <216ed07c1360457199b0e813e94cba85@serv030.corp.eldorado.org.br> References: <216ed07c1360457199b0e813e94cba85@serv030.corp.eldorado.org.br> Message-ID: <12638e45-39d7-3f83-519d-ba81f7942bfe@oracle.com> On 11/16/16 9:51 AM, Igor Henrique Soares Nunes wrote: > Hi all, > > I'm currently working on openjdk9 (hs) and some of my tests are failing (error) because of wrong nativepath. > > See the following line: > JT_JAVA=/usr/lib/jvm/java-8-openjdk-amd64/ jtreg-tip/bin/jtreg -agentvm -Xmx40m -conc:10 -va -a -ignore:quiet -w:test/hotspot/JTwork -r:test/hotspot/JTreport -jdk:./build/linux-x86_64-normal-server-release/jdk/ -timeout:3 ./hotspot/test/ > > In this first command nativepath is not being set. So that "./hotspot/test/runtime/StackGuardPages/testme.sh" fails because $TESTNATIVEPATH is empty, and also other ".java" (like "./hotspot/test/compiler/calls/TestDirtyInt.java") tests fail because a nativepath is being expected in -Dtest.nativepath. > > If I set nativepath to "-nativepath:./build/linux-ppc64le-normal-server-release/support/test/hotspot/jtreg/native/lib/", tests that expect a correct path in -Dtest.nativepath, start to pass. But "./hotspot/test/runtime/StackGuardPages/testme.sh" still fails. > > Otherwise, if I set nativepath to "-nativepath:./build/linux-ppc64le-normal-server-release/support/test/hotspot/jtreg/native/bin/", testme.sh passes but the others fail. > > How can I solve this? For now I am copying the "./build/linux-ppc64le-normal-server-release/support/test/hotspot/jtreg/native/bin" files to "./build/linux-ppc64le-normal-server-release/support/test/hotspot/jtreg/native/lib" so that I can set nativepath to "jtreg/native/lib". > > Regards, > > Igor Nunes It sounds like a test bug if different tests require different settings for -nativepath. -- Jon From christoph.langer at sap.com Tue Nov 22 08:38:08 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 08:38:08 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") Message-ID: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> Hi, I'm currently struggling while running jtreg tests for the jaxp depot. There are several tests that fail with the same symptom. I always get exceptions like: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) at java.base/java.security.AccessController.checkPermission(AccessController.java:894) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:548) at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) at org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) at org.testng.internal.Parameters.handleParameters(Parameters.java:419) at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) at org.testng.internal.Invoker.createParameters(Invoker.java:989) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:782) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) 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 com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:224) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:188) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:537) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) For instance the test javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. It's calling "testng -DrunSecMngr=true" and obviously some important permission for testing is missing with that. I'm using most current jtreg (with testng-6.9.10.jar) Thanks for any help. Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Nov 22 09:08:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2016 09:08:03 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> Message-ID: <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Hi Christoph, Can you please ensure that your build of jtreg contains the fix for 7901792 [1]. 7901792 grants /lib/testng.jar all permissions. -Chris. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > On 22 Nov 2016, at 08:38, Langer, Christoph wrote: > > Hi, > > I'm currently struggling while running jtreg tests for the jaxp depot. > > There are several tests that fail with the same symptom. I always get exceptions like: > java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") > at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) > at java.base/java.security.AccessController.checkPermission(AccessController.java:894) > at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:548) > at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > at org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > at org.testng.internal.Parameters.handleParameters(Parameters.java:419) > at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > at org.testng.internal.Invoker.createParameters(Invoker.java:989) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > at org.testng.TestRunner.privateRun(TestRunner.java:782) > at org.testng.TestRunner.run(TestRunner.java:632) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > 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 com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:224) > at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:188) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:537) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.base/java.lang.Thread.run(Thread.java:844) > > For instance the test javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. > > It's calling "testng -DrunSecMngr=true" and obviously some important permission for testing is missing with that. > > I'm using most current jtreg (with testng-6.9.10.jar) > > > Thanks for any help. > > > Best regards > Christoph From christoph.langer at sap.com Tue Nov 22 09:43:13 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 09:43:13 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Hi Chris, thanks for this hint. However, we've already seen this change and rebuilt jtreg with the latest jtreg repo. But it doesn't change a thing. Also, the download from https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I would suppose latest jtreg sources were used, don't help. Am I missing something? Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Dienstag, 22. November 2016 10:08 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi Christoph, > > Can you please ensure that your build of jtreg contains the fix for 7901792 [1]. > 7901792 grants /lib/testng.jar all permissions. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > > > On 22 Nov 2016, at 08:38, Langer, Christoph > wrote: > > > > Hi, > > > > I'm currently struggling while running jtreg tests for the jaxp depot. > > > > There are several tests that fail with the same symptom. I always get > exceptions like: > > java.security.AccessControlException: access denied > ("java.lang.RuntimePermission" "accessDeclaredMembers") > > at > java.base/java.security.AccessControlContext.checkPermission(AccessControlCo > ntext.java:471) > > at > java.base/java.security.AccessController.checkPermission(AccessController.java > :894) > > at > java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 > 48) > > at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > > at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > > at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > > at > org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > > at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > > at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > > at > org.testng.internal.Parameters.handleParameters(Parameters.java:419) > > at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > > at org.testng.internal.Invoker.createParameters(Invoker.java:989) > > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. > java:129) > > at > org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > > at org.testng.TestRunner.privateRun(TestRunner.java:782) > > at org.testng.TestRunner.run(TestRunner.java:632) > > at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > > 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 > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > 224) > > at > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > 188) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > AccessorImpl.java:62) > > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin > gMethodAccessorImpl.java:43) > > at java.base/java.lang.reflect.Method.invoke(Method.java:537) > > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j > ava:110) > > at java.base/java.lang.Thread.run(Thread.java:844) > > > > For instance the test > javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. > > > > It's calling "testng -DrunSecMngr=true" and obviously some important > permission for testing is missing with that. > > > > I'm using most current jtreg (with testng-6.9.10.jar) > > > > > > Thanks for any help. > > > > > > Best regards > > Christoph From chris.hegarty at oracle.com Tue Nov 22 10:03:20 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2016 10:03:20 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: > On 22 Nov 2016, at 09:43, Langer, Christoph wrote: > > Hi Chris, > > thanks for this hint. However, we've already seen this change and rebuilt jtreg with the latest jtreg repo. But it doesn't change a thing. > > Also, the download from https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I would suppose latest jtreg sources were used, don't help. > > Am I missing something? Is it possible to post, or upload to cr.o.j.n, the jtr of the failing test? -Chris. > Best regards > Christoph > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Dienstag, 22. November 2016 10:08 >> To: Langer, Christoph >> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- >> use at openjdk.java.net >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >> "accessDeclaredMembers") >> >> Hi Christoph, >> >> Can you please ensure that your build of jtreg contains the fix for 7901792 [1]. >> 7901792 grants /lib/testng.jar all permissions. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >> >>> On 22 Nov 2016, at 08:38, Langer, Christoph >> wrote: >>> >>> Hi, >>> >>> I'm currently struggling while running jtreg tests for the jaxp depot. >>> >>> There are several tests that fail with the same symptom. I always get >> exceptions like: >>> java.security.AccessControlException: access denied >> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>> at >> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >> ntext.java:471) >>> at >> java.base/java.security.AccessController.checkPermission(AccessController.java >> :894) >>> at >> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >> 48) >>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>> at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>> at >> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>> at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>> at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>> at >> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>> at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>> at org.testng.internal.Invoker.createParameters(Invoker.java:989) >>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>> at >> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >> java:129) >>> at >> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>> at org.testng.TestRunner.run(TestRunner.java:632) >>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>> 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 >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >> 224) >>> at >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >> 188) >>> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >>> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >> AccessorImpl.java:62) >>> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >> gMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >> ava:110) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> >>> For instance the test >> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. >>> >>> It's calling "testng -DrunSecMngr=true" and obviously some important >> permission for testing is missing with that. >>> >>> I'm using most current jtreg (with testng-6.9.10.jar) >>> >>> >>> Thanks for any help. >>> >>> >>> Best regards >>> Christoph > From christoph.langer at sap.com Tue Nov 22 10:52:55 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 10:52:55 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Yes, please find it here: http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Dienstag, 22. November 2016 11:03 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > > > On 22 Nov 2016, at 09:43, Langer, Christoph > wrote: > > > > Hi Chris, > > > > thanks for this hint. However, we've already seen this change and rebuilt > jtreg with the latest jtreg repo. But it doesn't change a thing. > > > > Also, the download from https://adopt- > openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I would > suppose latest jtreg sources were used, don't help. > > > > Am I missing something? > > Is it possible to post, or upload to cr.o.j.n, the jtr of the failing test? > > -Chris. > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Dienstag, 22. November 2016 10:08 > >> To: Langer, Christoph > >> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- > >> use at openjdk.java.net > >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > >> "accessDeclaredMembers") > >> > >> Hi Christoph, > >> > >> Can you please ensure that your build of jtreg contains the fix for 7901792 > [1]. > >> 7901792 grants /lib/testng.jar all permissions. > >> > >> -Chris. > >> > >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > >> > >>> On 22 Nov 2016, at 08:38, Langer, Christoph > >> wrote: > >>> > >>> Hi, > >>> > >>> I'm currently struggling while running jtreg tests for the jaxp depot. > >>> > >>> There are several tests that fail with the same symptom. I always get > >> exceptions like: > >>> java.security.AccessControlException: access denied > >> ("java.lang.RuntimePermission" "accessDeclaredMembers") > >>> at > >> > java.base/java.security.AccessControlContext.checkPermission(AccessControlCo > >> ntext.java:471) > >>> at > >> > java.base/java.security.AccessController.checkPermission(AccessController.java > >> :894) > >>> at > >> > java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 > >> 48) > >>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > >>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > >>> at > org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > >>> at > >> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > >>> at > org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > >>> at > org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > >>> at > >> org.testng.internal.Parameters.handleParameters(Parameters.java:419) > >>> at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > >>> at org.testng.internal.Invoker.createParameters(Invoker.java:989) > >>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > >>> at > >> > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. > >> java:129) > >>> at > >> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > >>> at org.testng.TestRunner.privateRun(TestRunner.java:782) > >>> at org.testng.TestRunner.run(TestRunner.java:632) > >>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > >>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > >>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > >>> 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 > >> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >> 224) > >>> at > >> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >> 188) > >>> at > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >>> at > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > >> AccessorImpl.java:62) > >>> at > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin > >> gMethodAccessorImpl.java:43) > >>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) > >>> at > >> > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j > >> ava:110) > >>> at java.base/java.lang.Thread.run(Thread.java:844) > >>> > >>> For instance the test > >> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. > >>> > >>> It's calling "testng -DrunSecMngr=true" and obviously some important > >> permission for testing is missing with that. > >>> > >>> I'm using most current jtreg (with testng-6.9.10.jar) > >>> > >>> > >>> Thanks for any help. > >>> > >>> > >>> Best regards > >>> Christoph > > From christoph.langer at sap.com Tue Nov 22 11:33:11 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 11:33:11 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: <928722e31ddb4d20a8a15906d01d5c92@DEWDFE13DE03.global.corp.sap> Hi Daniel, I checked your suggestion with the paths and moved my jtreg to a local disk - but nothing changed. I don't see any policy that is being manipulated. I found out, by adding some debug printing code, that inside jtreg, the addGrantEntry() method is not called at all... Is some policy file missing? Thanks Christoph > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Dienstag, 22. November 2016 12:25 > To: Langer, Christoph ; Chris Hegarty > > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi Christoph, > > Is there anything funny with the place jtreg is installed? > like: > - path contains whitespaces > - path is accessible through links or mount points... > > It seems clear that the issue here is that testng classes are > missing some permissions, so I was wondering whether that could > be caused by the actual path to testng.jar not matching the > path injected in the policy file. > > I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: > > $ cd jaxp/tests > $ rm -r JT* > $ jtreg -verbose:summary -ignore:quiet -jdk > ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ > > => the only test that fails is > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's > expected (it's in the ProblemList.txt). > > The other thing to take care of, is not to run two jtreg process > concurrently if they point to the same JT* directories. If you do > that then you might experience weird failures with permissions > issues (it seems to mess the policy files). > > best regards, > > -- daniel > > On 22/11/16 10:52, Langer, Christoph wrote: > > Yes, please find it here: > http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr > > > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Dienstag, 22. November 2016 11:03 > >> To: Langer, Christoph > >> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- > >> use at openjdk.java.net > >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > >> "accessDeclaredMembers") > >> > >> > >>> On 22 Nov 2016, at 09:43, Langer, Christoph > >> wrote: > >>> > >>> Hi Chris, > >>> > >>> thanks for this hint. However, we've already seen this change and rebuilt > >> jtreg with the latest jtreg repo. But it doesn't change a thing. > >>> > >>> Also, the download from https://adopt- > >> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I > would > >> suppose latest jtreg sources were used, don't help. > >>> > >>> Am I missing something? > >> > >> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing test? > >> > >> -Chris. > >> > >>> Best regards > >>> Christoph > >>> > >>>> -----Original Message----- > >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >>>> Sent: Dienstag, 22. November 2016 10:08 > >>>> To: Langer, Christoph > >>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; > jtreg- > >>>> use at openjdk.java.net > >>>> Subject: Re: Issues running JAXP jtreg tests > ("java.lang.RuntimePermission" > >>>> "accessDeclaredMembers") > >>>> > >>>> Hi Christoph, > >>>> > >>>> Can you please ensure that your build of jtreg contains the fix for 7901792 > >> [1]. > >>>> 7901792 grants /lib/testng.jar all permissions. > >>>> > >>>> -Chris. > >>>> > >>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > >>>> > >>>>> On 22 Nov 2016, at 08:38, Langer, Christoph > > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I'm currently struggling while running jtreg tests for the jaxp depot. > >>>>> > >>>>> There are several tests that fail with the same symptom. I always get > >>>> exceptions like: > >>>>> java.security.AccessControlException: access denied > >>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") > >>>>> at > >>>> > >> > java.base/java.security.AccessControlContext.checkPermission(AccessControlCo > >>>> ntext.java:471) > >>>>> at > >>>> > >> > java.base/java.security.AccessController.checkPermission(AccessController.java > >>>> :894) > >>>>> at > >>>> > >> > java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 > >>>> 48) > >>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > >>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > >>>>> at > >> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > >>>>> at > >>>> > org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > >>>>> at > >> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > >>>>> at > >> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > >>>>> at > >>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) > >>>>> at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > >>>>> at org.testng.internal.Invoker.createParameters(Invoker.java:989) > >>>>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > >>>>> at > >>>> > >> > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. > >>>> java:129) > >>>>> at > >>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > >>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) > >>>>> at org.testng.TestRunner.run(TestRunner.java:632) > >>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > >>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > >>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > >>>>> 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 > >>>> > >> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >>>> 224) > >>>>> at > >>>> > >> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >>>> 188) > >>>>> at > >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >>>> Method) > >>>>> at > >>>> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > >>>> AccessorImpl.java:62) > >>>>> at > >>>> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin > >>>> gMethodAccessorImpl.java:43) > >>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) > >>>>> at > >>>> > >> > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j > >>>> ava:110) > >>>>> at java.base/java.lang.Thread.run(Thread.java:844) > >>>>> > >>>>> For instance the test > >>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. > >>>>> > >>>>> It's calling "testng -DrunSecMngr=true" and obviously some important > >>>> permission for testing is missing with that. > >>>>> > >>>>> I'm using most current jtreg (with testng-6.9.10.jar) > >>>>> > >>>>> > >>>>> Thanks for any help. > >>>>> > >>>>> > >>>>> Best regards > >>>>> Christoph > >>> > > From volker.simonis at gmail.com Tue Nov 22 12:13:42 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Nov 2016 13:13:42 +0100 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Hi Daniel, thanks for your support - this problem really drives us crazy! What version of jtreg are you using? If you are using a central one which was configured and build by Oracle, could you please also try with the one from https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ ? Where can we find the generated policy files? It seems they get deleted during test post-run cleanup phase (at least I could not find any of them under JTwork). Is there a way to get a more detailed trace on how JTreg executes testng and to leave all the generated files in place after the test? I'm currently running the following JAXP test and get the same error as described by Christoph: /tmp/jtreg/bin/jtreg -verbose:summary -jdk /output-jdk9-hs-dbg/images/jdk/ /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java What I don't really understand is how this is supposed to work at all, because every JAXP test which runs with "-DrunSecMngr=true" will execute the following code from JAXPPolicyManager: /* * Install a SecurityManager along with a default Policy to allow testNG to * run when there is a security manager. */ private JAXPPolicyManager() { // Backing up policy and security manager for restore policyBackup = Policy.getPolicy(); smBackup = System.getSecurityManager(); // Set customized policy setDefaultPermissions(); Policy.setPolicy(policy); System.setSecurityManager(new SecurityManager()); } Won't this code override the settings from the policy file which was potentially installed by jtreg for testng? The setDefaultPermissions() sets some special permissions for testng, but not "accessDeclaredMembers": private void setDefaultPermissions() { //Permissions to set security manager and policy addPermission(new SecurityPermission("getPolicy")); addPermission(new SecurityPermission("setPolicy")); addPermission(new RuntimePermission("setSecurityManager")); //Properties that jtreg and TestNG require addPermission(new PropertyPermission("testng.show.stack.frames", "read")); addPermission(new PropertyPermission("test.src", "read")); addPermission(new PropertyPermission("test.classes", "read")); addPermission(new PropertyPermission("dataproviderthreadcount", "read")); addPermission(new PropertyPermission("experimental", "read")); } If I add the line: addPermission(new RuntimePermission("accessDeclaredMembers")); to setDefaultPermissions(), the test will succeed. I saw that an early version of "JDK-8067170: Enable security manager on JAXP unit tests" contained that extra permission, but you objected (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042520.html) and it was removed in the final version. Any more hints? Thanks, Volker On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs wrote: > Hi Christoph, > > Is there anything funny with the place jtreg is installed? > like: > - path contains whitespaces > - path is accessible through links or mount points... > > It seems clear that the issue here is that testng classes are > missing some permissions, so I was wondering whether that could > be caused by the actual path to testng.jar not matching the > path injected in the policy file. > > I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: > > $ cd jaxp/tests > $ rm -r JT* > $ jtreg -verbose:summary -ignore:quiet -jdk > ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ > > => the only test that fails is > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's expected > (it's in the ProblemList.txt). > > The other thing to take care of, is not to run two jtreg process > concurrently if they point to the same JT* directories. If you do > that then you might experience weird failures with permissions > issues (it seems to mess the policy files). > > best regards, > > -- daniel > > > On 22/11/16 10:52, Langer, Christoph wrote: >> >> Yes, please find it here: >> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >> >> >>> -----Original Message----- >>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>> Sent: Dienstag, 22. November 2016 11:03 >>> To: Langer, Christoph >>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>> jtreg- >>> use at openjdk.java.net >>> Subject: Re: Issues running JAXP jtreg tests >>> ("java.lang.RuntimePermission" >>> "accessDeclaredMembers") >>> >>> >>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>> >>> wrote: >>>> >>>> >>>> Hi Chris, >>>> >>>> thanks for this hint. However, we've already seen this change and >>>> rebuilt >>> >>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>> >>>> >>>> Also, the download from https://adopt- >>> >>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I >>> would >>> suppose latest jtreg sources were used, don't help. >>>> >>>> >>>> Am I missing something? >>> >>> >>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>> test? >>> >>> -Chris. >>> >>>> Best regards >>>> Christoph >>>> >>>>> -----Original Message----- >>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>> To: Langer, Christoph >>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>> jtreg- >>>>> use at openjdk.java.net >>>>> Subject: Re: Issues running JAXP jtreg tests >>>>> ("java.lang.RuntimePermission" >>>>> "accessDeclaredMembers") >>>>> >>>>> Hi Christoph, >>>>> >>>>> Can you please ensure that your build of jtreg contains the fix for >>>>> 7901792 >>> >>> [1]. >>>>> >>>>> 7901792 grants /lib/testng.jar all permissions. >>>>> >>>>> -Chris. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>> >>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm currently struggling while running jtreg tests for the jaxp depot. >>>>>> >>>>>> There are several tests that fail with the same symptom. I always get >>>>> >>>>> exceptions like: >>>>>> >>>>>> java.security.AccessControlException: access denied >>>>> >>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>> >>>>> ntext.java:471) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>> >>>>> :894) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>> >>>>> 48) >>>>>> >>>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>> at >>> >>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>> >>>>>> at >>>>> >>>>> >>>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>> >>>>>> at >>> >>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>> >>>>>> at >>> >>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>> >>>>>> at >>>>> >>>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>> >>>>>> at >>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>> at >>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>> at >>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>> at >>>>> >>>>> >>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>> >>>>> java:129) >>>>>> >>>>>> at >>>>> >>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>> >>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>> 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 >>>>> >>>>> >>> >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>> >>>>> 224) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>> >>>>> 188) >>>>>> >>>>>> at >>>>> >>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>> Method) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>> >>>>> AccessorImpl.java:62) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>> >>>>> gMethodAccessorImpl.java:43) >>>>>> >>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>> at >>>>> >>>>> >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>> >>>>> ava:110) >>>>>> >>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>> >>>>>> For instance the test >>>>> >>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>> this. >>>>>> >>>>>> >>>>>> It's calling "testng -DrunSecMngr=true" and obviously some important >>>>> >>>>> permission for testing is missing with that. >>>>>> >>>>>> >>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>> >>>>>> >>>>>> Thanks for any help. >>>>>> >>>>>> >>>>>> Best regards >>>>>> Christoph >>>> >>>> >> > From chris.hegarty at oracle.com Tue Nov 22 12:25:16 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2016 12:25:16 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Volker, Just to add, jtreg has support in its tags to start the test VM with a security manager and a specified policy. In the case of the test failure you are seeing, the built-in jtreg support is not being used. Instead, the test is executing with a test-specific system property that is being used to trigger the programatic setting of a security manager with a generated policy. I think this explains why you are not seeing any policy file in the JTwork directory. What is odd is that the stack trace you are seeing appears to be before the test?s main entry point, so I would not expect to the security manager to be active at this point ( since no test code has run ). My previous comment regarding 7901792 is not relevant since it relates to tests executing with a security manager set through jtreg tags. Is there anything in the environment that could trigger the VM to start up with a security manager enabled? -Chris. > On 22 Nov 2016, at 12:13, Volker Simonis wrote: > > Hi Daniel, > > thanks for your support - this problem really drives us crazy! > > What version of jtreg are you using? > If you are using a central one which was configured and build by > Oracle, could you please also try with the one from > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > ? > > Where can we find the generated policy files? It seems they get > deleted during test post-run cleanup phase (at least I could not find > any of them under JTwork). Is there a way to get a more detailed trace > on how JTreg executes testng and to leave all the generated files in > place after the test? > > I'm currently running the following JAXP test and get the same error > as described by Christoph: > > /tmp/jtreg/bin/jtreg -verbose:summary -jdk > /output-jdk9-hs-dbg/images/jdk/ > /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java > > What I don't really understand is how this is supposed to work at all, > because every JAXP test which runs with "-DrunSecMngr=true" will > execute the following code from JAXPPolicyManager: > > /* > * Install a SecurityManager along with a default Policy to allow testNG to > * run when there is a security manager. > */ > private JAXPPolicyManager() { > // Backing up policy and security manager for restore > policyBackup = Policy.getPolicy(); > smBackup = System.getSecurityManager(); > > // Set customized policy > setDefaultPermissions(); > Policy.setPolicy(policy); > System.setSecurityManager(new SecurityManager()); > } > > Won't this code override the settings from the policy file which was > potentially installed by jtreg for testng? > > The setDefaultPermissions() sets some special permissions for testng, > but not "accessDeclaredMembers": > > private void setDefaultPermissions() { > //Permissions to set security manager and policy > addPermission(new SecurityPermission("getPolicy")); > addPermission(new SecurityPermission("setPolicy")); > addPermission(new RuntimePermission("setSecurityManager")); > //Properties that jtreg and TestNG require > addPermission(new > PropertyPermission("testng.show.stack.frames", "read")); > addPermission(new PropertyPermission("test.src", "read")); > addPermission(new PropertyPermission("test.classes", "read")); > addPermission(new > PropertyPermission("dataproviderthreadcount", "read")); > addPermission(new PropertyPermission("experimental", "read")); > } > > If I add the line: > > addPermission(new RuntimePermission("accessDeclaredMembers")); > > to setDefaultPermissions(), the test will succeed. > > I saw that an early version of "JDK-8067170: Enable security manager > on JAXP unit tests" contained that extra permission, but you objected > (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042520.html) > and it was removed in the final version. > > Any more hints? > > Thanks, > Volker > > > On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs wrote: >> Hi Christoph, >> >> Is there anything funny with the place jtreg is installed? >> like: >> - path contains whitespaces >> - path is accessible through links or mount points... >> >> It seems clear that the issue here is that testng classes are >> missing some permissions, so I was wondering whether that could >> be caused by the actual path to testng.jar not matching the >> path injected in the policy file. >> >> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >> >> $ cd jaxp/tests >> $ rm -r JT* >> $ jtreg -verbose:summary -ignore:quiet -jdk >> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >> >> => the only test that fails is >> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's expected >> (it's in the ProblemList.txt). >> >> The other thing to take care of, is not to run two jtreg process >> concurrently if they point to the same JT* directories. If you do >> that then you might experience weird failures with permissions >> issues (it seems to mess the policy files). >> >> best regards, >> >> -- daniel >> >> >> On 22/11/16 10:52, Langer, Christoph wrote: >>> >>> Yes, please find it here: >>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>> >>> >>>> -----Original Message----- >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>> Sent: Dienstag, 22. November 2016 11:03 >>>> To: Langer, Christoph >>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>> jtreg- >>>> use at openjdk.java.net >>>> Subject: Re: Issues running JAXP jtreg tests >>>> ("java.lang.RuntimePermission" >>>> "accessDeclaredMembers") >>>> >>>> >>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>> >>>> wrote: >>>>> >>>>> >>>>> Hi Chris, >>>>> >>>>> thanks for this hint. However, we've already seen this change and >>>>> rebuilt >>>> >>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>> >>>>> >>>>> Also, the download from https://adopt- >>>> >>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I >>>> would >>>> suppose latest jtreg sources were used, don't help. >>>>> >>>>> >>>>> Am I missing something? >>>> >>>> >>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>>> test? >>>> >>>> -Chris. >>>> >>>>> Best regards >>>>> Christoph >>>>> >>>>>> -----Original Message----- >>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>> To: Langer, Christoph >>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>>> jtreg- >>>>>> use at openjdk.java.net >>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>> ("java.lang.RuntimePermission" >>>>>> "accessDeclaredMembers") >>>>>> >>>>>> Hi Christoph, >>>>>> >>>>>> Can you please ensure that your build of jtreg contains the fix for >>>>>> 7901792 >>>> >>>> [1]. >>>>>> >>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>> >>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm currently struggling while running jtreg tests for the jaxp depot. >>>>>>> >>>>>>> There are several tests that fail with the same symptom. I always get >>>>>> >>>>>> exceptions like: >>>>>>> >>>>>>> java.security.AccessControlException: access denied >>>>>> >>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>> >>>>>> ntext.java:471) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>> >>>>>> :894) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>> >>>>>> 48) >>>>>>> >>>>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>> at >>>> >>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>> >>>>>>> at >>>> >>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>> >>>>>>> at >>>> >>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>> >>>>>>> at >>>>>> >>>>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>> >>>>>>> at >>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>> at >>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>> at >>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>> at >>>>>> >>>>>> >>>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>> >>>>>> java:129) >>>>>>> >>>>>>> at >>>>>> >>>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>> >>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>> 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 >>>>>> >>>>>> >>>> >>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>> >>>>>> 224) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>> >>>>>> 188) >>>>>>> >>>>>>> at >>>>>> >>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>> Method) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>> >>>>>> AccessorImpl.java:62) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>> >>>>>> gMethodAccessorImpl.java:43) >>>>>>> >>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>> at >>>>>> >>>>>> >>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>> >>>>>> ava:110) >>>>>>> >>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>> >>>>>>> For instance the test >>>>>> >>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>>> this. >>>>>>> >>>>>>> >>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some important >>>>>> >>>>>> permission for testing is missing with that. >>>>>>> >>>>>>> >>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>> >>>>>>> >>>>>>> Thanks for any help. >>>>>>> >>>>>>> >>>>>>> Best regards >>>>>>> Christoph >>>>> >>>>> >>> >> From christoph.langer at sap.com Tue Nov 22 13:01:02 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 13:01:02 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> Message-ID: <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Hi, we are running jtreg with something like -jdk:/images/jdk. So would that be the exploded version or not? FWIW: I think all test that fail don't have void test methods but the test methods expect input parameters and hence a tag @Test(dataProvider = "...") exists. Can it be that we are using a testng framework that is "too new" and maybe contains something which makes it not work in the jaxp scenario? Best, Christoph > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Dienstag, 22. November 2016 13:42 > To: Volker Simonis ; Langer, Christoph > ; Langer, Christoph > Cc: Chris Hegarty ; code-tools- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi guys, > > Are you running the tests with the exploded jdk or with the image? > > I'm seeing failures with the exploded jdk. > > That could explain the difference with permission checks. > > best regards, > > -- daniel > > > On 22/11/16 12:32, Daniel Fuchs wrote: > > Hi Volker, > > > > On 22/11/16 12:25, Chris Hegarty wrote: > >> Volker, > >> > >> Just to add, jtreg has support in its tags to start the test VM with a > >> security manager and a specified policy. In the case of the test failure > >> you are seeing, the built-in jtreg support is not being used. Instead, > >> the test is executing with a test-specific system property that is being > >> used to trigger the programatic setting of a security manager with a > >> generated policy. I think this explains why you are not seeing any > >> policy file in the JTwork directory. > >> > >> What is odd is that the stack trace you are seeing appears to be > >> before the test?s main entry point, so I would not expect to the > >> security manager to be active at this point ( since no test code > >> has run ). My previous comment regarding 7901792 is not relevant > >> since it relates to tests executing with a security manager set > >> through jtreg tags. > > > > I agree with Chris - I believe CODETOOLS-7901792 was a red herring. > > I'm going to try the jtreg you pointed at and see if there's any > > difference (I'm using jtreg 4.2 fcs b03). > > > >> Is there anything in the environment that could trigger the VM > >> to start up with a security manager enabled? > > > > This is a good question. > > > > best regards, > > > > -- daniel > > > >> > >> -Chris. > >> > >>> On 22 Nov 2016, at 12:13, Volker Simonis > >>> wrote: > >>> > >>> Hi Daniel, > >>> > >>> thanks for your support - this problem really drives us crazy! > >>> > >>> What version of jtreg are you using? > >>> If you are using a central one which was configured and build by > >>> Oracle, could you please also try with the one from > >>> https://adopt- > openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > >>> > >>> ? > >>> > >>> Where can we find the generated policy files? It seems they get > >>> deleted during test post-run cleanup phase (at least I could not find > >>> any of them under JTwork). Is there a way to get a more detailed trace > >>> on how JTreg executes testng and to leave all the generated files in > >>> place after the test? > >>> > >>> I'm currently running the following JAXP test and get the same error > >>> as described by Christoph: > >>> > >>> /tmp/jtreg/bin/jtreg -verbose:summary -jdk > >>> /output-jdk9-hs-dbg/images/jdk/ > >>> /OpenJDK/jdk9- > hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jav > a > >>> > >>> > >>> What I don't really understand is how this is supposed to work at all, > >>> because every JAXP test which runs with "-DrunSecMngr=true" will > >>> execute the following code from JAXPPolicyManager: > >>> > >>> /* > >>> * Install a SecurityManager along with a default Policy to allow > >>> testNG to > >>> * run when there is a security manager. > >>> */ > >>> private JAXPPolicyManager() { > >>> // Backing up policy and security manager for restore > >>> policyBackup = Policy.getPolicy(); > >>> smBackup = System.getSecurityManager(); > >>> > >>> // Set customized policy > >>> setDefaultPermissions(); > >>> Policy.setPolicy(policy); > >>> System.setSecurityManager(new SecurityManager()); > >>> } > >>> > >>> Won't this code override the settings from the policy file which was > >>> potentially installed by jtreg for testng? > >>> > >>> The setDefaultPermissions() sets some special permissions for testng, > >>> but not "accessDeclaredMembers": > >>> > >>> private void setDefaultPermissions() { > >>> //Permissions to set security manager and policy > >>> addPermission(new SecurityPermission("getPolicy")); > >>> addPermission(new SecurityPermission("setPolicy")); > >>> addPermission(new RuntimePermission("setSecurityManager")); > >>> //Properties that jtreg and TestNG require > >>> addPermission(new > >>> PropertyPermission("testng.show.stack.frames", "read")); > >>> addPermission(new PropertyPermission("test.src", "read")); > >>> addPermission(new PropertyPermission("test.classes", "read")); > >>> addPermission(new > >>> PropertyPermission("dataproviderthreadcount", "read")); > >>> addPermission(new PropertyPermission("experimental", "read")); > >>> } > >>> > >>> If I add the line: > >>> > >>> addPermission(new RuntimePermission("accessDeclaredMembers")); > >>> > >>> to setDefaultPermissions(), the test will succeed. > >>> > >>> I saw that an early version of "JDK-8067170: Enable security manager > >>> on JAXP unit tests" contained that extra permission, but you objected > >>> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- > July/042520.html) > >>> > >>> and it was removed in the final version. > >>> > >>> Any more hints? > >>> > >>> Thanks, > >>> Volker > >>> > >>> > >>> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs > >>> wrote: > >>>> Hi Christoph, > >>>> > >>>> Is there anything funny with the place jtreg is installed? > >>>> like: > >>>> - path contains whitespaces > >>>> - path is accessible through links or mount points... > >>>> > >>>> It seems clear that the issue here is that testng classes are > >>>> missing some permissions, so I was wondering whether that could > >>>> be caused by the actual path to testng.jar not matching the > >>>> path injected in the policy file. > >>>> > >>>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: > >>>> > >>>> $ cd jaxp/tests > >>>> $ rm -r JT* > >>>> $ jtreg -verbose:summary -ignore:quiet -jdk > >>>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ > >>>> > >>>> => the only test that fails is > >>>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's > >>>> expected > >>>> (it's in the ProblemList.txt). > >>>> > >>>> The other thing to take care of, is not to run two jtreg process > >>>> concurrently if they point to the same JT* directories. If you do > >>>> that then you might experience weird failures with permissions > >>>> issues (it seems to mess the policy files). > >>>> > >>>> best regards, > >>>> > >>>> -- daniel > >>>> > >>>> > >>>> On 22/11/16 10:52, Langer, Christoph wrote: > >>>>> > >>>>> Yes, please find it here: > >>>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >>>>>> Sent: Dienstag, 22. November 2016 11:03 > >>>>>> To: Langer, Christoph > >>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; > >>>>>> jtreg- > >>>>>> use at openjdk.java.net > >>>>>> Subject: Re: Issues running JAXP jtreg tests > >>>>>> ("java.lang.RuntimePermission" > >>>>>> "accessDeclaredMembers") > >>>>>> > >>>>>> > >>>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph > >>>>>>> > >>>>>> > >>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> Hi Chris, > >>>>>>> > >>>>>>> thanks for this hint. However, we've already seen this change and > >>>>>>> rebuilt > >>>>>> > >>>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. > >>>>>>> > >>>>>>> > >>>>>>> Also, the download from https://adopt- > >>>>>> > >>>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > >>>>>> where I > >>>>>> would > >>>>>> suppose latest jtreg sources were used, don't help. > >>>>>>> > >>>>>>> > >>>>>>> Am I missing something? > >>>>>> > >>>>>> > >>>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing > >>>>>> test? > >>>>>> > >>>>>> -Chris. > >>>>>> > >>>>>>> Best regards > >>>>>>> Christoph > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >>>>>>>> Sent: Dienstag, 22. November 2016 10:08 > >>>>>>>> To: Langer, Christoph > >>>>>>>> Cc: core-libs-dev at openjdk.java.net; > >>>>>>>> code-tools-dev at openjdk.java.net; > >>>>>>>> jtreg- > >>>>>>>> use at openjdk.java.net > >>>>>>>> Subject: Re: Issues running JAXP jtreg tests > >>>>>>>> ("java.lang.RuntimePermission" > >>>>>>>> "accessDeclaredMembers") > >>>>>>>> > >>>>>>>> Hi Christoph, > >>>>>>>> > >>>>>>>> Can you please ensure that your build of jtreg contains the fix for > >>>>>>>> 7901792 > >>>>>> > >>>>>> [1]. > >>>>>>>> > >>>>>>>> 7901792 grants /lib/testng.jar all permissions. > >>>>>>>> > >>>>>>>> -Chris. > >>>>>>>> > >>>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > >>>>>>>> > >>>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph > >>>>>>>>> > >>>>>>>> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I'm currently struggling while running jtreg tests for the jaxp > >>>>>>>>> depot. > >>>>>>>>> > >>>>>>>>> There are several tests that fail with the same symptom. I > >>>>>>>>> always get > >>>>>>>> > >>>>>>>> exceptions like: > >>>>>>>>> > >>>>>>>>> java.security.AccessControlException: access denied > >>>>>>>> > >>>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/java.security.AccessControlContext.checkPermission(AccessControlCo > >>>>>> > >>>>>>>> > >>>>>>>> ntext.java:471) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/java.security.AccessController.checkPermission(AccessController.java > >>>>>> > >>>>>>>> > >>>>>>>> :894) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 > >>>>>> > >>>>>>>> > >>>>>>>> 48) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>>> java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > >>>>>>>>> at > >>>>>>>>> java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > >>>>>>>>> at > >>>>>> > >>>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>>>> > org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > >>>>>>>> > >>>>>>>>> > >>>>>>>>> at > >>>>>> > >>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > >>>>>>>>> > >>>>>>>>> at > >>>>>> > >>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > org.testng.internal.Parameters.handleParameters(Parameters.java:419) > >>>>>>>> > >>>>>>>>> > >>>>>>>>> at > >>>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > >>>>>>>>> at > >>>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) > >>>>>>>>> at > >>>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. > >>>>>> > >>>>>>>> > >>>>>>>> java:129) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > >>>>>>>>> > >>>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) > >>>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) > >>>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > >>>>>>>>> at > >>>>>>>>> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > >>>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > >>>>>>>>> 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 > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >>>>>> > >>>>>>>> > >>>>>>>> 224) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >>>>>> > >>>>>>>> > >>>>>>>> 188) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >>>>>>>> > >>>>>>>> Method) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > >>>>>> > >>>>>>>> > >>>>>>>> AccessorImpl.java:62) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin > >>>>>> > >>>>>>>> > >>>>>>>> gMethodAccessorImpl.java:43) > >>>>>>>>> > >>>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j > >>>>>> > >>>>>>>> > >>>>>>>> ava:110) > >>>>>>>>> > >>>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) > >>>>>>>>> > >>>>>>>>> For instance the test > >>>>>>>> > >>>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like > >>>>>>>> this. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some > >>>>>>>>> important > >>>>>>>> > >>>>>>>> permission for testing is missing with that. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks for any help. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Best regards > >>>>>>>>> Christoph > >>>>>>> > >>>>>>> > >>>>> > >>>> > >> > > From volker.simonis at gmail.com Tue Nov 22 14:31:58 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Nov 2016 15:31:58 +0100 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: On Tue, Nov 22, 2016 at 2:31 PM, Daniel Fuchs wrote: > On 22/11/16 13:01, Langer, Christoph wrote: >> >> Hi, >> >> we are running jtreg with something like -jdk:> directory>/images/jdk. So would that be the exploded version or not? > > > Yes - that's the image. Hmm... The failures I see with the exploded > build are different than what you have anyway. > >> FWIW: I think all test that fail don't have void test methods but the test >> methods expect input parameters and hence a tag @Test(dataProvider = "...") >> exists. > > > Good observation. > >> Can it be that we are using a testng framework that is "too new" and maybe >> contains something which makes it not work in the jaxp scenario? > > > When I call jtreg -version it reports: > TestNG: version 6.9.5 > > This seems different to what you are using. > Can you try with > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz > without altering the version of testng? > > I had no problem running the tests with that version > of testng (except if I use the exploded build). > Sorry, but I can't believe that :) Are you really sure you used exact that version for testing? I'm just asking because I get the same failure with that version as well: /tmp/jtreg/bin/jtreg -version jtreg, version 4.2 dev b03 Installed in /tmp/jtreg/lib/jtreg.jar Running on platform version 1.8.0-internal from /net/usr.work/openjdk/nb/linuxx86_64/last_known_good/output-jdk8/images/j2sdk-image/jre. Built with 1.8.0_60 on 11/21/2016 01:47 PM. Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. JCov 2.0-1 TestNG (testng.jar): version 6.9.11 TestNG (jcommander.jar): version unknown /tmp/jtreg/bin/jtreg -verbose:summary -jdk /output-jdk9-hs-dbg/images/jdk/ /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java FAILED: javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java Test results: failed: 1 cat JTwork/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jtr ... javatestVersion=4.6 jtregVersion=jtreg 4.2 dev b03 #section:testng ----------messages:(4/240)---------- command: testng -DrunSecMngr=true catalog.CatalogReferCircularityTest reason: User specified action: run testng/othervm -DrunSecMngr=true catalog.CatalogReferCircularityTest Mode: othervm [/othervm specified] elapsed time (seconds): 4.407 ----------configuration:(0/0)---------- ----------System.out:(46/2950)---------- [TestNG] Running: javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java test catalog.CatalogReferCircularityTest.testReferCircularity(): skip java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) at java.base/java.security.AccessController.checkPermission(AccessController.java:894) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:548) at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) at org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) at org.testng.internal.Parameters.handleParameters(Parameters.java:419) at org.testng.internal.Invoker.handleParameters(Invoker.java:1243) at org.testng.internal.Invoker.createParameters(Invoker.java:992) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1082) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) 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:1225) at org.testng.TestNG.runSuitesLocally(TestNG.java:1150) at org.testng.TestNG.runSuites(TestNG.java:1075) at org.testng.TestNG.run(TestNG.java:1047) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:184) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:537) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) > Maybe the listener that the test uses to set up the security > manager is invoked in a different way (earlier?) with the > 6.9.10 version? > I'm pretty sure now that the error is related to the testng version! I've rebuild our local jtreg with testng 9.5 (the same one you're using and the version which is recommended on the "Building jtreg" page at http://openjdk.java.net/jtreg/build.html. Unfortunately, that's not so easy, because testng-6.9.5.jar from maven-central is badly compiled to contain Java 8 classes (i.e. classes with major version 52). But this breaks the jtreg build because it generates (and expects) Java 7 classes. If I set JDK17HOME to point to a Java 8 jdk, the build succeeds and the resulting jtreg (with testng-6.9.5.jar) successfully executes the test mentioned before. Unfortunately we can't use such a version of jtreg with Java 7 anymore :( After I've verified that testng-6.9.5.jar is indeed working, I've also checked with the latest testng-6.9.13.6.jar from maven-central and it still breaks the tests. So somwhere between testng 9.5 and 9.10 testng was changed in a way which breaks some of the testng/jtreg tests. I'm currently investigating if this is a general testng/jdk9 problem or a problem which can be fixed or worked-around in jtreg. @Daniel: can I please kindly ask you to retry your tests with https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz and make sure you are really using that version. If you really succeed to successfully execute javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jtr with that version I would be pretty surprised (and speechless :) Thanks, Volker > best regards, > > -- daniel > > >> >> Best, >> Christoph >> >>> -----Original Message----- >>> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] >>> Sent: Dienstag, 22. November 2016 13:42 >>> To: Volker Simonis ; Langer, Christoph >>> ; Langer, Christoph >>> Cc: Chris Hegarty ; code-tools- >>> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- >>> use at openjdk.java.net >>> Subject: Re: Issues running JAXP jtreg tests >>> ("java.lang.RuntimePermission" >>> "accessDeclaredMembers") >>> >>> Hi guys, >>> >>> Are you running the tests with the exploded jdk or with the image? >>> >>> I'm seeing failures with the exploded jdk. >>> >>> That could explain the difference with permission checks. >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 22/11/16 12:32, Daniel Fuchs wrote: >>>> >>>> Hi Volker, >>>> >>>> On 22/11/16 12:25, Chris Hegarty wrote: >>>>> >>>>> Volker, >>>>> >>>>> Just to add, jtreg has support in its tags to start the test VM with a >>>>> security manager and a specified policy. In the case of the test >>>>> failure >>>>> you are seeing, the built-in jtreg support is not being used. Instead, >>>>> the test is executing with a test-specific system property that is >>>>> being >>>>> used to trigger the programatic setting of a security manager with a >>>>> generated policy. I think this explains why you are not seeing any >>>>> policy file in the JTwork directory. >>>>> >>>>> What is odd is that the stack trace you are seeing appears to be >>>>> before the test?s main entry point, so I would not expect to the >>>>> security manager to be active at this point ( since no test code >>>>> has run ). My previous comment regarding 7901792 is not relevant >>>>> since it relates to tests executing with a security manager set >>>>> through jtreg tags. >>>> >>>> >>>> I agree with Chris - I believe CODETOOLS-7901792 was a red herring. >>>> I'm going to try the jtreg you pointed at and see if there's any >>>> difference (I'm using jtreg 4.2 fcs b03). >>>> >>>>> Is there anything in the environment that could trigger the VM >>>>> to start up with a security manager enabled? >>>> >>>> >>>> This is a good question. >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>>> >>>>> -Chris. >>>>> >>>>>> On 22 Nov 2016, at 12:13, Volker Simonis >>>>>> wrote: >>>>>> >>>>>> Hi Daniel, >>>>>> >>>>>> thanks for your support - this problem really drives us crazy! >>>>>> >>>>>> What version of jtreg are you using? >>>>>> If you are using a central one which was configured and build by >>>>>> Oracle, could you please also try with the one from >>>>>> https://adopt- >>> >>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>>> >>>>>> >>>>>> ? >>>>>> >>>>>> Where can we find the generated policy files? It seems they get >>>>>> deleted during test post-run cleanup phase (at least I could not find >>>>>> any of them under JTwork). Is there a way to get a more detailed trace >>>>>> on how JTreg executes testng and to leave all the generated files in >>>>>> place after the test? >>>>>> >>>>>> I'm currently running the following JAXP test and get the same error >>>>>> as described by Christoph: >>>>>> >>>>>> /tmp/jtreg/bin/jtreg -verbose:summary -jdk >>>>>> /output-jdk9-hs-dbg/images/jdk/ >>>>>> /OpenJDK/jdk9- >>> >>> >>> hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jav >>> a >>>>>> >>>>>> >>>>>> >>>>>> What I don't really understand is how this is supposed to work at all, >>>>>> because every JAXP test which runs with "-DrunSecMngr=true" will >>>>>> execute the following code from JAXPPolicyManager: >>>>>> >>>>>> /* >>>>>> * Install a SecurityManager along with a default Policy to allow >>>>>> testNG to >>>>>> * run when there is a security manager. >>>>>> */ >>>>>> private JAXPPolicyManager() { >>>>>> // Backing up policy and security manager for restore >>>>>> policyBackup = Policy.getPolicy(); >>>>>> smBackup = System.getSecurityManager(); >>>>>> >>>>>> // Set customized policy >>>>>> setDefaultPermissions(); >>>>>> Policy.setPolicy(policy); >>>>>> System.setSecurityManager(new SecurityManager()); >>>>>> } >>>>>> >>>>>> Won't this code override the settings from the policy file which was >>>>>> potentially installed by jtreg for testng? >>>>>> >>>>>> The setDefaultPermissions() sets some special permissions for testng, >>>>>> but not "accessDeclaredMembers": >>>>>> >>>>>> private void setDefaultPermissions() { >>>>>> //Permissions to set security manager and policy >>>>>> addPermission(new SecurityPermission("getPolicy")); >>>>>> addPermission(new SecurityPermission("setPolicy")); >>>>>> addPermission(new RuntimePermission("setSecurityManager")); >>>>>> //Properties that jtreg and TestNG require >>>>>> addPermission(new >>>>>> PropertyPermission("testng.show.stack.frames", "read")); >>>>>> addPermission(new PropertyPermission("test.src", "read")); >>>>>> addPermission(new PropertyPermission("test.classes", "read")); >>>>>> addPermission(new >>>>>> PropertyPermission("dataproviderthreadcount", "read")); >>>>>> addPermission(new PropertyPermission("experimental", "read")); >>>>>> } >>>>>> >>>>>> If I add the line: >>>>>> >>>>>> addPermission(new RuntimePermission("accessDeclaredMembers")); >>>>>> >>>>>> to setDefaultPermissions(), the test will succeed. >>>>>> >>>>>> I saw that an early version of "JDK-8067170: Enable security manager >>>>>> on JAXP unit tests" contained that extra permission, but you objected >>>>>> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- >>> >>> July/042520.html) >>>>>> >>>>>> >>>>>> and it was removed in the final version. >>>>>> >>>>>> Any more hints? >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs >>>>>> wrote: >>>>>>> >>>>>>> Hi Christoph, >>>>>>> >>>>>>> Is there anything funny with the place jtreg is installed? >>>>>>> like: >>>>>>> - path contains whitespaces >>>>>>> - path is accessible through links or mount points... >>>>>>> >>>>>>> It seems clear that the issue here is that testng classes are >>>>>>> missing some permissions, so I was wondering whether that could >>>>>>> be caused by the actual path to testng.jar not matching the >>>>>>> path injected in the policy file. >>>>>>> >>>>>>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >>>>>>> >>>>>>> $ cd jaxp/tests >>>>>>> $ rm -r JT* >>>>>>> $ jtreg -verbose:summary -ignore:quiet -jdk >>>>>>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >>>>>>> >>>>>>> => the only test that fails is >>>>>>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's >>>>>>> expected >>>>>>> (it's in the ProblemList.txt). >>>>>>> >>>>>>> The other thing to take care of, is not to run two jtreg process >>>>>>> concurrently if they point to the same JT* directories. If you do >>>>>>> that then you might experience weird failures with permissions >>>>>>> issues (it seems to mess the policy files). >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> >>>>>>> On 22/11/16 10:52, Langer, Christoph wrote: >>>>>>>> >>>>>>>> >>>>>>>> Yes, please find it here: >>>>>>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>>> Sent: Dienstag, 22. November 2016 11:03 >>>>>>>>> To: Langer, Christoph >>>>>>>>> Cc: core-libs-dev at openjdk.java.net; >>>>>>>>> code-tools-dev at openjdk.java.net; >>>>>>>>> jtreg- >>>>>>>>> use at openjdk.java.net >>>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>>> ("java.lang.RuntimePermission" >>>>>>>>> "accessDeclaredMembers") >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Chris, >>>>>>>>>> >>>>>>>>>> thanks for this hint. However, we've already seen this change and >>>>>>>>>> rebuilt >>>>>>>>> >>>>>>>>> >>>>>>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, the download from https://adopt- >>>>>>>>> >>>>>>>>> >>>>>>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>>>>>> where I >>>>>>>>> would >>>>>>>>> suppose latest jtreg sources were used, don't help. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am I missing something? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the >>>>>>>>> failing >>>>>>>>> test? >>>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Christoph >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>>>>>>> To: Langer, Christoph >>>>>>>>>>> Cc: core-libs-dev at openjdk.java.net; >>>>>>>>>>> code-tools-dev at openjdk.java.net; >>>>>>>>>>> jtreg- >>>>>>>>>>> use at openjdk.java.net >>>>>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>>>>> ("java.lang.RuntimePermission" >>>>>>>>>>> "accessDeclaredMembers") >>>>>>>>>>> >>>>>>>>>>> Hi Christoph, >>>>>>>>>>> >>>>>>>>>>> Can you please ensure that your build of jtreg contains the fix >>>>>>>>>>> for >>>>>>>>>>> 7901792 >>>>>>>>> >>>>>>>>> >>>>>>>>> [1]. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>>>>>>> >>>>>>>>>>> -Chris. >>>>>>>>>>> >>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>>>>>>> >>>>>>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I'm currently struggling while running jtreg tests for the jaxp >>>>>>>>>>>> depot. >>>>>>>>>>>> >>>>>>>>>>>> There are several tests that fail with the same symptom. I >>>>>>>>>>>> always get >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> exceptions like: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> java.security.AccessControlException: access denied >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ntext.java:471) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> :894) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 48) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>>> java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>>>>>>> at >>>>>>>>>>>> java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> java:129) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 224) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 188) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Method) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> AccessorImpl.java:62) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> gMethodAccessorImpl.java:43) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>>> java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ava:110) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>>>>>> >>>>>>>>>>>> For instance the test >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails >>>>>>>>>>> like >>>>>>>>>>> this. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some >>>>>>>>>>>> important >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> permission for testing is missing with that. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks for any help. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards >>>>>>>>>>>> Christoph >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> > From christoph.langer at sap.com Tue Nov 22 14:43:22 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 14:43:22 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> Message-ID: <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Hi Daniel, yes - that looks like what we observe, see Volker's mail. It seems to work with testing 6.9.5 but not with 6.9.10 or 6.9.11. So for my jaxp testing I can use 6.9.5, I'm so happy :) But, as for fixing with the new testng, will you look into this? Shall I open a bug? Thanks Christoph > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Dienstag, 22. November 2016 15:31 > To: Langer, Christoph ; Volker Simonis > > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi, > > The issue seems to be caused by changes in testng - but maybe that > needs to be fixed in the JAXP test base. > > I could reproduce the issue by running the jaxp tests, after > unsetting JT_HOME and running with > https://adopt- > openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2- > b03.tar.gz > which has testng 6.9.11. > > When I dowloaded > http://mvnrepository.com/artifact/org.testng/testng/6.9.5 > and installed it in the jtreg install dir, the issue disappeared. > > best regards, > > -- daniel > From christoph.langer at sap.com Tue Nov 22 14:51:14 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 14:51:14 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: <7b9c0ca9a73c4d03920b87eea1ecab4f@DEWDFE13DE03.global.corp.sap> In that case, if we can't change testng, maybe the jaxp SecurityManager can allow testng to access the declared members without granting this to the testee code? > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Dienstag, 22. November 2016 15:47 > To: Langer, Christoph > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net; Volker Simonis > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > On 22/11/16 14:43, Langer, Christoph wrote: > > But, as for fixing with the new testng, will you look into this? Shall I open a > bug? > > I am unsure on how to fix this actually. > > The new testng must attempt to load the data provider > after having invoked the listener, while the old testng > probably did the opposite. > > Let me try some experiments... > > best regards, > > -- daniel From volker.simonis at gmail.com Tue Nov 22 19:24:41 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Nov 2016 20:24:41 +0100 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: Hi Daniel, thanks for your patch! I've meanwhile tried to better understand the root cause of the problem. I don't think that the invocation order of the data provider the listener have changed. If you look at the the two version 6.9.5 and 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly the same in both 6.9.5 [1] and 6.9.13 [2]: public void run() { beforeRun(); try { XmlTest test= getTest(); if(test.isJUnit()) { privateRunJUnit(test); } else { privateRun(test); } } finally { afterRun(); } I think the problem is in org.testng.internal.ClassHelper.getAvailableMethods() where we testng only collected the methods until (i.e. excluding) java.lang.Object in 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: 6.9.5 ===== public static Set getAvailableMethods(Class clazz) { Set methods = Sets.newHashSet(); methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); Class parent = clazz.getSuperclass(); while (Object.class != parent) { methods.addAll(extractMethods(clazz, parent, methods)); parent = parent.getSuperclass(); } 6.9.13 ===== public static Set getAvailableMethods(Class clazz) { Set methods = Sets.newHashSet(); methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); Class parent = clazz.getSuperclass(); while (null != parent) { methods.addAll(extractMethods(clazz, parent, methods)); parent = parent.getSuperclass(); } But java.lang.Object has a different class loader (null) compared to the test class (which is loaded by the application class loader), which leads to the AccessControlException with 6.9.13. As far as I can see, this was changed in testng 6.9.10 [5] to fix https://github.com/cbeust/testng/issues/876 This behavior may potentially also affect other tests which are running with a security manger so I'm not sure you fix will help for all of them. And I also wonder why this hasn't been detected by other who run testng with a security manager (but maybe nobody is doing that :) Regards, Volker [1] https://github.com/cbeust/testng/blob/testng-6.9.5/src/main/java/org/testng/TestRunner.java [2] https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRunner.java [3] https://github.com/cbeust/testng/blob/testng-6.9.5/src/main/java/org/testng/internal/ClassHelper.java [4] https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/internal/ClassHelper.java [5] https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780bff7716fca29daaab On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs wrote: > Hi Christoph, > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > best regards, > > -- daniel > > > On 22/11/16 14:47, Daniel Fuchs wrote: >> >> On 22/11/16 14:43, Langer, Christoph wrote: >>> >>> But, as for fixing with the new testng, will you look into this? Shall >>> I open a bug? > > From christoph.langer at sap.com Tue Nov 22 19:50:30 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 19:50:30 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: <2df3195f1faf474dbd8593c2af8e50bf@DEWDFE13DE03.global.corp.sap> Thanks a lot Volker and Daniel for the big support to analyze and fix this. It seems to me that the proposed fix (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like the best that can be done at the moment. I agree that it would be nicer if jtreg would leave the jtreg lib path as java property to be able to elevate all of its contents. But the current proposal with a set of TEST_JARS of jtreg, javatest and testng is probably sufficient for jaxp testing. The best thing to find out about other issues with the new version of testng would certainly be if Oracle's internal version of jtreg be updated to use the latest testng :-) Best regards Christoph > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Dienstag, 22. November 2016 20:25 > To: Daniel Fuchs > Cc: Langer, Christoph ; code-tools- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi Daniel, > > thanks for your patch! > > I've meanwhile tried to better understand the root cause of the problem. > > I don't think that the invocation order of the data provider the > listener have changed. If you look at the the two version 6.9.5 and > 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly > the same in both 6.9.5 [1] and 6.9.13 [2]: > > public void run() { > beforeRun(); > > try { > XmlTest test= getTest(); > if(test.isJUnit()) { > privateRunJUnit(test); > } > else { > privateRun(test); > } > } > finally { > afterRun(); > } > > I think the problem is in > org.testng.internal.ClassHelper.getAvailableMethods() where we testng > only collected the methods until (i.e. excluding) java.lang.Object in > 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: > > 6.9.5 > ===== > public static Set getAvailableMethods(Class clazz) { > Set methods = Sets.newHashSet(); > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > Class parent = clazz.getSuperclass(); > while (Object.class != parent) { > methods.addAll(extractMethods(clazz, parent, methods)); > parent = parent.getSuperclass(); > } > > 6.9.13 > ===== > public static Set getAvailableMethods(Class clazz) { > Set methods = Sets.newHashSet(); > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > Class parent = clazz.getSuperclass(); > while (null != parent) { > methods.addAll(extractMethods(clazz, parent, methods)); > parent = parent.getSuperclass(); > } > > But java.lang.Object has a different class loader (null) compared to > the test class (which is loaded by the application class loader), > which leads to the AccessControlException with 6.9.13. > > As far as I can see, this was changed in testng 6.9.10 [5] to fix > https://github.com/cbeust/testng/issues/876 > > This behavior may potentially also affect other tests which are > running with a security manger so I'm not sure you fix will help for > all of them. And I also wonder why this hasn't been detected by other > who run testng with a security manager (but maybe nobody is doing that > :) > > Regards, > Volker > > [1] https://github.com/cbeust/testng/blob/testng- > 6.9.5/src/main/java/org/testng/TestRunner.java > [2] > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu > nner.java > [3] https://github.com/cbeust/testng/blob/testng- > 6.9.5/src/main/java/org/testng/internal/ClassHelper.java > [4] > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna > l/ClassHelper.java > [5] > https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b > ff7716fca29daaab > > > On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs > wrote: > > Hi Christoph, > > > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > best regards, > > > > -- daniel > > > > > > On 22/11/16 14:47, Daniel Fuchs wrote: > >> > >> On 22/11/16 14:43, Langer, Christoph wrote: > >>> > >>> But, as for fixing with the new testng, will you look into this? Shall > >>> I open a bug? > > > > From christoph.langer at sap.com Wed Nov 23 07:40:57 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Nov 2016 07:40:57 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <030901d2454a$18c955b0$4a5c0110$@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> <2df3195f1faf474dbd! 8593c2af8e50bf@DEWDFE13 DE03.global.corp.sap> <030901d2454a$18c955b0$4a5c0110$@oracle.com> Message-ID: <762c837a843e4b99bffae8e3f3e6d4b0@DEWDFE13DE03.global.corp.sap> Thanks, Frank. we run scheduled jtreg tests for jdk every night so we should have encountered issues if there were some. But langtools could be interesting, I don't think those run automatically for OpenJDK in our environment. Best regards Christoph > -----Original Message----- > From: Frank Yuan [mailto:frank.yuan at oracle.com] > Sent: Mittwoch, 23. November 2016 06:26 > To: Langer, Christoph ; 'Volker Simonis' > ; 'Daniel Fuchs' > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi Christoph and Volker > > I have been launching jdk and langtools tests with the new jtreg, will update to > you once I get the result. > Hope jaxp test is special because most of tests should control the Security > Manager setting inside the test methods. > > Thanks > Frank > > > > > -----Original Message----- > > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Langer, Christoph > > Sent: Wednesday, November 23, 2016 3:51 AM > > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > > > Thanks a lot Volker and Daniel for the big support to analyze and fix this. > > > > It seems to me that the proposed fix > > (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like > > the best that can be done at the moment. I agree that it would be nicer if > > jtreg would leave the jtreg lib path as java property to be able to elevate > > all of its contents. But the current proposal with a set of TEST_JARS of > > jtreg, javatest and testng is probably sufficient for jaxp testing. > > > > The best thing to find out about other issues with the new version of testng > > would certainly be if Oracle's internal version of jtreg be updated to use > > the latest testng :-) > > > > Best regards > > Christoph > > > > > > > > > -----Original Message----- > > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > > Sent: Dienstag, 22. November 2016 20:25 > > > To: Daniel Fuchs > > > Cc: Langer, Christoph ; code-tools- > > > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > > > use at openjdk.java.net > > > Subject: Re: Issues running JAXP jtreg tests > > > ("java.lang.RuntimePermission" > > > "accessDeclaredMembers") > > > > > > Hi Daniel, > > > > > > thanks for your patch! > > > > > > I've meanwhile tried to better understand the root cause of the problem. > > > > > > I don't think that the invocation order of the data provider the > > > listener have changed. If you look at the the two version 6.9.5 and > > > 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly > > > the same in both 6.9.5 [1] and 6.9.13 [2]: > > > > > > public void run() { > > > beforeRun(); > > > > > > try { > > > XmlTest test= getTest(); > > > if(test.isJUnit()) { > > > privateRunJUnit(test); > > > } > > > else { > > > privateRun(test); > > > } > > > } > > > finally { > > > afterRun(); > > > } > > > > > > I think the problem is in > > > org.testng.internal.ClassHelper.getAvailableMethods() where we testng > > > only collected the methods until (i.e. excluding) java.lang.Object in > > > 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: > > > > > > 6.9.5 > > > ===== > > > public static Set getAvailableMethods(Class clazz) { > > > Set methods = Sets.newHashSet(); > > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > > > Class parent = clazz.getSuperclass(); > > > while (Object.class != parent) { > > > methods.addAll(extractMethods(clazz, parent, methods)); > > > parent = parent.getSuperclass(); > > > } > > > > > > 6.9.13 > > > ===== > > > public static Set getAvailableMethods(Class clazz) { > > > Set methods = Sets.newHashSet(); > > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > > > Class parent = clazz.getSuperclass(); > > > while (null != parent) { > > > methods.addAll(extractMethods(clazz, parent, methods)); > > > parent = parent.getSuperclass(); > > > } > > > > > > But java.lang.Object has a different class loader (null) compared to > > > the test class (which is loaded by the application class loader), > > > which leads to the AccessControlException with 6.9.13. > > > > > > As far as I can see, this was changed in testng 6.9.10 [5] to fix > > > https://github.com/cbeust/testng/issues/876 > > > > > > This behavior may potentially also affect other tests which are > > > running with a security manger so I'm not sure you fix will help for > > > all of them. And I also wonder why this hasn't been detected by other > > > who run testng with a security manager (but maybe nobody is doing that > > > :) > > > > > > Regards, > > > Volker > > > > > > [1] https://github.com/cbeust/testng/blob/testng- > > > 6.9.5/src/main/java/org/testng/TestRunner.java > > > [2] > > > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu > > > nner.java > > > [3] https://github.com/cbeust/testng/blob/testng- > > > 6.9.5/src/main/java/org/testng/internal/ClassHelper.java > > > [4] > > > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna > > > l/ClassHelper.java > > > [5] > > > > https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b > > > ff7716fca29daaab > > > > > > > > > On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs > > > wrote: > > > > Hi Christoph, > > > > > > > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > > > > > best regards, > > > > > > > > -- daniel > > > > > > > > > > > > On 22/11/16 14:47, Daniel Fuchs wrote: > > > >> > > > >> On 22/11/16 14:43, Langer, Christoph wrote: > > > >>> > > > >>> But, as for fixing with the new testng, will you look into this? Shall > > > >>> I open a bug? > > > > > > > > From christoph.langer at sap.com Wed Nov 23 07:48:27 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Nov 2016 07:48:27 +0000 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <02f901d24543$d2b37f70$781a7e50$@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> Message-ID: <6d4303350e6f44aaa5016abd0bc4a8ec@DEWDFE13DE03.global.corp.sap> Hi Frank, to me this looks fine. Maybe a small cosmetical thing: Around lines 212 and 240 you could remove the additional empty lines to have one blank line between methods as in the rest of the file. Note that I'm not a reviewer. Best regards Christoph From: Frank Yuan [mailto:frank.yuan at oracle.com] Sent: Mittwoch, 23. November 2016 05:41 To: core-libs-dev at openjdk.java.net; 'Daniel Fuchs' ; Langer, Christoph ; 'Volker Simonis' ; 'Joe Wang' Cc: code-tools-dev at openjdk.java.net; jtreg-use at openjdk.java.net Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars Hi All Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 This patch is fully same as Daniel provided except a few lines of additional cleaning, thanks to Daniel for providing the patch! Thanks Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.yuan at oracle.com Wed Nov 23 08:31:50 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 23 Nov 2016 16:31:50 +0800 Subject: Did the tests fail due to TestNG dataprovider parameter type check? Message-ID: <036a01d24564$0bc56e20$23504a60$@oracle.com> Hi Jon I run the whole jdk regression tests with jtreg-4.2-b03 [1], and then found lots of tests in different test groups failed with the error message like following: test test.java.time.format.TestNumberPrinter.test_pad_ALWAYS(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_pad_ALWAYS([Parameter{index=0, type=int, declaredAnnotations=[]}, Parameter{index=1, type=int, declaredAnnotations=[]}, Parameter{index=2, type=long, declaredAnnotations=[]}, Parameter{index=3, type=java.lang.String, declaredAnnotations=[]}]) Arguments: [(java.lang.Integer)1,(java.lang.Integer)1,(java.lang.Integer)-10,null] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) 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:1225) at org.testng.TestNG.runSuitesLocally(TestNG.java:1150) at org.testng.TestNG.runSuites(TestNG.java:1075) at org.testng.TestNG.run(TestNG.java:1047) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:184) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:537) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) This test methd signature is: public void test_pad_ALWAYS(int minPad, int maxPad, long value, String result) The provider return the following data Object[][] provider_pad() { return new Object[][] { {1, 1, -10, null}, {1, 1, -9, "9"}, {1, 1, -1, "1"}, ... However, I got message "Cannot find class java/lang/reflect/JTRegModuleHelper.class to init patch directory" when I run jtreg, although I didn't find any code related to testng dataprovider in jtreg source, I would double confirm with you if this is a definite issue or anything I made incorrectly? To Christoph Except above issue, I didn't find any other issue in jdk and langtools repo so far. [1] https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz Thanks Frank > -----Original Message----- > From: Langer, Christoph [mailto:christoph.langer at sap.com] > Sent: Wednesday, November 23, 2016 3:41 PM > To: Frank Yuan > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg-use at openjdk.java.net; 'Volker Simonis'; 'Daniel Fuchs' > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") > > Thanks, Frank. > > we run scheduled jtreg tests for jdk every night so we should have encountered issues if there were some. But langtools could be interesting, I > don't think those run automatically for OpenJDK in our environment. > > Best regards > Christoph > > > -----Original Message----- > > From: Frank Yuan [mailto:frank.yuan at oracle.com] > > Sent: Mittwoch, 23. November 2016 06:26 > > To: Langer, Christoph ; 'Volker Simonis' > > ; 'Daniel Fuchs' > > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > > use at openjdk.java.net > > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > > "accessDeclaredMembers") > > > > Hi Christoph and Volker > > > > I have been launching jdk and langtools tests with the new jtreg, will update to > > you once I get the result. > > Hope jaxp test is special because most of tests should control the Security > > Manager setting inside the test methods. > > > > Thanks > > Frank > > > > > > > > > -----Original Message----- > > > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > > Behalf Of Langer, Christoph > > > Sent: Wednesday, November 23, 2016 3:51 AM > > > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > > "accessDeclaredMembers") > > > > > > Thanks a lot Volker and Daniel for the big support to analyze and fix this. > > > > > > It seems to me that the proposed fix > > > (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like > > > the best that can be done at the moment. I agree that it would be nicer if > > > jtreg would leave the jtreg lib path as java property to be able to elevate > > > all of its contents. But the current proposal with a set of TEST_JARS of > > > jtreg, javatest and testng is probably sufficient for jaxp testing. > > > > > > The best thing to find out about other issues with the new version of testng > > > would certainly be if Oracle's internal version of jtreg be updated to use > > > the latest testng :-) > > > > > > Best regards > > > Christoph > > > > > > > > > > > > > -----Original Message----- > > > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > > > Sent: Dienstag, 22. November 2016 20:25 > > > > To: Daniel Fuchs > > > > Cc: Langer, Christoph ; code-tools- > > > > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > > > > use at openjdk.java.net > > > > Subject: Re: Issues running JAXP jtreg tests > > > > ("java.lang.RuntimePermission" > > > > "accessDeclaredMembers") > > > > > > > > Hi Daniel, > > > > > > > > thanks for your patch! > > > > > > > > I've meanwhile tried to better understand the root cause of the problem. > > > > > > > > I don't think that the invocation order of the data provider the > > > > listener have changed. If you look at the the two version 6.9.5 and > > > > 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly > > > > the same in both 6.9.5 [1] and 6.9.13 [2]: > > > > > > > > public void run() { > > > > beforeRun(); > > > > > > > > try { > > > > XmlTest test= getTest(); > > > > if(test.isJUnit()) { > > > > privateRunJUnit(test); > > > > } > > > > else { > > > > privateRun(test); > > > > } > > > > } > > > > finally { > > > > afterRun(); > > > > } > > > > > > > > I think the problem is in > > > > org.testng.internal.ClassHelper.getAvailableMethods() where we testng > > > > only collected the methods until (i.e. excluding) java.lang.Object in > > > > 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: > > > > > > > > 6.9.5 > > > > ===== > > > > public static Set getAvailableMethods(Class clazz) { > > > > Set methods = Sets.newHashSet(); > > > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > > > > > Class parent = clazz.getSuperclass(); > > > > while (Object.class != parent) { > > > > methods.addAll(extractMethods(clazz, parent, methods)); > > > > parent = parent.getSuperclass(); > > > > } > > > > > > > > 6.9.13 > > > > ===== > > > > public static Set getAvailableMethods(Class clazz) { > > > > Set methods = Sets.newHashSet(); > > > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > > > > > Class parent = clazz.getSuperclass(); > > > > while (null != parent) { > > > > methods.addAll(extractMethods(clazz, parent, methods)); > > > > parent = parent.getSuperclass(); > > > > } > > > > > > > > But java.lang.Object has a different class loader (null) compared to > > > > the test class (which is loaded by the application class loader), > > > > which leads to the AccessControlException with 6.9.13. > > > > > > > > As far as I can see, this was changed in testng 6.9.10 [5] to fix > > > > https://github.com/cbeust/testng/issues/876 > > > > > > > > This behavior may potentially also affect other tests which are > > > > running with a security manger so I'm not sure you fix will help for > > > > all of them. And I also wonder why this hasn't been detected by other > > > > who run testng with a security manager (but maybe nobody is doing that > > > > :) > > > > > > > > Regards, > > > > Volker > > > > > > > > [1] https://github.com/cbeust/testng/blob/testng- > > > > 6.9.5/src/main/java/org/testng/TestRunner.java > > > > [2] > > > > > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu > > > > nner.java > > > > [3] https://github.com/cbeust/testng/blob/testng- > > > > 6.9.5/src/main/java/org/testng/internal/ClassHelper.java > > > > [4] > > > > > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna > > > > l/ClassHelper.java > > > > [5] > > > > > > https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b > > > > ff7716fca29daaab > > > > > > > > > > > > On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs > > > > wrote: > > > > > Hi Christoph, > > > > > > > > > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > > > > > > > best regards, > > > > > > > > > > -- daniel > > > > > > > > > > > > > > > On 22/11/16 14:47, Daniel Fuchs wrote: > > > > >> > > > > >> On 22/11/16 14:43, Langer, Christoph wrote: > > > > >>> > > > > >>> But, as for fixing with the new testng, will you look into this? Shall > > > > >>> I open a bug? > > > > > > > > > > From manuelag2004 at yahoo.co.uk Sat Nov 19 00:27:22 2016 From: manuelag2004 at yahoo.co.uk (Manuela Grindei) Date: Sat, 19 Nov 2016 00:27:22 +0000 (UTC) Subject: running jtreg for jdk8u In-Reply-To: <701660426.3065234.1477956972399@mail.yahoo.com> References: <593282355.3620607.1477526302474.ref@mail.yahoo.com> <593282355.3620607.1477526302474@mail.yahoo.com> <701660426.3065234.1477956972399@mail.yahoo.com> Message-ID: <1267985694.5772246.1479515243638@mail.yahoo.com> Hi everyone, I'm trying to test the fix I created for JDK-8154066, but I cannot run jtreg for jdk8u from VirtualBox. I have created the images, but when starting jtreg, it keeps throwing an error saying that it cannot find JDK. I'm trying to run: $JTREG_HOME/bin/jtreg -jdk:build/linux-x86_64-normal-server-release/images/jdk jdk/test/:compact1. I took some screenshots of the directories I currently have after creating the images and I was wondering if you could help me. Thank you, Manuela Grindei -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagesFolder.png Type: image/png Size: 830955 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: j2sdkFolder.png Type: image/png Size: 660817 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk.png Type: image/png Size: 788307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jtreg.png Type: image/png Size: 825456 bytes Desc: not available URL: From daniel.fuchs at oracle.com Tue Nov 22 11:24:43 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 11:24:43 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Hi Christoph, Is there anything funny with the place jtreg is installed? like: - path contains whitespaces - path is accessible through links or mount points... It seems clear that the issue here is that testng classes are missing some permissions, so I was wondering whether that could be caused by the actual path to testng.jar not matching the path injected in the policy file. I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: $ cd jaxp/tests $ rm -r JT* $ jtreg -verbose:summary -ignore:quiet -jdk ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ => the only test that fails is javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's expected (it's in the ProblemList.txt). The other thing to take care of, is not to run two jtreg process concurrently if they point to the same JT* directories. If you do that then you might experience weird failures with permissions issues (it seems to mess the policy files). best regards, -- daniel On 22/11/16 10:52, Langer, Christoph wrote: > Yes, please find it here: http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr > > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Dienstag, 22. November 2016 11:03 >> To: Langer, Christoph >> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- >> use at openjdk.java.net >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >> "accessDeclaredMembers") >> >> >>> On 22 Nov 2016, at 09:43, Langer, Christoph >> wrote: >>> >>> Hi Chris, >>> >>> thanks for this hint. However, we've already seen this change and rebuilt >> jtreg with the latest jtreg repo. But it doesn't change a thing. >>> >>> Also, the download from https://adopt- >> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I would >> suppose latest jtreg sources were used, don't help. >>> >>> Am I missing something? >> >> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing test? >> >> -Chris. >> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>> Sent: Dienstag, 22. November 2016 10:08 >>>> To: Langer, Christoph >>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- >>>> use at openjdk.java.net >>>> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >>>> "accessDeclaredMembers") >>>> >>>> Hi Christoph, >>>> >>>> Can you please ensure that your build of jtreg contains the fix for 7901792 >> [1]. >>>> 7901792 grants /lib/testng.jar all permissions. >>>> >>>> -Chris. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>> >>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm currently struggling while running jtreg tests for the jaxp depot. >>>>> >>>>> There are several tests that fail with the same symptom. I always get >>>> exceptions like: >>>>> java.security.AccessControlException: access denied >>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>> at >>>> >> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>> ntext.java:471) >>>>> at >>>> >> java.base/java.security.AccessController.checkPermission(AccessController.java >>>> :894) >>>>> at >>>> >> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>> 48) >>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>> at >> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>> at >>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>> at >> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>> at >> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>> at >>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>> at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>> at org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>> at >>>> >> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>> java:129) >>>>> at >>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>> 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 >>>> >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>> 224) >>>>> at >>>> >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>> 188) >>>>> at >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> Method) >>>>> at >>>> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>> AccessorImpl.java:62) >>>>> at >>>> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>> gMethodAccessorImpl.java:43) >>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>> at >>>> >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>> ava:110) >>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>> >>>>> For instance the test >>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. >>>>> >>>>> It's calling "testng -DrunSecMngr=true" and obviously some important >>>> permission for testing is missing with that. >>>>> >>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>> >>>>> >>>>> Thanks for any help. >>>>> >>>>> >>>>> Best regards >>>>> Christoph >>> > From daniel.fuchs at oracle.com Tue Nov 22 12:32:32 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 12:32:32 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Hi Volker, On 22/11/16 12:25, Chris Hegarty wrote: > Volker, > > Just to add, jtreg has support in its tags to start the test VM with a > security manager and a specified policy. In the case of the test failure > you are seeing, the built-in jtreg support is not being used. Instead, > the test is executing with a test-specific system property that is being > used to trigger the programatic setting of a security manager with a > generated policy. I think this explains why you are not seeing any > policy file in the JTwork directory. > > What is odd is that the stack trace you are seeing appears to be > before the test?s main entry point, so I would not expect to the > security manager to be active at this point ( since no test code > has run ). My previous comment regarding 7901792 is not relevant > since it relates to tests executing with a security manager set > through jtreg tags. I agree with Chris - I believe CODETOOLS-7901792 was a red herring. I'm going to try the jtreg you pointed at and see if there's any difference (I'm using jtreg 4.2 fcs b03). > Is there anything in the environment that could trigger the VM > to start up with a security manager enabled? This is a good question. best regards, -- daniel > > -Chris. > >> On 22 Nov 2016, at 12:13, Volker Simonis wrote: >> >> Hi Daniel, >> >> thanks for your support - this problem really drives us crazy! >> >> What version of jtreg are you using? >> If you are using a central one which was configured and build by >> Oracle, could you please also try with the one from >> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >> ? >> >> Where can we find the generated policy files? It seems they get >> deleted during test post-run cleanup phase (at least I could not find >> any of them under JTwork). Is there a way to get a more detailed trace >> on how JTreg executes testng and to leave all the generated files in >> place after the test? >> >> I'm currently running the following JAXP test and get the same error >> as described by Christoph: >> >> /tmp/jtreg/bin/jtreg -verbose:summary -jdk >> /output-jdk9-hs-dbg/images/jdk/ >> /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java >> >> What I don't really understand is how this is supposed to work at all, >> because every JAXP test which runs with "-DrunSecMngr=true" will >> execute the following code from JAXPPolicyManager: >> >> /* >> * Install a SecurityManager along with a default Policy to allow testNG to >> * run when there is a security manager. >> */ >> private JAXPPolicyManager() { >> // Backing up policy and security manager for restore >> policyBackup = Policy.getPolicy(); >> smBackup = System.getSecurityManager(); >> >> // Set customized policy >> setDefaultPermissions(); >> Policy.setPolicy(policy); >> System.setSecurityManager(new SecurityManager()); >> } >> >> Won't this code override the settings from the policy file which was >> potentially installed by jtreg for testng? >> >> The setDefaultPermissions() sets some special permissions for testng, >> but not "accessDeclaredMembers": >> >> private void setDefaultPermissions() { >> //Permissions to set security manager and policy >> addPermission(new SecurityPermission("getPolicy")); >> addPermission(new SecurityPermission("setPolicy")); >> addPermission(new RuntimePermission("setSecurityManager")); >> //Properties that jtreg and TestNG require >> addPermission(new >> PropertyPermission("testng.show.stack.frames", "read")); >> addPermission(new PropertyPermission("test.src", "read")); >> addPermission(new PropertyPermission("test.classes", "read")); >> addPermission(new >> PropertyPermission("dataproviderthreadcount", "read")); >> addPermission(new PropertyPermission("experimental", "read")); >> } >> >> If I add the line: >> >> addPermission(new RuntimePermission("accessDeclaredMembers")); >> >> to setDefaultPermissions(), the test will succeed. >> >> I saw that an early version of "JDK-8067170: Enable security manager >> on JAXP unit tests" contained that extra permission, but you objected >> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042520.html) >> and it was removed in the final version. >> >> Any more hints? >> >> Thanks, >> Volker >> >> >> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs wrote: >>> Hi Christoph, >>> >>> Is there anything funny with the place jtreg is installed? >>> like: >>> - path contains whitespaces >>> - path is accessible through links or mount points... >>> >>> It seems clear that the issue here is that testng classes are >>> missing some permissions, so I was wondering whether that could >>> be caused by the actual path to testng.jar not matching the >>> path injected in the policy file. >>> >>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >>> >>> $ cd jaxp/tests >>> $ rm -r JT* >>> $ jtreg -verbose:summary -ignore:quiet -jdk >>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >>> >>> => the only test that fails is >>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's expected >>> (it's in the ProblemList.txt). >>> >>> The other thing to take care of, is not to run two jtreg process >>> concurrently if they point to the same JT* directories. If you do >>> that then you might experience weird failures with permissions >>> issues (it seems to mess the policy files). >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 22/11/16 10:52, Langer, Christoph wrote: >>>> >>>> Yes, please find it here: >>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>>> >>>> >>>>> -----Original Message----- >>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>> Sent: Dienstag, 22. November 2016 11:03 >>>>> To: Langer, Christoph >>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>> jtreg- >>>>> use at openjdk.java.net >>>>> Subject: Re: Issues running JAXP jtreg tests >>>>> ("java.lang.RuntimePermission" >>>>> "accessDeclaredMembers") >>>>> >>>>> >>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> thanks for this hint. However, we've already seen this change and >>>>>> rebuilt >>>>> >>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>>> >>>>>> >>>>>> Also, the download from https://adopt- >>>>> >>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I >>>>> would >>>>> suppose latest jtreg sources were used, don't help. >>>>>> >>>>>> >>>>>> Am I missing something? >>>>> >>>>> >>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>>>> test? >>>>> >>>>> -Chris. >>>>> >>>>>> Best regards >>>>>> Christoph >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>>> To: Langer, Christoph >>>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>>>> jtreg- >>>>>>> use at openjdk.java.net >>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>> ("java.lang.RuntimePermission" >>>>>>> "accessDeclaredMembers") >>>>>>> >>>>>>> Hi Christoph, >>>>>>> >>>>>>> Can you please ensure that your build of jtreg contains the fix for >>>>>>> 7901792 >>>>> >>>>> [1]. >>>>>>> >>>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>>> >>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm currently struggling while running jtreg tests for the jaxp depot. >>>>>>>> >>>>>>>> There are several tests that fail with the same symptom. I always get >>>>>>> >>>>>>> exceptions like: >>>>>>>> >>>>>>>> java.security.AccessControlException: access denied >>>>>>> >>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>>> >>>>>>> ntext.java:471) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>>> >>>>>>> :894) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>>> >>>>>>> 48) >>>>>>>> >>>>>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>>> at >>>>> >>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>>> >>>>>>>> at >>>>> >>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>>> >>>>>>>> at >>>>> >>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>>> >>>>>>>> at >>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>>> at >>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>>> at >>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>>> at >>>>>>> >>>>>>> >>>>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>>> >>>>>>> java:129) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>>> >>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>>> 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 >>>>>>> >>>>>>> >>>>> >>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>> >>>>>>> 224) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>> >>>>>>> 188) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>> Method) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>>> >>>>>>> AccessorImpl.java:62) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>>> >>>>>>> gMethodAccessorImpl.java:43) >>>>>>>> >>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>>> at >>>>>>> >>>>>>> >>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>>> >>>>>>> ava:110) >>>>>>>> >>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>> >>>>>>>> For instance the test >>>>>>> >>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>>>> this. >>>>>>>> >>>>>>>> >>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some important >>>>>>> >>>>>>> permission for testing is missing with that. >>>>>>>> >>>>>>>> >>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>>> >>>>>>>> >>>>>>>> Thanks for any help. >>>>>>>> >>>>>>>> >>>>>>>> Best regards >>>>>>>> Christoph >>>>>> >>>>>> >>>> >>> > From daniel.fuchs at oracle.com Tue Nov 22 12:42:14 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 12:42:14 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> Hi guys, Are you running the tests with the exploded jdk or with the image? I'm seeing failures with the exploded jdk. That could explain the difference with permission checks. best regards, -- daniel On 22/11/16 12:32, Daniel Fuchs wrote: > Hi Volker, > > On 22/11/16 12:25, Chris Hegarty wrote: >> Volker, >> >> Just to add, jtreg has support in its tags to start the test VM with a >> security manager and a specified policy. In the case of the test failure >> you are seeing, the built-in jtreg support is not being used. Instead, >> the test is executing with a test-specific system property that is being >> used to trigger the programatic setting of a security manager with a >> generated policy. I think this explains why you are not seeing any >> policy file in the JTwork directory. >> >> What is odd is that the stack trace you are seeing appears to be >> before the test?s main entry point, so I would not expect to the >> security manager to be active at this point ( since no test code >> has run ). My previous comment regarding 7901792 is not relevant >> since it relates to tests executing with a security manager set >> through jtreg tags. > > I agree with Chris - I believe CODETOOLS-7901792 was a red herring. > I'm going to try the jtreg you pointed at and see if there's any > difference (I'm using jtreg 4.2 fcs b03). > >> Is there anything in the environment that could trigger the VM >> to start up with a security manager enabled? > > This is a good question. > > best regards, > > -- daniel > >> >> -Chris. >> >>> On 22 Nov 2016, at 12:13, Volker Simonis >>> wrote: >>> >>> Hi Daniel, >>> >>> thanks for your support - this problem really drives us crazy! >>> >>> What version of jtreg are you using? >>> If you are using a central one which was configured and build by >>> Oracle, could you please also try with the one from >>> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>> >>> ? >>> >>> Where can we find the generated policy files? It seems they get >>> deleted during test post-run cleanup phase (at least I could not find >>> any of them under JTwork). Is there a way to get a more detailed trace >>> on how JTreg executes testng and to leave all the generated files in >>> place after the test? >>> >>> I'm currently running the following JAXP test and get the same error >>> as described by Christoph: >>> >>> /tmp/jtreg/bin/jtreg -verbose:summary -jdk >>> /output-jdk9-hs-dbg/images/jdk/ >>> /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java >>> >>> >>> What I don't really understand is how this is supposed to work at all, >>> because every JAXP test which runs with "-DrunSecMngr=true" will >>> execute the following code from JAXPPolicyManager: >>> >>> /* >>> * Install a SecurityManager along with a default Policy to allow >>> testNG to >>> * run when there is a security manager. >>> */ >>> private JAXPPolicyManager() { >>> // Backing up policy and security manager for restore >>> policyBackup = Policy.getPolicy(); >>> smBackup = System.getSecurityManager(); >>> >>> // Set customized policy >>> setDefaultPermissions(); >>> Policy.setPolicy(policy); >>> System.setSecurityManager(new SecurityManager()); >>> } >>> >>> Won't this code override the settings from the policy file which was >>> potentially installed by jtreg for testng? >>> >>> The setDefaultPermissions() sets some special permissions for testng, >>> but not "accessDeclaredMembers": >>> >>> private void setDefaultPermissions() { >>> //Permissions to set security manager and policy >>> addPermission(new SecurityPermission("getPolicy")); >>> addPermission(new SecurityPermission("setPolicy")); >>> addPermission(new RuntimePermission("setSecurityManager")); >>> //Properties that jtreg and TestNG require >>> addPermission(new >>> PropertyPermission("testng.show.stack.frames", "read")); >>> addPermission(new PropertyPermission("test.src", "read")); >>> addPermission(new PropertyPermission("test.classes", "read")); >>> addPermission(new >>> PropertyPermission("dataproviderthreadcount", "read")); >>> addPermission(new PropertyPermission("experimental", "read")); >>> } >>> >>> If I add the line: >>> >>> addPermission(new RuntimePermission("accessDeclaredMembers")); >>> >>> to setDefaultPermissions(), the test will succeed. >>> >>> I saw that an early version of "JDK-8067170: Enable security manager >>> on JAXP unit tests" contained that extra permission, but you objected >>> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042520.html) >>> >>> and it was removed in the final version. >>> >>> Any more hints? >>> >>> Thanks, >>> Volker >>> >>> >>> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs >>> wrote: >>>> Hi Christoph, >>>> >>>> Is there anything funny with the place jtreg is installed? >>>> like: >>>> - path contains whitespaces >>>> - path is accessible through links or mount points... >>>> >>>> It seems clear that the issue here is that testng classes are >>>> missing some permissions, so I was wondering whether that could >>>> be caused by the actual path to testng.jar not matching the >>>> path injected in the policy file. >>>> >>>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >>>> >>>> $ cd jaxp/tests >>>> $ rm -r JT* >>>> $ jtreg -verbose:summary -ignore:quiet -jdk >>>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >>>> >>>> => the only test that fails is >>>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's >>>> expected >>>> (it's in the ProblemList.txt). >>>> >>>> The other thing to take care of, is not to run two jtreg process >>>> concurrently if they point to the same JT* directories. If you do >>>> that then you might experience weird failures with permissions >>>> issues (it seems to mess the policy files). >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>> On 22/11/16 10:52, Langer, Christoph wrote: >>>>> >>>>> Yes, please find it here: >>>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>> Sent: Dienstag, 22. November 2016 11:03 >>>>>> To: Langer, Christoph >>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>>> jtreg- >>>>>> use at openjdk.java.net >>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>> ("java.lang.RuntimePermission" >>>>>> "accessDeclaredMembers") >>>>>> >>>>>> >>>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>>>>> >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> thanks for this hint. However, we've already seen this change and >>>>>>> rebuilt >>>>>> >>>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>>>> >>>>>>> >>>>>>> Also, the download from https://adopt- >>>>>> >>>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>>> where I >>>>>> would >>>>>> suppose latest jtreg sources were used, don't help. >>>>>>> >>>>>>> >>>>>>> Am I missing something? >>>>>> >>>>>> >>>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>>>>> test? >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> Best regards >>>>>>> Christoph >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>>>> To: Langer, Christoph >>>>>>>> Cc: core-libs-dev at openjdk.java.net; >>>>>>>> code-tools-dev at openjdk.java.net; >>>>>>>> jtreg- >>>>>>>> use at openjdk.java.net >>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>> ("java.lang.RuntimePermission" >>>>>>>> "accessDeclaredMembers") >>>>>>>> >>>>>>>> Hi Christoph, >>>>>>>> >>>>>>>> Can you please ensure that your build of jtreg contains the fix for >>>>>>>> 7901792 >>>>>> >>>>>> [1]. >>>>>>>> >>>>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>>>> >>>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>>>>> >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm currently struggling while running jtreg tests for the jaxp >>>>>>>>> depot. >>>>>>>>> >>>>>>>>> There are several tests that fail with the same symptom. I >>>>>>>>> always get >>>>>>>> >>>>>>>> exceptions like: >>>>>>>>> >>>>>>>>> java.security.AccessControlException: access denied >>>>>>>> >>>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>> >>>>>>>> >>>>>>>> ntext.java:471) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>> >>>>>>>> >>>>>>>> :894) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>> >>>>>>>> >>>>>>>> 48) >>>>>>>>> >>>>>>>>> at >>>>>>>>> java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>>>> at >>>>>>>>> java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>>>> at >>>>>> >>>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>>> >>>>>>>>> >>>>>>>>> at >>>>>> >>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>>>> >>>>>>>>> at >>>>>> >>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>>> >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>>>> at >>>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>>>> at >>>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>> >>>>>>>> >>>>>>>> java:129) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>>>> >>>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>>>> at >>>>>>>>> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>> >>>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>> >>>>>>>> >>>>>>>> 224) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>> >>>>>>>> >>>>>>>> 188) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>> >>>>>>>> Method) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>> >>>>>>>> >>>>>>>> AccessorImpl.java:62) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>> >>>>>>>> >>>>>>>> gMethodAccessorImpl.java:43) >>>>>>>>> >>>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>> >>>>>>>> >>>>>>>> ava:110) >>>>>>>>> >>>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>>> >>>>>>>>> For instance the test >>>>>>>> >>>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>>>>> this. >>>>>>>>> >>>>>>>>> >>>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some >>>>>>>>> important >>>>>>>> >>>>>>>> permission for testing is missing with that. >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for any help. >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Christoph >>>>>>> >>>>>>> >>>>> >>>> >> > From daniel.fuchs at oracle.com Tue Nov 22 13:31:47 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 13:31:47 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: On 22/11/16 13:01, Langer, Christoph wrote: > Hi, > > we are running jtreg with something like -jdk:/images/jdk. So would that be the exploded version or not? Yes - that's the image. Hmm... The failures I see with the exploded build are different than what you have anyway. > FWIW: I think all test that fail don't have void test methods but the test methods expect input parameters and hence a tag @Test(dataProvider = "...") exists. Good observation. > Can it be that we are using a testng framework that is "too new" and maybe contains something which makes it not work in the jaxp scenario? When I call jtreg -version it reports: TestNG: version 6.9.5 This seems different to what you are using. Can you try with https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz without altering the version of testng? I had no problem running the tests with that version of testng (except if I use the exploded build). Maybe the listener that the test uses to set up the security manager is invoked in a different way (earlier?) with the 6.9.10 version? best regards, -- daniel > > Best, > Christoph > >> -----Original Message----- >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] >> Sent: Dienstag, 22. November 2016 13:42 >> To: Volker Simonis ; Langer, Christoph >> ; Langer, Christoph >> Cc: Chris Hegarty ; code-tools- >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- >> use at openjdk.java.net >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >> "accessDeclaredMembers") >> >> Hi guys, >> >> Are you running the tests with the exploded jdk or with the image? >> >> I'm seeing failures with the exploded jdk. >> >> That could explain the difference with permission checks. >> >> best regards, >> >> -- daniel >> >> >> On 22/11/16 12:32, Daniel Fuchs wrote: >>> Hi Volker, >>> >>> On 22/11/16 12:25, Chris Hegarty wrote: >>>> Volker, >>>> >>>> Just to add, jtreg has support in its tags to start the test VM with a >>>> security manager and a specified policy. In the case of the test failure >>>> you are seeing, the built-in jtreg support is not being used. Instead, >>>> the test is executing with a test-specific system property that is being >>>> used to trigger the programatic setting of a security manager with a >>>> generated policy. I think this explains why you are not seeing any >>>> policy file in the JTwork directory. >>>> >>>> What is odd is that the stack trace you are seeing appears to be >>>> before the test?s main entry point, so I would not expect to the >>>> security manager to be active at this point ( since no test code >>>> has run ). My previous comment regarding 7901792 is not relevant >>>> since it relates to tests executing with a security manager set >>>> through jtreg tags. >>> >>> I agree with Chris - I believe CODETOOLS-7901792 was a red herring. >>> I'm going to try the jtreg you pointed at and see if there's any >>> difference (I'm using jtreg 4.2 fcs b03). >>> >>>> Is there anything in the environment that could trigger the VM >>>> to start up with a security manager enabled? >>> >>> This is a good question. >>> >>> best regards, >>> >>> -- daniel >>> >>>> >>>> -Chris. >>>> >>>>> On 22 Nov 2016, at 12:13, Volker Simonis >>>>> wrote: >>>>> >>>>> Hi Daniel, >>>>> >>>>> thanks for your support - this problem really drives us crazy! >>>>> >>>>> What version of jtreg are you using? >>>>> If you are using a central one which was configured and build by >>>>> Oracle, could you please also try with the one from >>>>> https://adopt- >> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>> >>>>> ? >>>>> >>>>> Where can we find the generated policy files? It seems they get >>>>> deleted during test post-run cleanup phase (at least I could not find >>>>> any of them under JTwork). Is there a way to get a more detailed trace >>>>> on how JTreg executes testng and to leave all the generated files in >>>>> place after the test? >>>>> >>>>> I'm currently running the following JAXP test and get the same error >>>>> as described by Christoph: >>>>> >>>>> /tmp/jtreg/bin/jtreg -verbose:summary -jdk >>>>> /output-jdk9-hs-dbg/images/jdk/ >>>>> /OpenJDK/jdk9- >> hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jav >> a >>>>> >>>>> >>>>> What I don't really understand is how this is supposed to work at all, >>>>> because every JAXP test which runs with "-DrunSecMngr=true" will >>>>> execute the following code from JAXPPolicyManager: >>>>> >>>>> /* >>>>> * Install a SecurityManager along with a default Policy to allow >>>>> testNG to >>>>> * run when there is a security manager. >>>>> */ >>>>> private JAXPPolicyManager() { >>>>> // Backing up policy and security manager for restore >>>>> policyBackup = Policy.getPolicy(); >>>>> smBackup = System.getSecurityManager(); >>>>> >>>>> // Set customized policy >>>>> setDefaultPermissions(); >>>>> Policy.setPolicy(policy); >>>>> System.setSecurityManager(new SecurityManager()); >>>>> } >>>>> >>>>> Won't this code override the settings from the policy file which was >>>>> potentially installed by jtreg for testng? >>>>> >>>>> The setDefaultPermissions() sets some special permissions for testng, >>>>> but not "accessDeclaredMembers": >>>>> >>>>> private void setDefaultPermissions() { >>>>> //Permissions to set security manager and policy >>>>> addPermission(new SecurityPermission("getPolicy")); >>>>> addPermission(new SecurityPermission("setPolicy")); >>>>> addPermission(new RuntimePermission("setSecurityManager")); >>>>> //Properties that jtreg and TestNG require >>>>> addPermission(new >>>>> PropertyPermission("testng.show.stack.frames", "read")); >>>>> addPermission(new PropertyPermission("test.src", "read")); >>>>> addPermission(new PropertyPermission("test.classes", "read")); >>>>> addPermission(new >>>>> PropertyPermission("dataproviderthreadcount", "read")); >>>>> addPermission(new PropertyPermission("experimental", "read")); >>>>> } >>>>> >>>>> If I add the line: >>>>> >>>>> addPermission(new RuntimePermission("accessDeclaredMembers")); >>>>> >>>>> to setDefaultPermissions(), the test will succeed. >>>>> >>>>> I saw that an early version of "JDK-8067170: Enable security manager >>>>> on JAXP unit tests" contained that extra permission, but you objected >>>>> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- >> July/042520.html) >>>>> >>>>> and it was removed in the final version. >>>>> >>>>> Any more hints? >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> >>>>> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs >>>>> wrote: >>>>>> Hi Christoph, >>>>>> >>>>>> Is there anything funny with the place jtreg is installed? >>>>>> like: >>>>>> - path contains whitespaces >>>>>> - path is accessible through links or mount points... >>>>>> >>>>>> It seems clear that the issue here is that testng classes are >>>>>> missing some permissions, so I was wondering whether that could >>>>>> be caused by the actual path to testng.jar not matching the >>>>>> path injected in the policy file. >>>>>> >>>>>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >>>>>> >>>>>> $ cd jaxp/tests >>>>>> $ rm -r JT* >>>>>> $ jtreg -verbose:summary -ignore:quiet -jdk >>>>>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >>>>>> >>>>>> => the only test that fails is >>>>>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's >>>>>> expected >>>>>> (it's in the ProblemList.txt). >>>>>> >>>>>> The other thing to take care of, is not to run two jtreg process >>>>>> concurrently if they point to the same JT* directories. If you do >>>>>> that then you might experience weird failures with permissions >>>>>> issues (it seems to mess the policy files). >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> >>>>>> On 22/11/16 10:52, Langer, Christoph wrote: >>>>>>> >>>>>>> Yes, please find it here: >>>>>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>> Sent: Dienstag, 22. November 2016 11:03 >>>>>>>> To: Langer, Christoph >>>>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>>>>> jtreg- >>>>>>>> use at openjdk.java.net >>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>> ("java.lang.RuntimePermission" >>>>>>>> "accessDeclaredMembers") >>>>>>>> >>>>>>>> >>>>>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>>>>>>> >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Chris, >>>>>>>>> >>>>>>>>> thanks for this hint. However, we've already seen this change and >>>>>>>>> rebuilt >>>>>>>> >>>>>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Also, the download from https://adopt- >>>>>>>> >>>>>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>>>>> where I >>>>>>>> would >>>>>>>> suppose latest jtreg sources were used, don't help. >>>>>>>>> >>>>>>>>> >>>>>>>>> Am I missing something? >>>>>>>> >>>>>>>> >>>>>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>>>>>>> test? >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Christoph >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>>>>>> To: Langer, Christoph >>>>>>>>>> Cc: core-libs-dev at openjdk.java.net; >>>>>>>>>> code-tools-dev at openjdk.java.net; >>>>>>>>>> jtreg- >>>>>>>>>> use at openjdk.java.net >>>>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>>>> ("java.lang.RuntimePermission" >>>>>>>>>> "accessDeclaredMembers") >>>>>>>>>> >>>>>>>>>> Hi Christoph, >>>>>>>>>> >>>>>>>>>> Can you please ensure that your build of jtreg contains the fix for >>>>>>>>>> 7901792 >>>>>>>> >>>>>>>> [1]. >>>>>>>>>> >>>>>>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>>>>>> >>>>>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I'm currently struggling while running jtreg tests for the jaxp >>>>>>>>>>> depot. >>>>>>>>>>> >>>>>>>>>>> There are several tests that fail with the same symptom. I >>>>>>>>>>> always get >>>>>>>>>> >>>>>>>>>> exceptions like: >>>>>>>>>>> >>>>>>>>>>> java.security.AccessControlException: access denied >>>>>>>>>> >>>>>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>>>> >>>>>>>>>> >>>>>>>>>> ntext.java:471) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>>>> >>>>>>>>>> >>>>>>>>>> :894) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>>>> >>>>>>>>>> >>>>>>>>>> 48) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>>>>>> at >>>>>>>>>>> java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>>>>>> at >>>>>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>>>>>> at >>>>>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>>>> >>>>>>>>>> >>>>>>>>>> java:129) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>>>>>> >>>>>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>>>>>> at >>>>>>>>>>> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>>> >>>>>>>>>> >>>>>>>>>> 224) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>>> >>>>>>>>>> >>>>>>>>>> 188) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>>> >>>>>>>>>> Method) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>>>> >>>>>>>>>> >>>>>>>>>> AccessorImpl.java:62) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>>>> >>>>>>>>>> >>>>>>>>>> gMethodAccessorImpl.java:43) >>>>>>>>>>> >>>>>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>>>> >>>>>>>>>> >>>>>>>>>> ava:110) >>>>>>>>>>> >>>>>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>>>>> >>>>>>>>>>> For instance the test >>>>>>>>>> >>>>>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>>>>>>> this. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some >>>>>>>>>>> important >>>>>>>>>> >>>>>>>>>> permission for testing is missing with that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks for any help. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards >>>>>>>>>>> Christoph >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From daniel.fuchs at oracle.com Tue Nov 22 13:34:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 13:34:29 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: <2f394e9e-ac3e-5d6f-880b-2a84b55e8a2f@oracle.com> On 22/11/16 13:31, Daniel Fuchs wrote: > On 22/11/16 13:01, Langer, Christoph wrote: >> Hi, >> >> we are running jtreg with something like -jdk:> directory>/images/jdk. So would that be the exploded version or not? > > Yes - that's the image. Hmm... The failures I see with the exploded > build are different than what you have anyway. I mean 'yes that's the image and not the exploded build' The exploded build would be: -jdk:/jdk (sorry for not being clear) -- daniel From daniel.fuchs at oracle.com Tue Nov 22 14:31:26 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 14:31:26 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> Hi, The issue seems to be caused by changes in testng - but maybe that needs to be fixed in the JAXP test base. I could reproduce the issue by running the jaxp tests, after unsetting JT_HOME and running with https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz which has testng 6.9.11. When I dowloaded http://mvnrepository.com/artifact/org.testng/testng/6.9.5 and installed it in the jtreg install dir, the issue disappeared. best regards, -- daniel On 22/11/16 13:31, Daniel Fuchs wrote: >> Can it be that we are using a testng framework that is "too new" and >> maybe contains something which makes it not work in the jaxp scenario? > > When I call jtreg -version it reports: > TestNG: version 6.9.5 > > This seems different to what you are using. > Can you try with > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz > > without altering the version of testng? > > I had no problem running the tests with that version > of testng (except if I use the exploded build). > > Maybe the listener that the test uses to set up the security > manager is invoked in a different way (earlier?) with the > 6.9.10 version? From daniel.fuchs at oracle.com Tue Nov 22 14:44:00 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 14:44:00 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: Hi Volker, Our emails crossed each others :-) On 22/11/16 14:31, Volker Simonis wrote: > @Daniel: can I please kindly ask you to retry your tests with > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz > and make sure you are really using that version. If you really succeed > to successfully execute > javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jtr with > that version I would be pretty surprised (and speechless :) I arrived at the same conclusion. I finally noticed that I had JT_HOME set, which meant that whatever jtreg script I invoked it still linked back to my own install which had 6.9.5. best regards, -- daniel From daniel.fuchs at oracle.com Tue Nov 22 14:47:15 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 14:47:15 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: On 22/11/16 14:43, Langer, Christoph wrote: > But, as for fixing with the new testng, will you look into this? Shall I open a bug? I am unsure on how to fix this actually. The new testng must attempt to load the data provider after having invoked the listener, while the old testng probably did the opposite. Let me try some experiments... best regards, -- daniel From daniel.fuchs at oracle.com Tue Nov 22 16:24:17 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 16:24:17 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: Hi Christoph, I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 best regards, -- daniel On 22/11/16 14:47, Daniel Fuchs wrote: > On 22/11/16 14:43, Langer, Christoph wrote: >> But, as for fixing with the new testng, will you look into this? Shall >> I open a bug? From frank.yuan at oracle.com Wed Nov 23 04:41:10 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 23 Nov 2016 12:41:10 +0800 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars Message-ID: <02f901d24543$d2b37f70$781a7e50$@oracle.com> Hi All Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 This patch is fully same as Daniel provided except a few lines of additional cleaning, thanks to Daniel for providing the patch! Thanks Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.yuan at oracle.com Wed Nov 23 05:26:05 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 23 Nov 2016 13:26:05 +0800 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <2df3195f1faf474dbd8593c2af8e50bf@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> <2df3195f1faf474dbd! 8593c2af8e50bf@DEWDFE13 DE03.global.corp.sap> Message-ID: <030901d2454a$18c955b0$4a5c0110$@oracle.com> Hi Christoph and Volker I have been launching jdk and langtools tests with the new jtreg, will update to you once I get the result. Hope jaxp test is special because most of tests should control the Security Manager setting inside the test methods. Thanks Frank > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Langer, Christoph > Sent: Wednesday, November 23, 2016 3:51 AM > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") > > Thanks a lot Volker and Daniel for the big support to analyze and fix this. > > It seems to me that the proposed fix > (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like > the best that can be done at the moment. I agree that it would be nicer if > jtreg would leave the jtreg lib path as java property to be able to elevate > all of its contents. But the current proposal with a set of TEST_JARS of > jtreg, javatest and testng is probably sufficient for jaxp testing. > > The best thing to find out about other issues with the new version of testng > would certainly be if Oracle's internal version of jtreg be updated to use > the latest testng :-) > > Best regards > Christoph > > > > > -----Original Message----- > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > Sent: Dienstag, 22. November 2016 20:25 > > To: Daniel Fuchs > > Cc: Langer, Christoph ; code-tools- > > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > > use at openjdk.java.net > > Subject: Re: Issues running JAXP jtreg tests > > ("java.lang.RuntimePermission" > > "accessDeclaredMembers") > > > > Hi Daniel, > > > > thanks for your patch! > > > > I've meanwhile tried to better understand the root cause of the problem. > > > > I don't think that the invocation order of the data provider the > > listener have changed. If you look at the the two version 6.9.5 and > > 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly > > the same in both 6.9.5 [1] and 6.9.13 [2]: > > > > public void run() { > > beforeRun(); > > > > try { > > XmlTest test= getTest(); > > if(test.isJUnit()) { > > privateRunJUnit(test); > > } > > else { > > privateRun(test); > > } > > } > > finally { > > afterRun(); > > } > > > > I think the problem is in > > org.testng.internal.ClassHelper.getAvailableMethods() where we testng > > only collected the methods until (i.e. excluding) java.lang.Object in > > 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: > > > > 6.9.5 > > ===== > > public static Set getAvailableMethods(Class clazz) { > > Set methods = Sets.newHashSet(); > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > Class parent = clazz.getSuperclass(); > > while (Object.class != parent) { > > methods.addAll(extractMethods(clazz, parent, methods)); > > parent = parent.getSuperclass(); > > } > > > > 6.9.13 > > ===== > > public static Set getAvailableMethods(Class clazz) { > > Set methods = Sets.newHashSet(); > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > Class parent = clazz.getSuperclass(); > > while (null != parent) { > > methods.addAll(extractMethods(clazz, parent, methods)); > > parent = parent.getSuperclass(); > > } > > > > But java.lang.Object has a different class loader (null) compared to > > the test class (which is loaded by the application class loader), > > which leads to the AccessControlException with 6.9.13. > > > > As far as I can see, this was changed in testng 6.9.10 [5] to fix > > https://github.com/cbeust/testng/issues/876 > > > > This behavior may potentially also affect other tests which are > > running with a security manger so I'm not sure you fix will help for > > all of them. And I also wonder why this hasn't been detected by other > > who run testng with a security manager (but maybe nobody is doing that > > :) > > > > Regards, > > Volker > > > > [1] https://github.com/cbeust/testng/blob/testng- > > 6.9.5/src/main/java/org/testng/TestRunner.java > > [2] > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu > > nner.java > > [3] https://github.com/cbeust/testng/blob/testng- > > 6.9.5/src/main/java/org/testng/internal/ClassHelper.java > > [4] > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna > > l/ClassHelper.java > > [5] > > https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b > > ff7716fca29daaab > > > > > > On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs > > wrote: > > > Hi Christoph, > > > > > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > > > best regards, > > > > > > -- daniel > > > > > > > > > On 22/11/16 14:47, Daniel Fuchs wrote: > > >> > > >> On 22/11/16 14:43, Langer, Christoph wrote: > > >>> > > >>> But, as for fixing with the new testng, will you look into this? Shall > > >>> I open a bug? > > > > > > From daniel.fuchs at oracle.com Wed Nov 23 13:59:20 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Nov 2016 13:59:20 +0000 Subject: Did the tests fail due to TestNG dataprovider parameter type check? In-Reply-To: <036a01d24564$0bc56e20$23504a60$@oracle.com> References: <036a01d24564$0bc56e20$23504a60$@oracle.com> Message-ID: <637303db-c014-4f19-6e38-3182c17aae34@oracle.com> Hi Frank, I ran only the tests under jaxp/tests/javax - and one test was failing (DurationTest) with a similar error (something about a mismatch between Integer & Long in data provider). This looked to be completely unrelated to the permission changes, so I thought it would be better to investigate it as a separate issue. The failure in the Duration test looked simpler - so it might be a good place to look at to try and figure out what is going on. best regards, -- daniel On 23/11/16 08:31, Frank Yuan wrote: > Hi Jon > > I run the whole jdk regression tests with jtreg-4.2-b03 [1], and then found lots of tests in different test groups failed with the error message like following: > test test.java.time.format.TestNumberPrinter.test_pad_ALWAYS(): failure > org.testng.internal.reflect.MethodMatcherException: > Data provider mismatch > Method: test_pad_ALWAYS([Parameter{index=0, type=int, declaredAnnotations=[]}, Parameter{index=1, type=int, declaredAnnotations=[]}, Parameter{index=2, type=long, declaredAnnotations=[]}, Parameter{index=3, type=java.lang.String, declaredAnnotations=[]}]) > Arguments: [(java.lang.Integer)1,(java.lang.Integer)1,(java.lang.Integer)-10,null] > at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) > at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > at org.testng.TestRunner.privateRun(TestRunner.java:778) > at org.testng.TestRunner.run(TestRunner.java:632) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > 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:1225) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1150) > at org.testng.TestNG.runSuites(TestNG.java:1075) > at org.testng.TestNG.run(TestNG.java:1047) > at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) > at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:184) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:537) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.base/java.lang.Thread.run(Thread.java:844) > > > This test methd signature is: > public void test_pad_ALWAYS(int minPad, int maxPad, long value, String result) > > The provider return the following data > Object[][] provider_pad() { > return new Object[][] { > {1, 1, -10, null}, > {1, 1, -9, "9"}, > {1, 1, -1, "1"}, > ... > > However, I got message "Cannot find class java/lang/reflect/JTRegModuleHelper.class to init patch directory" when I run jtreg, although I didn't find any code related to testng dataprovider in jtreg source, I would double confirm with you if this is a definite issue or anything I made incorrectly? > > To Christoph > > Except above issue, I didn't find any other issue in jdk and langtools repo so far. > > > [1] https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz > > > Thanks > Frank > >> -----Original Message----- >> From: Langer, Christoph [mailto:christoph.langer at sap.com] >> Sent: Wednesday, November 23, 2016 3:41 PM >> To: Frank Yuan >> Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg-use at openjdk.java.net; 'Volker Simonis'; 'Daniel Fuchs' >> Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") >> >> Thanks, Frank. >> >> we run scheduled jtreg tests for jdk every night so we should have encountered issues if there were some. But langtools could be interesting, I >> don't think those run automatically for OpenJDK in our environment. >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: Frank Yuan [mailto:frank.yuan at oracle.com] >>> Sent: Mittwoch, 23. November 2016 06:26 >>> To: Langer, Christoph ; 'Volker Simonis' >>> ; 'Daniel Fuchs' >>> Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- >>> use at openjdk.java.net >>> Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >>> "accessDeclaredMembers") >>> >>> Hi Christoph and Volker >>> >>> I have been launching jdk and langtools tests with the new jtreg, will update to >>> you once I get the result. >>> Hope jaxp test is special because most of tests should control the Security >>> Manager setting inside the test methods. >>> >>> Thanks >>> Frank >>> >>> >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >>> Behalf Of Langer, Christoph >>>> Sent: Wednesday, November 23, 2016 3:51 AM >>>> Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >>> "accessDeclaredMembers") >>>> >>>> Thanks a lot Volker and Daniel for the big support to analyze and fix this. >>>> >>>> It seems to me that the proposed fix >>>> (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like >>>> the best that can be done at the moment. I agree that it would be nicer if >>>> jtreg would leave the jtreg lib path as java property to be able to elevate >>>> all of its contents. But the current proposal with a set of TEST_JARS of >>>> jtreg, javatest and testng is probably sufficient for jaxp testing. >>>> >>>> The best thing to find out about other issues with the new version of testng >>>> would certainly be if Oracle's internal version of jtreg be updated to use >>>> the latest testng :-) >>>> >>>> Best regards >>>> Christoph >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Volker Simonis [mailto:volker.simonis at gmail.com] >>>>> Sent: Dienstag, 22. November 2016 20:25 >>>>> To: Daniel Fuchs >>>>> Cc: Langer, Christoph ; code-tools- >>>>> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- >>>>> use at openjdk.java.net >>>>> Subject: Re: Issues running JAXP jtreg tests >>>>> ("java.lang.RuntimePermission" >>>>> "accessDeclaredMembers") >>>>> >>>>> Hi Daniel, >>>>> >>>>> thanks for your patch! >>>>> >>>>> I've meanwhile tried to better understand the root cause of the problem. >>>>> >>>>> I don't think that the invocation order of the data provider the >>>>> listener have changed. If you look at the the two version 6.9.5 and >>>>> 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly >>>>> the same in both 6.9.5 [1] and 6.9.13 [2]: >>>>> >>>>> public void run() { >>>>> beforeRun(); >>>>> >>>>> try { >>>>> XmlTest test= getTest(); >>>>> if(test.isJUnit()) { >>>>> privateRunJUnit(test); >>>>> } >>>>> else { >>>>> privateRun(test); >>>>> } >>>>> } >>>>> finally { >>>>> afterRun(); >>>>> } >>>>> >>>>> I think the problem is in >>>>> org.testng.internal.ClassHelper.getAvailableMethods() where we testng >>>>> only collected the methods until (i.e. excluding) java.lang.Object in >>>>> 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: >>>>> >>>>> 6.9.5 >>>>> ===== >>>>> public static Set getAvailableMethods(Class clazz) { >>>>> Set methods = Sets.newHashSet(); >>>>> methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); >>>>> >>>>> Class parent = clazz.getSuperclass(); >>>>> while (Object.class != parent) { >>>>> methods.addAll(extractMethods(clazz, parent, methods)); >>>>> parent = parent.getSuperclass(); >>>>> } >>>>> >>>>> 6.9.13 >>>>> ===== >>>>> public static Set getAvailableMethods(Class clazz) { >>>>> Set methods = Sets.newHashSet(); >>>>> methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); >>>>> >>>>> Class parent = clazz.getSuperclass(); >>>>> while (null != parent) { >>>>> methods.addAll(extractMethods(clazz, parent, methods)); >>>>> parent = parent.getSuperclass(); >>>>> } >>>>> >>>>> But java.lang.Object has a different class loader (null) compared to >>>>> the test class (which is loaded by the application class loader), >>>>> which leads to the AccessControlException with 6.9.13. >>>>> >>>>> As far as I can see, this was changed in testng 6.9.10 [5] to fix >>>>> https://github.com/cbeust/testng/issues/876 >>>>> >>>>> This behavior may potentially also affect other tests which are >>>>> running with a security manger so I'm not sure you fix will help for >>>>> all of them. And I also wonder why this hasn't been detected by other >>>>> who run testng with a security manager (but maybe nobody is doing that >>>>> :) >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> [1] https://github.com/cbeust/testng/blob/testng- >>>>> 6.9.5/src/main/java/org/testng/TestRunner.java >>>>> [2] >>>>> >>> https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu >>>>> nner.java >>>>> [3] https://github.com/cbeust/testng/blob/testng- >>>>> 6.9.5/src/main/java/org/testng/internal/ClassHelper.java >>>>> [4] >>>>> >>> https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna >>>>> l/ClassHelper.java >>>>> [5] >>>>> >>> https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b >>>>> ff7716fca29daaab >>>>> >>>>> >>>>> On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs >>>>> wrote: >>>>>> Hi Christoph, >>>>>> >>>>>> I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> >>>>>> On 22/11/16 14:47, Daniel Fuchs wrote: >>>>>>> >>>>>>> On 22/11/16 14:43, Langer, Christoph wrote: >>>>>>>> >>>>>>>> But, as for fixing with the new testng, will you look into this? Shall >>>>>>>> I open a bug? >>>>>> >>>>>> > > From daniel.fuchs at oracle.com Wed Nov 23 14:00:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Nov 2016 14:00:13 +0000 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <02f901d24543$d2b37f70$781a7e50$@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> Message-ID: <5107a701-1cea-5017-2afb-c4a2031c4058@oracle.com> Hi Frank, Thanks for taking this on. Looks good to me. -- daniel On 23/11/16 04:41, Frank Yuan wrote: > Hi All > > > > Would you like to review > http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > This patch is fully same as Daniel provided except a few lines of > additional cleaning, thanks to Daniel for providing the patch! > > > > Thanks > > Frank > > > From huizhe.wang at oracle.com Wed Nov 23 17:47:39 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 23 Nov 2016 09:47:39 -0800 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <5107a701-1cea-5017-2afb-c4a2031c4058@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> <5107a701-1cea-5017-2afb-c4a2031c4058@oracle.com> Message-ID: <5835D63B.2090609@oracle.com> +1. Thanks Frank! -Joe On 11/23/16, 6:00 AM, Daniel Fuchs wrote: > Hi Frank, > > Thanks for taking this on. > Looks good to me. > > -- daniel > > On 23/11/16 04:41, Frank Yuan wrote: >> Hi All >> >> >> >> Would you like to review >> http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 >> >> >> >> This patch is fully same as Daniel provided except a few lines of >> additional cleaning, thanks to Daniel for providing the patch! >> >> >> >> Thanks >> >> Frank >> >> >> > From jonathan.gibbons at oracle.com Wed Nov 23 20:26:09 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 23 Nov 2016 12:26:09 -0800 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <02f901d24543$d2b37f70$781a7e50$@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> Message-ID: <5835FB61.8090707@oracle.com> Frank, More recent builds of testng.jar, such as the builds available on Maven, have separated out the jcommander component so that two jar files are required: testng.jar and jcommander.jar. You should consider taking jcommander.jar into account. This will be more important/noticeable to folk outside Oracle who build their own copy of jtreg to use. -- Jon On 11/22/2016 08:41 PM, Frank Yuan wrote: > > Hi All > > Would you like to review > http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/ > ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 > > This patch is fully same as Daniel provided except a few lines of > additional cleaning, thanks to Daniel for providing the patch! > > Thanks > > Frank > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Nov 23 20:47:32 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 23 Nov 2016 12:47:32 -0800 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <2df3195f1faf474dbd8593c2af8e50bf@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> <2df3195f1faf474dbd8593c2af8e50bf@DEWDFE13DE03.global.corp.sap> Message-ID: <58360064.1070104@oracle.com> On 11/22/2016 11:50 AM, Langer, Christoph wrote: > I agree that it would be nicer if jtreg would leave the jtreg lib path as java property to be able to elevate all of its contents. But the current proposal with a set of TEST_JARS of jtreg, javatest and testng is probably sufficient for jaxp testing. https://bugs.openjdk.java.net/browse/CODETOOLS-7901844 -- Jon From david.holmes at oracle.com Wed Nov 23 23:58:53 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Nov 2016 09:58:53 +1000 Subject: running jtreg for jdk8u In-Reply-To: <1267985694.5772246.1479515243638@mail.yahoo.com> References: <593282355.3620607.1477526302474.ref@mail.yahoo.com> <593282355.3620607.1477526302474@mail.yahoo.com> <701660426.3065234.1477956972399@mail.yahoo.com> <1267985694.5772246.1479515243638@mail.yahoo.com> Message-ID: <604587a9-2e62-7692-ca29-5bdaf58c1017@oracle.com> On 19/11/2016 10:27 AM, Manuela Grindei wrote: > > > Hi everyone, > > I'm trying to test the fix I created for JDK-8154066 > , but I cannot run > jtreg for jdk8u from VirtualBox. I have created the images, but when > starting jtreg, it keeps throwing an error saying that it cannot find JDK. > > I'm trying to run: > > $JTREG_HOME/bin/jtreg > -jdk:build/linux-x86_64-normal-server-release/images/jdk jdk/test/:compact1. If you look at your screenshots the JDK image directory is "j2sdk-image" not "jdk" David > I took some screenshots of the directories I currently have after > creating the images and I was wondering if you could help me. > > > Thank you, > > Manuela Grindei > > > > > From jonathan.gibbons at oracle.com Thu Nov 24 00:04:39 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 23 Nov 2016 16:04:39 -0800 Subject: running jtreg for jdk8u In-Reply-To: <604587a9-2e62-7692-ca29-5bdaf58c1017@oracle.com> References: <593282355.3620607.1477526302474.ref@mail.yahoo.com> <593282355.3620607.1477526302474@mail.yahoo.com> <701660426.3065234.1477956972399@mail.yahoo.com> <1267985694.5772246.1479515243638@mail.yahoo.com> <604587a9-2e62-7692-ca29-5bdaf58c1017@oracle.com> Message-ID: <58362E97.3040306@oracle.com> Hi David, These messages from Manuela got stuck in the jtreg moderation queue for some reason and have only now been flushed. After some direct email exchange, I believe the problems have been resolved. Ultimately, the root cause was a conflict between a pre-configured virtual image and a newer version of jtreg. -- Jon On 11/23/2016 03:58 PM, David Holmes wrote: > On 19/11/2016 10:27 AM, Manuela Grindei wrote: >> >> >> Hi everyone, >> >> I'm trying to test the fix I created for JDK-8154066 >> , but I cannot run >> jtreg for jdk8u from VirtualBox. I have created the images, but when >> starting jtreg, it keeps throwing an error saying that it cannot find >> JDK. >> >> I'm trying to run: >> >> $JTREG_HOME/bin/jtreg >> -jdk:build/linux-x86_64-normal-server-release/images/jdk >> jdk/test/:compact1. > > If you look at your screenshots the JDK image directory is > "j2sdk-image" not "jdk" > > David > >> I took some screenshots of the directories I currently have after >> creating the images and I was wondering if you could help me. >> >> >> Thank you, >> >> Manuela Grindei >> >> >> >> >> From shrinivas.joshi at oracle.com Thu Nov 24 00:52:39 2016 From: shrinivas.joshi at oracle.com (Shrinivas Joshi) Date: Wed, 23 Nov 2016 16:52:39 -0800 Subject: jdk jtreg tests partial completion Message-ID: <583639D7.4050609@oracle.com> Hi, I am trying to execute all of the 'jdk' project jtreg tests on a SPARC-T4 system with 64 vcpus @2.8GHz that has 128GB memory. Following is the command-line I am using: /path/to/jtreg_4.2/bin/jtreg -testjdk:/path/to/jdk_repo/build/solaris-sparcv9-normal-server-release/images/jdk -va -agentvm -conc:8 -timeoutFactor:30 -automatic -ignore:quiet -r:/path/to/JTReport/ -w:/path/to/JTWork/ -exclude:/path/to/jdk_repo/jdk/test/ProblemList.txt -nativepath:/path/to/jdk_repo/build/solaris-sparcv9-normal-server-release/images/test/jdk/jtreg/native/ jdk/test The jdk_repo is based off of http://hg.openjdk.java.net/jdk9/hs/ It executes 3843 tests (out of ~11K) and then seems to stop silently without any apparent indication of error. In one of the runs, the last executed test case (jdk/test/com/sun/net/httpserver/Test7a.java) completes successfully. In another run, the last executed test case (jdk/test/com/sun/net/httpserver/Test8a.java) failed with "java.io.IOException: Error writing to server"; see [1]. Thus, no report gets generated in JTReport dir. Please let me know what I should look for to debug this issue further. So far, looking into JTWork dir has not provided any concrete clues. Also, I execute this as a background job and hence don't want to include any of the AWT or other tests that require manual inputs. I thought -automatic is the way to disable those, but there are certain tests that fail with "Execution failed: `main' threw exception: java.awt.AWTError: Can't connect to X11 window server using 'localhost:10.0' as the value of the DISPLAY variable". Is there something I am missing here. Thanks, -Shrinivas [1]: java.io.IOException: Error writing to server at java.base/sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:696) at java.base/sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:708) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1556) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1463) at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:319) at Test8a.main(Test8a.java:78) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:537) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) From frank.yuan at oracle.com Thu Nov 24 02:29:24 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 24 Nov 2016 10:29:24 +0800 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <5835FB61.8090707@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> <5835FB61.8090707@oracle.com> Message-ID: <013b01d245fa$95b17020$c1145060$@oracle.com> Hi Jon Thank you for your advice! Please check the update http://cr.openjdk.java.net/~fyuan/8170192/webrev.01/ , which contains jcommander.jar and removes the extra blank lines following Christoph's suggestion. Frank From: Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com] Sent: Thursday, November 24, 2016 4:26 AM Subject: Re: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars Frank, More recent builds of testng.jar, such as the builds available on Maven, have separated out the jcommander component so that two jar files are required: testng.jar and jcommander.jar. You should consider taking jcommander.jar into account. This will be more important/noticeable to folk outside Oracle who build their own copy of jtreg to use. -- Jon On 11/22/2016 08:41 PM, Frank Yuan wrote: Hi All Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/ ? Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 This patch is fully same as Daniel provided except a few lines of additional cleaning, thanks to Daniel for providing the patch! Thanks Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Thu Nov 24 10:22:54 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 24 Nov 2016 10:22:54 +0000 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <013b01d245fa$95b17020$c1145060$@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> <5835FB61.8090707@oracle.com> <013b01d245fa$95b17020$c1145060$@oracle.com> Message-ID: <3573f887-9e8f-2b09-3ef8-f644794ebe3c@oracle.com> Hi Frank, Looks good to me. Thanks for the advice Jon! best regards, -- daniel On 24/11/16 02:29, Frank Yuan wrote: > Hi Jon > > > > Thank you for your advice! > > > > Please check the update > http://cr.openjdk.java.net/~fyuan/8170192/webrev.01/ , which contains > jcommander.jar and removes the extra blank lines following Christoph?s > suggestion. > > > > Frank > > > > *From:*Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com] > *Sent:* Thursday, November 24, 2016 4:26 AM > *Subject:* Re: RFR JDK-8170192 [JAXP] [TESTBUG] > test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should > grant permissions to jtreg, javatest, and testng jars > > > > Frank, > > More recent builds of testng.jar, such as the builds available on > Maven, have separated out the jcommander component so that two jar > files are required: testng.jar and jcommander.jar. > > You should consider taking jcommander.jar into account. This will be > more important/noticeable to folk outside Oracle who build their own > copy of jtreg to use. > > -- Jon > > On 11/22/2016 08:41 PM, Frank Yuan wrote: > > Hi All > > > > Would you like to review > http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/ > ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > This patch is fully same as Daniel provided except a few lines of > additional cleaning, thanks to Daniel for providing the patch! > > > > Thanks > > Frank > > > > > From frank.yuan at oracle.com Fri Nov 25 03:17:38 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Fri, 25 Nov 2016 11:17:38 +0800 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <5F4F601B-8AF1-4A1C-BDB7-88C96F19998B@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> <5835FB61.8090707@oracle.com> <013b01d245fa$95b17020$c1145060$@oracle.com> <5F4F601B-8AF1-4A1C-BDB7-88C96F19998B@oracle.com> Message-ID: <00b501d246ca$7c0053a0$7400fae0$@oracle.com> Thank you! Pushed. Frank From: Lance Andersen [mailto:lance.andersen at oracle.com] Sent: Thursday, November 24, 2016 8:58 PM Subject: Re: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars Looks good Frank Best Lance On Nov 23, 2016, at 9:29 PM, Frank Yuan > wrote: Hi Jon Thank you for your advice! Please check the update http://cr.openjdk.java.net/~fyuan/8170192/webrev.01/ , which contains jcommander.jar and removes the extra blank lines following Christoph's suggestion. Frank From: Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com] Sent: Thursday, November 24, 2016 4:26 AM Subject: Re: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars Frank, More recent builds of testng.jar, such as the builds available on Maven, have separated out the jcommander component so that two jar files are required: testng.jar and jcommander.jar. You should consider taking jcommander.jar into account. This will be more important/noticeable to folk outside Oracle who build their own copy of jtreg to use. -- Jon On 11/22/2016 08:41 PM, Frank Yuan wrote: Hi All Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/ ? Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 This patch is fully same as Daniel provided except a few lines of additional cleaning, thanks to Daniel for providing the patch! Thanks Frank Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 658 bytes Desc: not available URL: From lance.andersen at oracle.com Thu Nov 24 12:58:28 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 24 Nov 2016 12:58:28 -0000 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <013b01d245fa$95b17020$c1145060$@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> <5835FB61.8090707@oracle.com> <013b01d245fa$95b17020$c1145060$@oracle.com> Message-ID: <5F4F601B-8AF1-4A1C-BDB7-88C96F19998B@oracle.com> Looks good Frank Best Lance > On Nov 23, 2016, at 9:29 PM, Frank Yuan wrote: > > Hi Jon > > > > Thank you for your advice! > > > > Please check the update http://cr.openjdk.java.net/~fyuan/8170192/webrev.01/ , which contains jcommander.jar and removes the extra > blank lines following Christoph's suggestion. > > > > Frank > > > > From: Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com] > Sent: Thursday, November 24, 2016 4:26 AM > Subject: Re: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions > to jtreg, javatest, and testng jars > > > > Frank, > > More recent builds of testng.jar, such as the builds available on Maven, have separated out the jcommander component so that two > jar files are required: testng.jar and jcommander.jar. > > You should consider taking jcommander.jar into account. This will be more important/noticeable to folk outside Oracle who build > their own copy of jtreg to use. > > -- Jon > > On 11/22/2016 08:41 PM, Frank Yuan wrote: > > Hi All > > > > Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/ > ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > This patch is fully same as Daniel provided except a few lines of additional cleaning, thanks to Daniel for providing the patch! > > > > Thanks > > Frank > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: