Well, I’m not too sure to understand :) I will only focus on bundle 0 and the stopping event I’m expecting from it. So, I put “that” bundle listener on the bundle 0 not on any other bundle. But, the way I get the bundle 0 is via a bundleContext which is injected via Blueprint.
That said, the spec says I should first get the event. Should not be tied to the actual stopping order, isn’t it (Blueprint or not)? Regards, JP De : Guillaume Nodet [mailto:[email protected]] Envoyé : vendredi 18 novembre 2016 17:04 À : user Objet : Re: Karaf shutdown You have 2 events for each bundle (but for the system bundle, the first event which is a STOPPING event). For each of those 2 events, the first one is a STOPPING, then the framework calls the activator stop, then fire a STOPPED event. Are you sure you're using activators ? because the problem may be completely different if using a blueprint extender and a blueprint event that does not stop. In that case, what happens is that the blueprint extender intercepts the STOPPING event from the system bundle and preemptively shutdown all blueprint bundles in an orderly fashion. This usually helps by choosing a better stopping order than the default one, depending on service used between bundles. The problem is that given the extender stops the blueprint bundles preemptively, the bundles will be stopped before the framework has a change to send the STOPPING event for the bundle. It's actually the same as if you would stop the blueprint extender in a running framework: all blueprint containers will be destroyed, but the lifecycle of the bundles would not be affected. This behavior can be turned off by using org.apache.aries.blueprint.preemptiveShutdown=false in the etc/config.properties file. 2016-11-18 16:49 GMT+01:00 CLEMENT Jean-Philippe <[email protected]<mailto:[email protected]>>: In fact I guess that’s the problem, the event seems not to be fired before stopping bundles. When all bundles react normally, i.e. they stop, I get the stopping event. When at least one does not stop as expected, then I get no stopping event. Would you be kind enough to try again with a non-stopping-bundle and displaying the event type? Regards, JP De : Guillaume Nodet [mailto:[email protected]<mailto:[email protected]>] Envoyé : vendredi 18 novembre 2016 16:40 À : user Objet : Re: Karaf shutdown 2016-11-18 15:01 GMT+01:00 CLEMENT Jean-Philippe <[email protected]<mailto:[email protected]>>: Did you also add a bundle which prevents stopping ? No, but the first event is sent before actually stopping any bundle. PS: in your traces which event is the shutdown itself? It's not, because I paste a wrong output. Here's the full output, and the interesting event is the first one. It's should be a STOPPING event. karaf@root()> ($.context bundle 0) stop 1 org.osgi.framework.BundleEvent[source=org.eclipse.osgi_3.10.101.v20150820-1432 [0]] org.osgi.framework.BundleEvent[source=org.jline_3.0.1 [34]] org.osgi.framework.BundleEvent[source=org.jline_3.0.1 [34]] org.osgi.framework.BundleEvent[source=org.fusesource.jansi_1.14.0 [33]] org.osgi.framework.BundleEvent[source=org.fusesource.jansi_1.14.0 [33]] org.osgi.framework.BundleEvent[source=org.apache.sshd.core_1.2.0 [32]] org.osgi.framework.BundleEvent[source=org.apache.sshd.core_1.2.0 [32]] org.osgi.framework.BundleEvent[source=org.apache.servicemix.bundles.not-yet-commons-ssl_0.3.11.1 [31]] org.osgi.framework.BundleEvent[source=org.apache.servicemix.bundles.not-yet-commons-ssl_0.3.11.1 [31]] ... Regards, JP De : Guillaume Nodet [mailto:[email protected]<mailto:[email protected]>] Envoyé : vendredi 18 novembre 2016 14:26 À : user Objet : Re: Karaf shutdown You must be doing something wrong. I added this small bit of code to one of karaf's activators: bundleContext.getBundle(0).getBundleContext().addBundleListener(new SynchronousBundleListener() { @Override public void bundleChanged(BundleEvent event) { System.out.println(event); } }); Here's the output when stopping under equinox: karaf@root()> ($.context bundle 0) stop 1 org.osgi.framework.BundleEvent[source=org.apache.karaf.shell.core_4.1.0.SNAPSHOT [28]] org.osgi.framework.BundleEvent[source=org.apache.karaf.shell.commands_4.1.0.SNAPSHOT [27]] org.osgi.framework.BundleEvent[source=org.apache.karaf.shell.commands_4.1.0.SNAPSHOT [27]] org.osgi.framework.BundleEvent[source=org.apache.karaf.service.core_4.1.0.SNAPSHOT [26]] org.osgi.framework.BundleEvent[source=org.apache.karaf.service.core_4.1.0.SNAPSHOT [26]] org.osgi.framework.BundleEvent[source=org.apache.karaf.package.core_4.1.0.SNAPSHOT [25]] org.osgi.framework.BundleEvent[source=org.apache.karaf.package.core_4.1.0.SNAPSHOT [25]] org.osgi.framework.BundleEvent[source=org.apache.karaf.management.server_4.1.0.SNAPSHOT [24]] org.osgi.framework.BundleEvent[source=org.apache.karaf.management.server_4.1.0.SNAPSHOT [24]] org.osgi.framework.BundleEvent[source=org.apache.karaf.log.core_4.1.0.SNAPSHOT [23]] org.osgi.framework.BundleEvent[source=org.apache.karaf.log.core_4.1.0.SNAPSHOT [23]] org.osgi.framework.BundleEvent[source=org.apache.karaf.kar.core_4.1.0.SNAPSHOT [22]] org.osgi.framework.BundleEvent[source=org.apache.karaf.kar.core_4.1.0.SNAPSHOT [22]] org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.modules_4.1.0.SNAPSHOT [21]] org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.modules_4.1.0.SNAPSHOT [21]] org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.config_4.1.0.SNAPSHOT [20]] org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.config_4.1.0.SNAPSHOT [20]] org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.command_4.1.0.SNAPSHOT [19]] org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.command_4.1.0.SNAPSHOT [19]] org.osgi.framework.BundleEvent[source=org.apache.karaf.instance.core_4.1.0.SNAPSHOT [18]] org.osgi.framework.BundleEvent[source=org.apache.karaf.instance.core_4.1.0.SNAPSHOT [18]] org.osgi.framework.BundleEvent[source=org.apache.karaf.features.command_4.1.0.SNAPSHOT [17]] org.osgi.framework.BundleEvent[source=org.apache.karaf.features.command_4.1.0.SNAPSHOT [17]] org.osgi.framework.BundleEvent[source=org.apache.karaf.diagnostic.core_4.1.0.SNAPSHOT [16]] org.osgi.framework.BundleEvent[source=org.apache.karaf.diagnostic.core_4.1.0.SNAPSHOT [16]] org.osgi.framework.BundleEvent[source=org.apache.karaf.config.core_4.1.0.SNAPSHOT [13]] org.osgi.framework.BundleEvent[source=org.apache.karaf.config.core_4.1.0.SNAPSHOT [13]] org.osgi.framework.BundleEvent[source=org.apache.karaf.bundle.core_4.1.0.SNAPSHOT [12]] org.osgi.framework.BundleEvent[source=org.apache.karaf.bundle.core_4.1.0.SNAPSHOT [12]] org.osgi.framework.BundleEvent[source=org.apache.aries.jmx.whiteboard_1.1.5 [10]] org.osgi.framework.BundleEvent[source=org.apache.aries.jmx.whiteboard_1.1.5 [10]] org.osgi.framework.BundleEvent[source=org.apache.aries.jmx.core_1.1.7 [9]] org.osgi.framework.BundleEvent[source=org.apache.aries.jmx.core_1.1.7 [9]] org.osgi.framework.BundleEvent[source=org.apache.aries.jmx.api_1.1.5 [8]] org.osgi.framework.BundleEvent[source=org.apache.aries.jmx.api_1.1.5 [8]] org.osgi.framework.BundleEvent[source=org.apache.karaf.deployer.features_4.1.0.SNAPSHOT [14]] org.osgi.framework.BundleEvent[source=org.apache.karaf.deployer.features_4.1.0.SNAPSHOT [14]] org.osgi.framework.BundleEvent[source=org.apache.karaf.deployer.kar_4.1.0.SNAPSHOT [15]] org.osgi.framework.BundleEvent[source=org.apache.karaf.deployer.kar_4.1.0.SNAPSHOT [15]] org.osgi.framework.BundleEvent[source=org.apache.aries.util_1.1.3 [11]] org.osgi.framework.BundleEvent[source=org.apache.aries.util_1.1.3 [11]] org.osgi.framework.BundleEvent[source=org.apache.karaf.features.core_4.1.0.SNAPSHOT [7]] org.osgi.framework.BundleEvent[source=org.apache.karaf.features.core_4.1.0.SNAPSHOT [7]] org.osgi.framework.BundleEvent[source=org.apache.felix.fileinstall_3.5.6 [6]] org.osgi.framework.BundleEvent[source=org.apache.felix.fileinstall_3.5.6 [6]] org.osgi.framework.BundleEvent[source=org.apache.felix.configadmin_1.8.12 [5]] org.osgi.framework.BundleEvent[source=org.apache.felix.configadmin_1.8.12 [5]] org.osgi.framework.BundleEvent[source=org.ops4j.pax.logging.pax-logging-log4j2_1.9.1 [4]] org.osgi.framework.BundleEvent[source=org.ops4j.pax.logging.pax-logging-log4j2_1.9.1 [4]] org.osgi.framework.BundleEvent[source=org.ops4j.pax.logging.pax-logging-api_1.9.1 [3]] org.osgi.framework.BundleEvent[source=org.ops4j.pax.logging.pax-logging-api_1.9.1 [3]] org.osgi.framework.BundleEvent[source=org.ops4j.pax.url.mvn_2.5.1 [2]] org.osgi.framework.BundleEvent[source=org.ops4j.pax.url.mvn_2.5.1 [2]] gnodet•apache-karaf-minimal/target/assembly(master⚡)» 2016-11-18 13:29 GMT+01:00 CLEMENT Jean-Philippe <[email protected]<mailto:[email protected]>>: That’s exactly what I did. The listener is not called at all. Looking at bundles, some are Active, some Resolved, one Installed (OSGi System Bundle 3.10.2.v20150203-1939) and one Waiting (one of mine). public final class KarafStopper { private static final Logger LOG = LogManager.getLogger(KarafStopper.class); private static final long TIMEOUT = 3 * 1000; // in milliseconds private final Bundle karaf; public KarafStopper(final BundleContext context) { System.out.println("=> blabla"); karaf = context.getBundle(0); karaf.getBundleContext().addBundleListener(new SynchronousBundleListener() { @Override public void bundleChanged(final BundleEvent event) { System.out.println("Karaf: " + event.getType()); } }); } public void shutdown() { try { final Thread watchdog = new Thread(() -> { try { Thread.sleep(TIMEOUT); // Karaf refuses to stop LOG.error(() -> "Karaf did not stop gracefully"); System.exit(-1); } catch (final InterruptedException e) { // Karaf stopped normally } }); watchdog.setDaemon(true); watchdog.start(); System.out.println("Bye bye"); karaf.stop(Bundle.STOP_TRANSIENT); System.out.println("So long!"); } catch (final BundleException e) { System.out.println("Oooooooooooops: " + e); LOG.error(() -> "Issue while stopping karaf", e); } } } Regards, JP De : Guillaume Nodet [mailto:[email protected]<mailto:[email protected]>] Envoyé : vendredi 18 novembre 2016 13:01 À : user Objet : Re: Karaf shutdown Can you write a simple SynchronousBundleListener that prints to stdout all received events and paste the output when stopping the framework for felix and equinox ? 2016-11-18 12:10 GMT+01:00 CLEMENT Jean-Philippe <[email protected]<mailto:[email protected]>>: Well, that’s not the case when a bundle refuses to stop – I get no event. Ah I forgot to mention that Equinox is used instead of Felix. May I open a bug for this? Regards, JP De : Guillaume Nodet [mailto:[email protected]<mailto:[email protected]>] Envoyé : vendredi 18 novembre 2016 11:52 À : user Objet : Re: Karaf shutdown The SynchronousBundleListener is the way to go. You should receive a STOPPING event for the system bundle before any other bundle is actually stopped. 2016-11-18 11:38 GMT+01:00 CLEMENT Jean-Philippe <[email protected]<mailto:[email protected]>>: Is there a way to get a shutdown event? Regards, JP De : CLEMENT Jean-Philippe [mailto:[email protected]<mailto:[email protected]>] Envoyé : jeudi 17 novembre 2016 17:03 À : [email protected]<mailto:[email protected]> Objet : Karaf shutdown Dear Karaf addicts :) I would like Karaf to stop. This may fail to happen when (at least) a bundle does not end. So I added a watchdog which exits Java when a time limit has been exceeded (note: maybe there is already a way to do so - ?). The way I coded it does not work when the shutdown is made via the Karaf prompt, so I decided to enhance it. Googling “Karaf shutdown hook”, I found an old thread talking about SynchronousBundleListener. The issue I’m facing is that I get no event when performing bundle0.stop(Bundle.STOP_TRANSIENT) and one of the bundles refuses to stop. The listener is registered via bundle0.getBundleContext().addBundleListener(new SynchronousBundleListener() { … }). Is it normal? How to force Karaf to shutdown? PS: Karaf version is 4.0.7 JP -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected]<mailto:[email protected]> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/ -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected]<mailto:[email protected]> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/ -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected]<mailto:[email protected]> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/ -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected]<mailto:[email protected]> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/ -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected]<mailto:[email protected]> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/
