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