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 <toni.men...@rebaze.com>
> To: General OPS4J <general@lists.ops4j.org>
> 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 <
> holly.k.cumm...@googlemail.com> 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 <toni.men...@rebaze.com
> >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 <
> >> holly.k.cumm...@googlemail.com> 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
> >>> general@lists.ops4j.org
> >>> http://lists.ops4j.org/mailman/listinfo/general
> >>>
> >>>
> >>
> >>
> >> --
> >> --
> >> Toni Menzel | Founder | Rebaze GmbH
> >> toni.men...@rebaze.com | www.rebaze.com
> >>
> >>
> >>
> >> _______________________________________________
> >> general mailing list
> >> general@lists.ops4j.org
> >> http://lists.ops4j.org/mailman/listinfo/general
> >>
> >>
> >
> > _______________________________________________
> > general mailing list
> > general@lists.ops4j.org
> > http://lists.ops4j.org/mailman/listinfo/general
> >
> >
>
>
> --
> --
> Toni Menzel | Founder | Rebaze GmbH
> toni.men...@rebaze.com | 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
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
>
>
> End of general Digest, Vol 82, Issue 4
> **************************************
>
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

Reply via email to