0

I am currently deciding which pax executor to use when running OSGi applications from the IDE (see http://paxrunner.ops4j.org/space/Executors for a list of available one's). There basically two choices for me when I want to run a process from the IDE with pax runner:

In-Process-Executor (Runs the OSGi process in the same Java Process as Pax Runner itself):

  • PRO: Easy to attach a debugger to.
  • PRO: Easy to kill the OSGi process, as no second Java VM is started.

  • PRO: Faster to start.

  • CON: heavily limits paxrunner's capabilities to non-javaVM settings (that one is from the documentation of Pax Runner).

Default Executor: (Runs the OSGi process in a new Java process)

  • PRO: enables Pax Runner to set various JavaVM settings.

  • CON: Harder to attach a debugger to (needs some remote debugging setup).

  • CON: Almost impossible to kill the OSGi process if Pax Runner doesn't do it properly.
  • CON: Longer startup times as two JVMs are started.

So my question basically is, if someone experienced a scenario where Pax Runner's JVM settings capabilities were crucial and the OSGi process would not work when using the in-process executor. I have not yet found such an example, however I need to decide if I support in-process, default executor or both, so some real-world use case that makes use of JVM-setting capabilities of the default executor would really help me in making that decision.

Jan Thomä
  • 13,296
  • 6
  • 55
  • 83

1 Answers1

0

If the reason you start Pax runner from IDE is for Testing, have a look at Pax Exam, which also (optionally) uses Pax Runner underneath. Then you don't need to worry too much.

double-beep
  • 5,031
  • 17
  • 33
  • 41
Toni Menzel
  • 764
  • 3
  • 10
  • I am developing a plugin for a Java IDE which allows for starting your OSGi application right from the IDE. That of course is mainly for testing reasons, but not necessarily for unit-testing reasons. It's like starting a Tomcat from your IDE to manually test your application, just that this plugin starts an OSGi container. Currently the plugin uses the default executor for launching the container which works pretty well however the second of my CON list is now kicking in, so I wonder if I could safely switch to the In-Process-Executor without sacrificing any vital functionality. – Jan Thomä Apr 21 '11 at 06:24