If you have:
<dependency>
<groupId>org.apache.karaf.itests</groupId>
<artifactId>common</artifactId>
<version>4.2.5</version>
</dependency>
<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
</dependency>
<dependency>
<groupId>org.ops4j.pax.exam</groupId>
<artifactId>pax-exam-container-karaf</artifactId>
<scope>compile</scope>
<optional>true</optional>
<exclusions>
<exclusion>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.configadmin</artifactId>
</exclusion>
</exclusions>
</dependency>
it should bring all required dependencies for you.
Else, you need at least:
<dependency>
<groupId>org.ops4j.pax.exam</groupId>
<artifactId>pax-exam-container-karaf</artifactId>
<scope>compile</scope>
<optional>true</optional>
<exclusions>
<exclusion>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.configadmin</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.ops4j.pax.exam</groupId>
<artifactId>pax-exam-junit4</artifactId>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.karaf.shell</groupId>
<artifactId>org.apache.karaf.shell.core</artifactId>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-atinject_1.0_spec</artifactId>
<scope>compile</scope>
</dependency>
I also recommend to check if you have the following plugin execution in
your pom.xml:
<plugin>
<groupId>org.apache.servicemix.tooling</groupId>
<artifactId>depends-maven-plugin</artifactId>
<executions>
<execution>
<id>generate-depends-file</id>
<goals>
<goal>generate-depends-file</goal>
</goals>
</execution>
</executions>
</plugin>
Regards
JB
On 08/05/2019 16:19, Alex Soto wrote:
> That error: /Registration of RBC failed/: only occurs when *not*
> running the Integration Test, I suppose because Pax Exam driver is not
> running. I think this is how the driver communicates with the probe.
> When running the integration test, there is no such error.
>
> What do you want to see from the POM?
>
> Best regards,
> Alex soto
>
>
>
>
>> On May 8, 2019, at 10:10 AM, Jean-Baptiste Onofré <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Don't you have interface binding issue ?
>>
>> What do you have in the pom.xml of your itest ?
>>
>> Regards
>> JB
>>
>> On 08/05/2019 16:06, Alex Soto wrote:
>>> After the integration test finished (with error) I ran Karaf in the same
>>> Pax-Exam directory:
>>>
>>>
>>> target/exam/621f714b-cc7e-4a0c-91cc-b8ce65d02340/bin/karaf
>>>
>>> The command /list/ shows everything as ACTIVE.
>>> Also command /scr:list/ shows all components either as /active/
>>> or /satisfied./
>>> /
>>> /
>>> The only anomaly in the logs is:
>>>
>>> 2019-05-08T09:57:46,133 | WARN | Thread-47 | Activator
>>> | 196 - org.ops4j.pax.exam.rbc - 4.11.0 |
>>> Registration of RBC failed:
>>> java.rmi.ConnectException: Connection refused to host: 127.0.0.1;
>>> nested exception is:
>>> java.net.ConnectException: Connection refused (Connection refused)
>>> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>>> ~[?:?]
>>> at
>>> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
>>> ~[?:?]
>>> at
>>> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
>>> ~[?:?]
>>> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338) ~[?:?]
>>> at
>>> sun.rmi.registry.RegistryImpl_Stub.rebind(RegistryImpl_Stub.java:147)
>>> ~[?:?]
>>> at
>>> org.ops4j.pax.exam.rbc.internal.Activator.bindRBC(Activator.java:145)
>>> ~[?:?]
>>> at
>>> org.ops4j.pax.exam.rbc.internal.Activator.access$600(Activator.java:47)
>>> ~[?:?]
>>> at
>>> org.ops4j.pax.exam.rbc.internal.Activator$2.call(Activator.java:121)
>>> ~[?:?]
>>> at
>>>
>>> org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
>>> ~[200:org.ops4j.pax.swissbox.core:1.8.2]
>>> at
>>> org.ops4j.pax.exam.rbc.internal.Activator.register(Activator.java:105)
>>> [196:org.ops4j.pax.exam.rbc:4.11.0]
>>> at
>>> org.ops4j.pax.exam.rbc.internal.Activator.access$000(Activator.java:47)
>>> [196:org.ops4j.pax.exam.rbc:4.11.0]
>>> at
>>> org.ops4j.pax.exam.rbc.internal.Activator$1.run(Activator.java:85)
>>> [196:org.ops4j.pax.exam.rbc:4.11.0]
>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>> Caused by: java.net.ConnectException: Connection refused (Connection
>>> refused)
>>> at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:?]
>>> at
>>>
>>> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
>>> ~[?:?]
>>> at
>>>
>>> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
>>> ~[?:?]
>>> at
>>>
>>> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
>>> ~[?:?]
>>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:?]
>>> at java.net.Socket.connect(Socket.java:589) ~[?:?]
>>> at java.net.Socket.connect(Socket.java:538) ~[?:?]
>>> at java.net.Socket.<init>(Socket.java:434) ~[?:?]
>>> at java.net.Socket.<init>(Socket.java:211) ~[?:?]
>>> at
>>>
>>> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
>>> ~[?:?]
>>> at
>>>
>>> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
>>> ~[?:?]
>>> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
>>> ~[?:?]
>>> ... 12 more
>>>
>>>
>>>
>>> But I think that is expected, since the Integration Test is not running.
>>>
>>>
>>>> On May 8, 2019, at 9:35 AM, Jean-Baptiste Onofré <[email protected]
>>>> <mailto:[email protected]>
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> Can you share your itest ? I'm not able to reproduce the issue, so hard
>>>> to investigate.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 08/05/2019 15:31, Alex Soto wrote:
>>>>> Still having this problem. I am setting log level:
>>>>>
>>>>> logLevel(LogLevel.TRACE),
>>>>>
>>>>> And
>>>>>
>>>>> log4j2.logger.paxexam.name=org.ops4j.pax.exam
>>>>> log4j2.logger.paxexam.level=TRACE
>>>>>
>>>>> And
>>>>>
>>>>> static final long SERVICE_TIMEOUT = 300_000;
>>>>> systemTimeout(SERVICE_TIMEOUT),
>>>>> RBCRemoteTargetOptions.waitForRBCFor((int) SERVICE_TIMEOUT),
>>>>>
>>>>> I removed all services references that used the /@Inject/ annotation,
>>>>> and replaced them with service lookup code.
>>>>> Logs don’t show any error or warning that can help pinpoint the
>>>>> cause of
>>>>> this error.
>>>>>
>>>>> Increasing the timeout just delays the reporting of the error by the
>>>>> FailSafe driver, but the error is logged a lot earlier in the Karaf log
>>>>> file.
>>>>>
>>>>> For easy reference, here is the stack trace again:
>>>>>
>>>>> 2019-05-08T09:15:18,654 | ERROR | BundleWatcher: 1 | BundleWatcher
>>>>> | 201 - org.ops4j.pax.swissbox.extender - 1.8.2 |
>>>>> Exception in executor thread
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
>>>>> for service org.ops4j.pax.exam.ProbeInvokerFactory
>>>>> at
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
>>>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>> at
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
>>>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>> at
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
>>>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>> at
>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
>>>>> ~[?:?]
>>>>> at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
>>>>> ~[?:?]
>>>>> at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
>>>>> ~[?:?]
>>>>> at
>>>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
>>>>> ~[?:?]
>>>>> at
>>>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
>>>>> [201:org.ops4j.pax.swissbox.extender:1.8.2]
>>>>> at
>>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>>>> [?:?]
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>>>> at
>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>> [?:?]
>>>>> at
>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>> [?:?]
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>> [?:?]
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>> [?:?]
>>>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>>>>
>>>>>
>>>>> Any hint?
>>>>>
>>>>> Best regards,
>>>>> Alex soto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On May 1, 2019, at 3:47 PM, Alex Soto <[email protected]
>>>>>> <mailto:[email protected]>
>>>>>> <mailto:[email protected]>
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>> Do you mean any of these options?
>>>>>>
>>>>>> RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
>>>>>> CoreOptions.systemTimeout(systemTimeout(finallongtimeoutInMillis)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Alex soto
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré
>>>>>>> <[email protected] <mailto:[email protected]>
>>>>>>> <mailto:[email protected]>
>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>
>>>>>>> You can increase the startup timeout on the @Configuration method (on
>>>>>>> the distribution).
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 01/05/2019 17:46, Alex Soto wrote:
>>>>>>>> No, I am not waiting for the service explicitly, it comes from
>>>>>>>> Pax Exam
>>>>>>>> itself (AFIK, based on the stack trace below).
>>>>>>>> My tests have a bunch of /@Inject/ed services, but they are all
>>>>>>>> decorated with /@Filter(timeout = SERVICE_TIMEOUT)
>>>>>>>> /where SERVICE_TIMEOUT = 240_000.
>>>>>>>>
>>>>>>>> Java version is 8.
>>>>>>>> Karaf version is 4.2.0.
>>>>>>>> The exception:
>>>>>>>>
>>>>>>>> 2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 |
>>>>>>>> BundleWatcher
>>>>>>>> | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
>>>>>>>> Exception in executor thread
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up
>>>>>>>> waiting
>>>>>>>> for service org.ops4j.pax.exam.ProbeInvokerFactory
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
>>>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
>>>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
>>>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
>>>>>>>> ~[?:?]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
>>>>>>>> ~[?:?]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
>>>>>>>> ~[?:?]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
>>>>>>>> ~[?:?]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
>>>>>>>> [202:org.ops4j.pax.swissbox.extender:1.8.2]
>>>>>>>> at
>>>>>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>>>>>>> [?:?]
>>>>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>>>>>>> at
>>>>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>>>>> [?:?]
>>>>>>>> at
>>>>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>>>>> [?:?]
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>>>> [?:?]
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>>>> [?:?]
>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>>>>>>>
>>>>>>>>
>>>>>>>> These integration tests have been working in the past, so I
>>>>>>>> suspect, as
>>>>>>>> the application complexity increased (i.e., more services being
>>>>>>>> added
>>>>>>>> overtime), it now takes more time for the container to finish
>>>>>>>> initialization (my guess). I would like to increase the timeout
>>>>>>>> value
>>>>>>>> to accommodate for a longer startup time, but so far, what I've
>>>>>>>> tried
>>>>>>>> has not made a difference.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Alex soto
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré
>>>>>>>>> <[email protected] <mailto:[email protected]>
>>>>>>>>> <mailto:[email protected]>
>>>>>>>>> <mailto:[email protected]>
>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>>
>>>>>>>>> Are you waiting for the service in your test explicitly or does
>>>>>>>>> it come
>>>>>>>>> from pax exam itself ?
>>>>>>>>>
>>>>>>>>> What JDK and Karaf version are you using ?
>>>>>>>>>
>>>>>>>>> As reminder, Pax Exam is used in Karaf itests themselves, and I
>>>>>>>>> don't
>>>>>>>>> have such issue. It could be related to JDK 11 if you are using
>>>>>>>>> this JDK
>>>>>>>>> version.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On 01/05/2019 17:13, Alex Soto wrote:
>>>>>>>>>> Thanks JB, no there are no errors in the log file, besides
>>>>>>>>>> this one.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Alex soto
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré
>>>>>>>>>>> <[email protected]
>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected]>
>>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Alex,
>>>>>>>>>>>
>>>>>>>>>>> Most of the time, this is a consequence of another error.
>>>>>>>>>>>
>>>>>>>>>>> Can you take a look in the target/exam karaf.log to see if
>>>>>>>>>>> there's
>>>>>>>>>>> something special there ?
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>> On 29/04/2019 18:09, Alex Soto wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> I am using pax-exam 4.11.0 for integration tests. I
>>>>>>>>>>>> am consistently
>>>>>>>>>>>> getting the following exception.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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:80)
>>>>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
>>>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
>>>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
>>>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
>>>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>>>>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
>>>>>>>>>>>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
>>>>>>>>>>>> at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
>>>>>>>>>>>> at com.sun.proxy.$Proxy15.call(Unknown Source)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
>>>>>>>>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>>>>>>>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>>>>>>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
>>>>>>>>>>>> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What causes this? How to troubleshoot or how to increase the
>>>>>>>>>>>> timeout?
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Alex soto
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected]>
>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected]>
>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>> [email protected]
>>>>>>>>> <mailto:[email protected]> <mailto:[email protected]>
>>>>>>>>> <mailto:[email protected]> <mailto:[email protected]>
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Baptiste Onofré
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> <mailto:[email protected]> <mailto:[email protected]>
>>>>>>> http://blog.nanthrax.net
>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>> Talend - http://www.talend.com
>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> [email protected] <mailto:[email protected]>
>>>> <mailto:[email protected]>
>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>>> Talend - http://www.talend.com <http://www.talend.com/>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [email protected] <mailto:[email protected]>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
