totally different ;)

if you are brave, you may want to take a look at the pax-web integration
tests with Karaf. [1]
Maybe there are enough hints for you to find out where exactly is your
mismatch :)

regards, Achim

[1] -
https://github.com/ops4j/org.ops4j.pax.web/tree/master/pax-web-itest/pax-web-itest-karaf/src/test/java/org/ops4j/pax/web/itest/karaf

2017-04-15 16:00 GMT+02:00 Steinar Bang <[email protected]>:

> >>>>> Achim Nierbeck <[email protected]>:
>
> > the karaf container is always a forked process. If you want to run it as
> > non-forked you can use the following configuration:
>
> > runEmbedded(true)
>
> > this is especially useful if you want to debug your tests, but beware
> > because of the nature of how the tests run, this can only be used with
> > debugging and one test-method.
>
> Right.
>
> In the meantime I've found this thread
>  http://karaf.922171.n3.nabble.com/Pax-exam-tests-fail-to-
> start-properly-with-Karaf-4-0-4-tp4044841p4044843.html
>
> and have applied the same cure:
>     <plugin>
>      <groupId>org.apache.maven.plugins</groupId>
>      <artifactId>maven-surefire-plugin</artifactId>
>      <configuration>
>       <forkCount>0</forkCount>
>      </configuration>
>     </plugin>
>
> And that works... that is: it still doesn't start, but at least there
> isn't a Java VM still running after the test has failed.
>
> Does this the trigger the same behaviour as the runEmbedded(true)
> configuration? Or is that a competely different mechanism?
>
>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Reply via email to