Karaf users,
A little background:
I have a bundle that periodically needs to restart its host Karaf
container. I accomplish this by setting the “karaf.restart”
system-property to “true” and then stopping the system-bundle. This
worked perfectly when Karaf was invoked directly via the bat files;
however, when using the service wrapper an attempt to restart simply
resulted in Karaf shutting down:
System.setProperty("karaf.restart", "true");
bundleContext.getBundle(0).stop();
I checked the mailing list archives and determined that this was
likely due to the Java Service Wrapper’s default behavior to shutdown
(http://karaf.922171.n3.nabble.com/Ability-to-self-restart-karaf-WAS-Infamous-permgen-leak-tp3589167p3590128.html).
The advice mentioned in the previous thread suggested changing the
Java Service Wrapper’s default behavior from “SHUTDOWN” to “RESTART”
via a wrapper configuration parameter (“wrapper.on_exit.default”).
While this works, it does prevent a normal shutdown as the wrapper
will restart the application no matter what.
After digging through the Java Service Wrapper documentation further I
discovered the filter mechanism by which the wrapper monitors the
console output of an application for “triggers” upon which it can act.
I was able to add a “trigger” to my code, via a System.out statement,
and indeed the wrapper initiates a restart while still allowing the
application to function correctly when invoked via the normal bat
files (sans-wrapper):
System.setProperty("karaf.restart", "true");
System.out.println("wrapper_restart_requested"); //wrapper restart trigger
bundleContext.getBundle(0).stop();
Question:
Are there any negative implications to the Karaf container by allowing
the wrapper to initiate a restart rather than stopping the
system-bundle directly? Does this introduce the possibility of
leaving the container in an inconsistent/corrupt state. I speculate
that the answer to this is “no”; however, I was hoping others
(especially core developers) might be able to give me a yes/no in
regards to the validity of this approach (or perhaps suggest an
alternative).
Thanks,
Steve
