Improved test runtime when probe invoker initialization failures occur [PAXEXAM-653]

[ops4j-issues]

Ion Savin created PAXEXAM-653

When the JUnit4ProbeInvoker initialization fails inside the container the driver will still try to execute the probe method, it will fail to find the corresponding ProbeInvoker service inside the container and will eventually timeout (after 2 minutes per test method).

Ran into this problem when the test class extends another class which is contained in a bundle dependency which fails to install. Then the ProbeInvoker is initialized the base class is not found and a NoClassDefFound exception is thrown and the corresponding probe invoker service is no longer registered.

The problem with this behavior is that the test runtime is 2min x number_of_test_requiring_missing_dep.

To improve the runtime a substitute ProbeInvoker is introduced which will throw the original exception/error when the probe is invoked.

---

Affects: 4.2.0
Votes: 0, Watches: 4

[ops4j-issues]

Ion Savin commented

The exception thrown when trying to retrieve the non-existing service:

org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker
        at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
        at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
        at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:79)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_45]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_45]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_45]
        at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_45]
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)[:1.7.0_45]
        at sun.rmi.transport.Transport$1.run(Transport.java:177)[:1.7.0_45]
        at sun.rmi.transport.Transport$1.run(Transport.java:174)[:1.7.0_45]
        at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_45]
        at sun.rmi.transport.Transport.serviceCall(Transport.java:173)[:1.7.0_45]
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)[:1.7.0_45]
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)[:1.7.0_45]
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)[:1.7.0_45]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_45]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_45]
        at java.lang.Thread.run(Thread.java:744)[:1.7.0_45]

[ops4j-issues]

Ion Savin commented

Proposed fix: #25

[ops4j-issues]

Toni Menzel commented

Sounds good too me. Harald Wellmann whats the OPS4J practice these days? Just accept his pull request or let him merge it in himself like "in the old days of OPS4J".. Just curious since its been a looooong time for me since my days over here 😉

[ops4j-issues]

Harald Wellmann commented

The issue descriptions smells of misconfiguration or an unintended misuse. I don't see a case where JUnit4ProbeInvoker initialization is expected to fail.

It's not clear which problem the pull request is trying to solve, and there is no test case, so this is not ready to be merged.

[ops4j-issues]

Toni Menzel commented

Ion Savin: As described in the pull request, a test would be good..

[ops4j-issues]

Ion Savin commented

Harald Wellmann, Toni Menzel, here is a sample project ilustrating the problem (I don't think a test case is appropriate in this case as the pass condition would be time-based):
https://github.com/isavin/paxexam-653-testcase

In the sample project the tests fail because of a dependency missing from the container (in practice it could be missing for whatever reason, not necessarily because of wrong @Configuration). The proposed change makes the build fail-fast(er) in this case.

[ops4j-issues]

Ion Savin commented

Hi guys, any update on this? Thanks!