Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Jonathan Gibbons]

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

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Langer, Christoph]

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.y...@oracle.com]
> Sent: Mittwoch, 23. November 2016 06:26
> To: Langer, Christoph ; 'Volker Simonis'
> ; 'Daniel Fuchs' 
> Cc: code-tools-...@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 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-boun...@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.simo...@gmail.com]
> > > Sent: Dienstag, 22. November 2016 20:25
> > > To: Daniel Fuchs 
> > > Cc: Langer, Christoph ; 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 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 

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Frank Yuan]

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-boun...@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.simo...@gmail.com]
> > Sent: Dienstag, 22. November 2016 20:25
> > To: Daniel Fuchs 
> > Cc: Langer, Christoph ; 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 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/tes

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Langer, Christoph]

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 
> Cc: Langer, Christoph ; 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 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?
> >
> >

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Volker Simonis]

On Tue, Nov 22, 2016 at 8:08 PM, Joe Wang  wrote:
> Daniel, you're awesome!  This could have potentially been a frustration to
> anyone with a newer testng, as Christoph and Volker have experienced. This
> issue really needs to be fixed immediately :-)
>

And Oracle should try to use the same tools versions as the community :)
As mentioned earlier in this thread, nobody can currently build jtreg
with testng 6.9.5 as described on the jtreg page :(

> Joe
>
>
> On 11/22/16, 7:58 AM, Daniel Fuchs wrote:
>>
>> On 22/11/16 14:51, Langer, Christoph wrote:
>>>
>>> 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?
>>
>>
>> That's what I was prototyping.
>> The patch below seem to fix the issue - but it's a bit ugly.
>> (note I just tested it with XSLTFunctionsTest - you need to
>>  rm -r JT* after applying to the jaxp repo)
>>
>> It might be less ugly if we had a system property set
>> by jtreg to point at /lib - as we could use that
>> to predict the code source location - but I don't think
>> we do.
>>
>> -- daniel
>>
>> diff --git a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
>> b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
>> --- a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
>> +++ b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
>> @@ -23,6 +23,7 @@
>>  package jaxp.library;
>>
>>
>> +import java.net.URL;
>>  import java.security.CodeSource;
>>  import java.security.Permission;
>>  import java.security.PermissionCollection;
>> @@ -34,6 +35,7 @@
>>  import java.util.HashMap;
>>  import java.util.Map;
>>  import java.util.PropertyPermission;
>> +import java.util.Set;
>>  import java.util.StringJoiner;
>>
>>
>> @@ -163,6 +165,8 @@
>>   * JAXP concrete classes.
>>   */
>>  class TestPolicy extends Policy {
>> +private final static Set TEST_JARS =
>> + Set.of("jtreg.jar", "javatest.jar", "testng.jar");
>>  private final PermissionCollection permissions = new Permissions();
>>
>>  private ThreadLocal> transientPermissions =
>> new ThreadLocal<>();
>> @@ -221,9 +225,30 @@
>>
>>  if (permissions.implies(perm))
>>  return true;
>> -else
>> +else {
>> +boolean before = allowAll();
>> +String path = null;
>> +try {
>> +CodeSource cs = (domain == null) ? null :
>> domain.getCodeSource();
>> +URL loc = (cs == null) ? null : cs.getLocation();
>> +path = (loc == null) ? null : loc.getPath();
>> +} finally {
>> +setAllowAll(before);
>> +}
>> +if (path != null && TEST_JARS.stream()
>> +.filter(path::endsWith)
>> +.findAny()
>> +.isPresent()) {
>> +return true;
>> +} else {
>>  return tmpImplies(perm);
>>  }
>> +}
>> +}
>> +
>> +
>> +
>>
>>  /*
>>   * Add a temporary permission in current thread context. This won't
>> impact
>>
>

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Volker Simonis]

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?
>
>

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Joe Wang]

Daniel, you're awesome!  This could have potentially been a frustration 
to anyone with a newer testng, as Christoph and Volker have experienced. 
This issue really needs to be fixed immediately :-)


Joe

On 11/22/16, 7:58 AM, Daniel Fuchs wrote:

On 22/11/16 14:51, Langer, Christoph wrote:
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?


That's what I was prototyping.
The patch below seem to fix the issue - but it's a bit ugly.
(note I just tested it with XSLTFunctionsTest - you need to
 rm -r JT* after applying to the jaxp repo)

It might be less ugly if we had a system property set
by jtreg to point at /lib - as we could use that
to predict the code source location - but I don't think
we do.

-- daniel

diff --git 
a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java 
b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java

--- a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
+++ b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
@@ -23,6 +23,7 @@
 package jaxp.library;


+import java.net.URL;
 import java.security.CodeSource;
 import java.security.Permission;
 import java.security.PermissionCollection;
@@ -34,6 +35,7 @@
 import java.util.HashMap;
 import java.util.Map;
 import java.util.PropertyPermission;
+import java.util.Set;
 import java.util.StringJoiner;


@@ -163,6 +165,8 @@
  * JAXP concrete classes.
  */
 class TestPolicy extends Policy {
+private final static Set TEST_JARS =
+ Set.of("jtreg.jar", "javatest.jar", "testng.jar");
 private final PermissionCollection permissions = new Permissions();

 private ThreadLocal> 
transientPermissions = new ThreadLocal<>();

@@ -221,9 +225,30 @@

 if (permissions.implies(perm))
 return true;
-else
+else {
+boolean before = allowAll();
+String path = null;
+try {
+CodeSource cs = (domain == null) ? null : 
domain.getCodeSource();

+URL loc = (cs == null) ? null : cs.getLocation();
+path = (loc == null) ? null : loc.getPath();
+} finally {
+setAllowAll(before);
+}
+if (path != null && TEST_JARS.stream()
+.filter(path::endsWith)
+.findAny()
+.isPresent()) {
+return true;
+} else {
 return tmpImplies(perm);
 }
+}
+}
+
+
+

 /*
  * Add a temporary permission in current thread context. This 
won't impact

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

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?

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

On 22/11/16 14:51, Langer, Christoph wrote:

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?


That's what I was prototyping.
The patch below seem to fix the issue - but it's a bit ugly.
(note I just tested it with XSLTFunctionsTest - you need to
 rm -r JT* after applying to the jaxp repo)

It might be less ugly if we had a system property set
by jtreg to point at /lib - as we could use that
to predict the code source location - but I don't think
we do.

-- daniel

diff --git 
a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java 
b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java

--- a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
+++ b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
@@ -23,6 +23,7 @@
 package jaxp.library;


+import java.net.URL;
 import java.security.CodeSource;
 import java.security.Permission;
 import java.security.PermissionCollection;
@@ -34,6 +35,7 @@
 import java.util.HashMap;
 import java.util.Map;
 import java.util.PropertyPermission;
+import java.util.Set;
 import java.util.StringJoiner;


@@ -163,6 +165,8 @@
  * JAXP concrete classes.
  */
 class TestPolicy extends Policy {
+private final static Set TEST_JARS =
+ Set.of("jtreg.jar", "javatest.jar", "testng.jar");
 private final PermissionCollection permissions = new Permissions();

 private ThreadLocal> transientPermissions 
= new ThreadLocal<>();

@@ -221,9 +225,30 @@

 if (permissions.implies(perm))
 return true;
-else
+else {
+boolean before = allowAll();
+String path = null;
+try {
+CodeSource cs = (domain == null) ? null : 
domain.getCodeSource();

+URL loc = (cs == null) ? null : cs.getLocation();
+path = (loc == null) ? null : loc.getPath();
+} finally {
+setAllowAll(before);
+}
+if (path != null && TEST_JARS.stream()
+.filter(path::endsWith)
+.findAny()
+.isPresent()) {
+return true;
+} else {
 return tmpImplies(perm);
 }
+}
+}
+
+
+

 /*
  * Add a temporary permission in current thread context. This 
won't impact

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Langer, Christoph]

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.fu...@oracle.com]
> Sent: Dienstag, 22. November 2016 15:47
> To: Langer, Christoph 
> Cc: code-tools-...@openjdk.java.net; core-libs-dev@openjdk.java.net; jtreg-
> u...@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

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Langer, Christoph]

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.fu...@oracle.com]
> Sent: Dienstag, 22. November 2016 15:31
> To: Langer, Christoph ; Volker Simonis
> 
> Cc: code-tools-...@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,
> 
> 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
> 

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

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

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

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

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Volker Simonis]

m.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.fu...@oracle.com]
>>> Sent: Dienstag, 22. November 2016 13:42
>>> To: Volker Simonis ; Langer, Christoph
>>> ; Langer, Christoph 
>>> Cc: Chris Hegarty ; 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 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 herri

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

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?

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

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:/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

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

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.fu...@oracle.com]
Sent: Dienstag, 22. November 2016 13:42
To: Volker Simonis ; Langer, Christoph
; Langer, Christoph 
Cc: Chris Hegarty ; 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 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() {
 

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Langer, Christoph]

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.fu...@oracle.com]
> Sent: Dienstag, 22. November 2016 13:42
> To: Volker Simonis ; Langer, Christoph
> ; Langer, Christoph 
> Cc: Chris Hegarty ; 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 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
> 

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

 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.hega...@oracle.com]
Sent: Dienstag, 22. November 2016 11:03
To: Langer, Christoph 
Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net;
jtreg-
u...@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.hega...@oracle.com]
Sent: Dienstag, 22. November 2016 10:08
To: Langer, Christoph 
Cc: core-libs-dev@openjdk.java.net;
code-tools-...@openjdk.java.net;
jtreg-
u...@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.invo

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

erver-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.hega...@oracle.com]
Sent: Dienstag, 22. November 2016 11:03
To: Langer, Christoph 
Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net;
jtreg-
u...@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.hega...@oracle.com]
Sent: Dienstag, 22. November 2016 10:08
To: Langer, Christoph 
Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net;
jtreg-
u...@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.javat

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Chris Hegarty]

t; 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.hega...@oracle.com]
>>>> Sent: Dienstag, 22. November 2016 11:03
>>>> To: Langer, Christoph 
>>>> Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net;
>>>> jtreg-
>>>> u...@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.hega...@oracle.com]
>>>>>> Sent: Dienstag, 22. November 2016 10:08
>>>>>> To: Langer, Christoph 
>>>>>> Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net;
>>>>>> jtreg-
>>>>>> u...@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
>>>>>> 
>>>

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Volker Simonis]

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.hega...@oracle.com]
>>> Sent: Dienstag, 22. November 2016 11:03
>>> To: Langer, Christoph 
>>> Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net;
>>> jtreg-
>>> u...@openjdk.java.net
>>> Subject: Re: Issues running JAXP jtreg tests
>>> ("java.lang.RuntimePermission"
>>> "accessD

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Langer, Christoph]

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.fu...@oracle.com]
> Sent: Dienstag, 22. November 2016 12:25
> To: Langer, Christoph ; Chris Hegarty
> 
> Cc: code-tools-...@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 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.hega...@oracle.com]
> >> Sent: Dienstag, 22. November 2016 11:03
> >> To: Langer, Christoph 
> >> Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net; jtreg-
> >> u...@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.hega...@oracle.com]
> >>>> Sent: Dienstag, 22. November 2016 10:08
> >>>> To: Langer, Christoph 
> >>>> Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net;
> jtreg-
> >>>> u...@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:
> >&

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Daniel Fuchs]

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.hega...@oracle.com]
Sent: Dienstag, 22. November 2016 11:03
To: Langer, Christoph 
Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net; jtreg-
u...@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.hega...@oracle.com]
Sent: Dienstag, 22. November 2016 10:08
To: Langer, Christoph 
Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net; jtreg-
u...@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.

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Langer, Christoph]

Yes, please find it here: 
http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr


> -Original Message-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sent: Dienstag, 22. November 2016 11:03
> To: Langer, Christoph 
> Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net; jtreg-
> u...@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.hega...@oracle.com]
> >> Sent: Dienstag, 22. November 2016 10:08
> >> To: Langer, Christoph 
> >> Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net; jtreg-
> >> u...@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)
> >>>

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Chris Hegarty]

> 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.hega...@oracle.com]
>> Sent: Dienstag, 22. November 2016 10:08
>> To: Langer, Christoph 
>> Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net; jtreg-
>> u...@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
> 

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Langer, Christoph]

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.hega...@oracle.com]
> Sent: Dienstag, 22. November 2016 10:08
> To: Langer, Christoph 
> Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net; jtreg-
> u...@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

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Chris Hegarty]

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

Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

[Langer, Christoph]

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