Comment 1 Markus Tiede 2014-12-09 05:09:59 EST

E.g. this happens if our RC Swing Adapter Factory extension is deployed and the SimpleAdder is supposed to start:

AUT:java.lang.reflect.InvocationTargetException
AUT:    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
AUT:    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
AUT:    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
AUT:    at java.lang.reflect.Method.invoke(Method.java:606)
AUT:    at org.eclipse.jubula.rc.common.AutServerLauncher.main(AutServerLauncher
.java:92)
AUT:Caused by: java.lang.SecurityException: class "org.eclipse.jubula.rc.common.
adapter.ComponentToStringAdapter"'s signer information does not match signer inf
ormation of other classes in the same package
AUT:    at java.lang.ClassLoader.checkCerts(ClassLoader.java:952)
AUT:    at java.lang.ClassLoader.preDefineClass(ClassLoader.java:666)
AUT:    at java.lang.ClassLoader.defineClass(ClassLoader.java:794)
AUT:    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14
2)
AUT:    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
AUT:    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
AUT:    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
AUT:    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
AUT:    at java.security.AccessController.doPrivileged(Native Method)
AUT:    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
AUT:    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
AUT:    at org.eclipse.jubula.rc.common.AutServerLauncher$UrlDefaultClassLoader.
loadClass(AutServerLauncher.java:225)
AUT:    at org.eclipse.jubula.rc.common.AutServerLauncher$UrlDefaultClassLoader.
loadClass(AutServerLauncher.java:241)
AUT:    at java.lang.Class.forName0(Native Method)
AUT:    at java.lang.Class.forName(Class.java:190)
AUT:    at org.eclipse.jubula.rc.common.adaptable.AdapterFactoryRegistry.findCla
ssesInJar(AdapterFactoryRegistry.java:340)
AUT:    at org.eclipse.jubula.rc.common.adaptable.AdapterFactoryRegistry.getClas
ses(AdapterFactoryRegistry.java:259)
AUT:    at org.eclipse.jubula.rc.common.adaptable.AdapterFactoryRegistry.findCla
ssesOfType(AdapterFactoryRegistry.java:196)
AUT:    at org.eclipse.jubula.rc.common.adaptable.AdapterFactoryRegistry.initReg
istration(AdapterFactoryRegistry.java:156)
AUT:    at org.eclipse.jubula.rc.common.adaptable.AdapterFactoryRegistry.initReg
istration(AdapterFactoryRegistry.java:180)
AUT:    at org.eclipse.jubula.rc.common.AUTServer.getInstance(AUTServer.java:269
)
AUT:    at org.eclipse.jubula.rc.common.AUTServer.main(AUTServer.java:287)
AUT:    ... 5 more

This affects (at least) all Java based toolkits.

Comment 2 Markus Tiede 2014-12-09 05:21:20 EST

A workaround for OSGi based toolkits (as e.g. RCP / GEF - when extending the o.e.j.rc.rcp* parts) is described here [1].

[1] http://eclip.se/173673#c3

Comment 3 Markus Tiede 2014-12-09 05:50:07 EST

For all other toolkits (Swing / AWT, SWT, JavaFX, ...) we could:
 - either change the loading sequence of signed and un-signed JARs / classes - to load the unsigned first and after that the signed ones (I'd not recommend using this as it's likely to break due to the same reason as soon as people start signing their extensions)
 - or re-locate the classes (at least AdapterFactories, Adapter and TesterClasses) to another package when using extensions (for all toolkits / for all examples).

As far as I can see this should address the problem "signer information does not match signer information of other classes in the same package".

Comment 4 Markus Tiede 2014-12-09 05:56:45 EST

We should also think about:
 - changing the AUT start behavior by logging errors like this and at least try to continue starting the AUT
 - enhancing the accessibility of logging information during AUT start; currently information like this are only printed to the system out of the AUT-Agent (which is hard to find when e.g. using the embedded AUT-Agent)
 - the fact that this (comment 3) is - depending on the way we implement it - a breaking change as everyone has to adjust his rc-extension and re-locate the mentioned classes

Comment 5 Markus Tiede 2015-01-05 04:54:20 EST

First step:

http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/commit/?id=06e1941f98b3c7e874425e8899ebf1131024e6fa

We do now also look in a different package for adapter factories.

Comment 6 Markus Tiede 2015-01-05 07:12:04 EST

Documentation and examples have been adjusted with

http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/commit/?id=a0c3ef26aaf187d41f0005cfc4bf9de613070de6

Comment 7 Markus Tiede 2015-01-05 07:21:07 EST

Release notes added with

http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/commit/?id=bf342fd12cf3a3b4297cca8d0f39c4edc0f3628d

This has been implemented - taking comment 3 part 3 into account - in a non-breaking way. However we strongly recommend to perform this class re-location.

Comment 8 Marvin Mueller 2015-01-06 09:01:06 EST

I can confirm when using other package names for the tester class and the "org.eclipse.jubula.ext.rc.common.adapter" package for the adapter factory everything is working without any further changes.

Comment 9 Markus Tiede 2015-01-14 05:18:54 EST

*** Bug 443349 has been marked as a duplicate of this bug. ***