Hi Timothee You need the instance logs to fully analyze the root cause, I think it may be in target/failsafe-reports/*-output.txt.
In any case, I suspect the issue may be related to repository startup. I recently made repo startup asynchronous in bundles/jcr/base (no release yet), which allows additional services (e.g. service user amendments, login admin whitelist fragments, repository initializers) to be bound while the repo starts up (which can be a few seconds). As a side-effect, this seems to have improved the chances of the system being ready by the time tests are run. Regards Julian On Tue, Dec 13, 2016 at 11:45 AM, Timothee Maret <[email protected]> wrote: > Hi all, > > One thing that prevents me from running the release:prepare command for the > i18n bundle is that the Pax Exam seem to fail from time to time on my > machine. When it fails, it is because PaxExam can't find the remote > framework (the i18n tests run in a forked vm) [0]. > > Is this a known issue or something that needs to be investigated ? Does > someone experience this as well (could be my environment) ? > > Regards, > > Timothee > > [0] > > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 86.166 sec > <<< FAILURE! - in org.apache.sling.i18n.it.ResourceBundleProviderIT > org.apache.sling.i18n.it.ResourceBundleProviderIT Time elapsed: 86.165 sec > <<< ERROR! > org.ops4j.pax.exam.TestContainerException: cannot find remote framework in > RMI registry > at > org.ops4j.pax.exam.forked.ForkedFrameworkFactory.findRemoteFramework(ForkedFrameworkFactory.java:235) > at > org.ops4j.pax.exam.forked.ForkedFrameworkFactory.fork(ForkedFrameworkFactory.java:124) > at > org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:162) > at > org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86) > at > org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136) > at > org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:448) > at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97) > at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.rmi.ConnectException: Connection refused to host: > 192.168.59.100; nested exception is: > java.net.ConnectException: Operation timed out > at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) > > 2016-12-12 21:30 GMT+01:00 Robert Munteanu <[email protected]>: > >> On Mon, 2016-12-12 at 20:39 +0100, Timothee Maret wrote: >> > Thanks Julian & Robert for your insight! >> > >> > The tests are fixed in r1773859 according to the successful run at >> > [2] >> > I'll follow [1] in order to eventually cut the release. >> >> Great, thanks for the quick turnaround! >> >> Robert >> >> > >> > Regards, >> > >> > Timothee >> > >> > [2] >> > https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sling-bun >> > dles-extensions-i18n-1.8/7/ >> > >> > 2016-12-12 14:39 GMT+01:00 Julian Sedding <[email protected]>: >> > >> > > I think the failure is due to the fact the no >> > > "org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.ame >> > > nded" >> > > configuration is present for the Pax integration test in the i18n >> > > module. >> > > >> > > Regards >> > > Julian >> > > >> > > On Mon, Dec 12, 2016 at 2:20 PM, Robert Munteanu <[email protected] >> > > g> >> > > wrote: >> > > > Hi, >> > > > >> > > > On Mon, 2016-12-12 at 11:03 +0100, Timothee Maret wrote: >> > > > > Hi, >> > > > > >> > > > > We fixed two bugs for org.apache.sling.i18n v 2.5.6 [0] and no >> > > > > issue >> > > > > is >> > > > > still opened. >> > > > > I think it'd make sense to cut a release for it, however I >> > > > > wonder >> > > > > how/who >> > > > > should do the release. >> > > > > >> > > > > Is someone assigned to releasing that bundle ? If not should I >> > > > > follow >> > > > > the >> > > > > instructions from [1] in order to propose/cut the release ? >> > > > >> > > > The Jenkins jobs for the i18n bundle have recently started >> > > > failing >> > > > >> > > > - https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sli >> > > > ng-bun >> > > > dles-extensions-i18n-1.7/ >> > > > - https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sli >> > > > ng-bun >> > > > dles-extensions-i18n-1.8/ >> > > > >> > > > It would be good to have them stable before a release. >> > > > >> > > > Robert >> >>
