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.simo...@gmail.com] > Sent: Dienstag, 22. November 2016 20:25 > To: Daniel Fuchs <daniel.fu...@oracle.com> > Cc: Langer, Christoph <christoph.lan...@sap.com>; code-tools- > d...@openjdk.java.net; core-libs-dev@openjdk.java.net; jtreg- > u...@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<Method> getAvailableMethods(Class<?> clazz) { > Set<Method> 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<Method> getAvailableMethods(Class<?> clazz) { > Set<Method> 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 <daniel.fu...@oracle.com> > 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? > > > >
