Correct! And thats almost the exact thing described here: https://github.com/tonit/Learn-PaxExam/blob/master/lesson-servermode/src/main/java/org/ops4j/pax/exam/servermode/SimpleServer.java if you need a one-class example.
On Wed, Apr 11, 2012 at 9:41 AM, Caspar MacRae <[email protected]> wrote: > > Hi Holly, > > I can't remember where but there's some documentation that shows how to > launch the test container from a main method - if you add your > @Configuration method and Gogo shell bundles you can get an interactive > handle on the test (it doesn't run any tests but AFAIK launches exactly the > same). > > > import static org.ops4j.pax.exam.OptionUtils.combine; > import static org.ops4j.pax.exam.spi.PaxExamRuntime.createContainer; > import static org.ops4j.pax.exam.spi.PaxExamRuntime.createTestSystem; > import static > com.matterhorn.test.integration.pax.exam.GogoOption.gogoShell; > > // ... > public static void main(String[] args) throws TimeoutException, > IOException { > createContainer( > createTestSystem( > combine(new MyIntegrationTest().config(), > gogoShell()) > )).start(); > } > > @Configuration > public Option[] config() > { > return new Option[]{ /* ... */}; > } > // ... > > > // With gogoShell() method coming from a helper class: > > public final class GogoOption { > > public static final String DEFAULT_VERSION = "0.10.0"; > > private GogoOption() {} > > > public static Option gogoShell(String version) > { > final String gid = "org.apache.felix"; > return composite( > > mavenBundle().groupId(gid).artifactId("org.apache.felix.gogo.runtime").version(version), > > mavenBundle().groupId(gid).artifactId("org.apache.felix.gogo.shell").version(version), > > mavenBundle().groupId(gid).artifactId("org.apache.felix.gogo.command").version(version) > ); > } > > public static Option gogoShell() > { > return gogoShell(DEFAULT_VERSION); > } > } > > > A bit late but might be useful. > > > cheers, > Caspar > > > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 6 Apr 2012 14:30:36 +0200 >> From: Toni Menzel <[email protected]> >> To: General OPS4J <[email protected]> >> Subject: Re: Debugging pax exam tests >> Message-ID: >> < >> caejgzhqwrtm2o0bpjm40019pekrw+mv8e3pvflwbs+4ozvm...@mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> >> Hey Holly, >> >> well sure, for interactive tests (how i'd call it) we've used a scenario >> where we just stop within test execution and debug things using a remote >> shell or any other means. >> Instead of halting standard tests, you can also use a feature known as >> "serverMode". This may sounds silly, but exactly does what you want: >> It does not shutdown the framework automatically. A good example is this >> [1] >> >> This is a demo on how we actually used the Pax Exam DSL to creating a OSGi >> environment used as a normal container, that you just start. In this case >> you won't get the helper bundles installed automatically. >> To get the idea on whats really going on, just compare the two factory >> methods defaultTestSystemOptions() vs defaultServerSystemOptions() in [2]. >> See, much less defaults you don't care about when not really injecting >> test >> bundles anyway. >> >> Not sure on how deep you've went with Pax Exam so far, you really want to >> understand the concepts described in [1]. Otherwise the examples i >> mentioned before might not make sense immediately (speaking of the >> plumbing >> API vs. porcelain API. You want to understand plumbing cause its really >> useful when creating new usecases other than automatic testing). >> >> Hope this helps ? >> >> [1] >> >> https://github.com/tonit/Learn-PaxExam/blob/master/lesson-servermode/src/main/java/org/ops4j/pax/exam/servermode/SimpleServer.java >> >> [2] >> >> https://github.com/ops4j/org.ops4j.pax.exam2/blob/master/core/pax-exam-spi/src/main/java/org/ops4j/pax/exam/spi/PaxExamRuntime.java >> >> [3] https://github.com/tonit/Learn-PaxExam >> >> Happy Easter Holidays, >> Toni >> >> On Thu, Apr 5, 2012 at 12:41 AM, Holly Cummins < >> [email protected]> wrote: >> >> > Hi Toni, >> > >> > Good question. I realised I usually do use the NativeContainer, which >> may >> > be why I never noticed the trick about re-using the downloaded bundles >> and >> > configuration until recently! In either case, though, what's usually >> most >> > useful to me is an OSGi console, rather than an attached debugger. >> Thinking >> > about it more, I suppose I could use a debugger to suspend the test and >> > then telnet in to an Equinox console if I have my options set >> correctly. Is >> > that the sort of approach you'd recommend, or is there something >> simpler? >> > >> > >> > On Wed, Apr 4, 2012 at 9:18 PM, Toni Menzel <[email protected] >> >wrote: >> > >> >> Hi Holly, >> >> Just a quick reply, did you consider using NativeContainer ? Just >> because >> >> it simplifies debugging really. >> >> On general approaches, i will reply in detail tomorrow. (Soccer now ;) >> >> Cheers, >> >> Toni >> >> >> >> On Wed, Apr 4, 2012 at 9:57 PM, Holly Cummins < >> >> [email protected]> wrote: >> >> >> >>> Hello, >> >>> >> >>> When running pax-exam tests, I find most of my failures are caused by >> >>> bundles failing to start for one reason or another. I have two >> strategies >> >>> for figuring out the issues, but I don't think either is quite what >> I'm >> >>> supposed to be doing: >> >>> >> >>> (1) Exhaustive assertion approach: In my test code, I add assertions >> >>> that all of the bundles I care about are started. If a bundle isn't >> >>> started, I try and start it and use the error message as the message >> for a >> >>> test failure. This makes for tests with very clear failure messages, >> but it >> >>> means writing a lot of boilerplate code. If I forget to add an >> assertion >> >>> for a problem bundle, my system is still a black box, and I need ... >> >>> >> >>> ... (2) Sneaky backdoor console approach: Often, what I really want to >> >>> do is just open a console to the test framework and have a good >> browse of >> >>> what's started and what's not and which packages and services are >> >>> available. In these cases, I find the temporary folder pax-runner is >> using >> >>> and fire up a console using a command like >> >>> >> >>> java -jar >> bundles/org.eclipse.osgi_3.5.1.R35x_v20090827.jar >> >>> -console -configuration equinox/ >> >>> >> >>> This makes it really easy to diagnose what's gone wrong in a failing >> >>> system, but it doesn't feel like I'm using the pax tools as intended. >> >>> >> >>> Am I missing some elegant debugging technique that everyone else using >> >>> pax-exam knows about? In other words, is there a cleaner way to >> produce a >> >>> dump of which bundles failed to resolve for technique (1), or to >> easily >> >>> bring up a console of the test environment for technique (2) using >> proper >> >>> pax-runner, rather than just ferreting out pax-runner's temporary >> folders >> >>> and using them directly? >> >>> >> >>> Thanks, >> >>> Holly >> >>> >> >>> _______________________________________________ >> >>> general mailing list >> >>> [email protected] >> >>> http://lists.ops4j.org/mailman/listinfo/general >> >>> >> >>> >> >> >> >> >> >> -- >> >> -- >> >> Toni Menzel | Founder | Rebaze GmbH >> >> [email protected] | www.rebaze.com >> >> >> >> >> >> >> >> _______________________________________________ >> >> general mailing list >> >> [email protected] >> >> http://lists.ops4j.org/mailman/listinfo/general >> >> >> >> >> > >> > _______________________________________________ >> > general mailing list >> > [email protected] >> > http://lists.ops4j.org/mailman/listinfo/general >> > >> > >> >> >> -- >> -- >> Toni Menzel | Founder | Rebaze GmbH >> [email protected] | www.rebaze.com >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.ops4j.org/pipermail/general/attachments/20120406/9593dc1c/attachment-0001.html >> > >> >> ------------------------------ >> >> >> _______________________________________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general >> >> >> End of general Digest, Vol 82, Issue 4 >> ************************************** >> > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > > -- -- Toni Menzel | Founder | Rebaze GmbH [email protected] | www.rebaze.com
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
