pax drone - faq

Owned by Toni Menzel
Last updated: Jul 17, 2008Version comment
1 min read
Unknown macro: {ops4j-style}
Unknown macro: {ops4j-roundrect}

What can i do if something goes wrong ?

If you encounter a problem during the paxdrone run you can always _revisit_ the framework's state interactively using pax-runner:
Go to the tmp folder (on mac/linux its /tmp). There you should find a paxdrone-runner folder.
This is the working directory of paxdrone.
You can load its "old" state using pax-run.sh like that:

cd /tmp
pax-run.sh --ups=true --workingDirectory=paxdrone_runner

Here you go and can look whats wrong using the shell.

Can i launch paxdrone tests with my ide debugger ?

Well, you can. And it works of cause for the native connectors like FelixConnector.
Unfortunately, PaxRunner is currently the prime connector (see below) but here this will currently not work.
The reason is that PaxRunner launches the osgi framework in a separate Process underneath the VM running your Junit.
While it is possible to delegate this debugger to the other instance we currently haven't it done yet.
New
Adding debugging support has just been scheduled for the next release
Same with JProfiler Support

Is there a recommended connector implementation ?

Technically not. But if you can accept a speed penalty you should give PaxRunnerConnector a try.
This supports an amazing amount of options, zillions of supported configurations, runs in a separate vm and is being used by us most.
That said we must admit that any other connector that is being shipped alongside with paxdrone may not be that greatly featured or tested (at least for the first versions we throw out).

Can i control the manifest of the drone ?

No.
By design the drone will be built using the wrap approach solely on classes found inside the current project.
Every dependency will be declared as an optional import-package.
This constrains the usage of the drone. But by intention.
The drone contains just the recipe host and its direct dependencies (like helper classes just for testing purpose).
Everything you want to test should be build by someone who really knows about it: maven-bundle-plugin or similar.
This way you orchestrate the final artifacts and no hybrid bundles that blur the test outcome.

If you fear the extra step (build the bundle before run tests), you could implement a URL Handler that triggers a build before opening the InputStream to the resource. (its Open Participation, feel free to do it at OPS4J)

How does Pax Drone compare to SpringDM's Test Support ?

Indeed, PaxDrone was inspired by SpringDM's solution.
Both boot different osgi frameworks, create a test-bundle on-the-fly and launch it.
SpringDM focuses on build-in frameworks, strong SpringDM support and fast execution.

While PaxRunner focuses on

  • total separation of testrunner and framework execution environment (prevent sideeffects)
    • make testing at remote locations possible at all
    • support different launch options independend from executor
  • support different executor methods: JUnit, Plain Java Object, etc.
  • Build in all the nice abstraction stuff from ops4j
    • Pax Runner
    • Pax URL

You can see SpringDM's functionality as a subset of PaxDrones capabilities using the Junit Runner:

  • write a junit test
  • use your unit test runner from inside your IDE
  • the framework takes care of making a bundle-on-the-fly that includes your test code
  • the framework invokes your tests