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]> 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]>> >>>>> <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]>> >>>>>> <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] <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]>> >>>>>>>>>> <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]>> >>>>>>>>>> <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/ <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/ <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] <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/ <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/> <http://www.talend.com/> >>>>>>> >>>>>> >>>>>> -- >>>>>> Jean-Baptiste Onofré >>>>>> [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]> >>> http://blog.nanthrax.net <http://blog.nanthrax.net/> >>> Talend - http://www.talend.com <http://www.talend.com/> >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com
