Re: [osgi-dev] Restart OSGi framework programatically
Hi, Am Mittwoch, den 08.06.2011, 18:00 +0200 schrieb Guillaume Nodet: Right, we have the same kind of launcher in Karaf that even enable us to update the osgi framework itself. Ok, lets continue with ads: The Sling launcher can also do this supporting the Bundle.update(InputStream) method on the system bundle ;-) Regards Felix On Wed, Jun 8, 2011 at 17:43, Felix Meschberger fmesc...@gmail.com wrote: Hi, Am Mittwoch, den 08.06.2011, 11:34 -0400 schrieb Richard S. Hall: On 6/8/11 11:20, Felix Meschberger wrote: Hi, Am Mittwoch, den 08.06.2011, 17:12 +0200 schrieb Eugen Reiswich: Hi folks, I need to restart an OSGi application programmatically in Java. How can I do this? AFAICT the official way is to call Bundle.update() on the system bundle. True. BUT: This requires support from the framework launcher. Not entirely true. Yes, I just realized that I remained in the 4.1 times when Peter posted his reply. If you want to simply restart the framework, then calling update() on the system bundle would be sufficient. However, if you want to restart the JVM (e.g., to change what's on the boot class path) then you need help from the launcher. In fact, what we do in the Sling launcher is that we create root class loader to load the framework with and on framework restart we throw away the old one and create a new one. I think this further helps PermGen GC --- but I would be happy to learn that I am wrong ;-) Regards Felix ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Monitoring the SCR
Hi Felix, I once started on a new API which I intended to propose to the OSGi as the standard DS admin API [1]... But somehow this always was pushed back by some other work; I should pick this up again, probably ;-) Probably. :-) I can see it being a real boon for both testing and diagnostic purposes. Imagine for example that a device is failing to become fully operational because of a corrupt file somewhere causing an activator to fail - how to diagnose if you can't visualise the state of the SCR? [1] http://svn.apache.org/viewvc/felix/sandbox/fmeschbe/dsadmin/ Yes, that (or something very like it) is just what is needed - go for it! Chris -- On Tue, Jun 7, 2011 at 10:44 PM, chris.g...@k-embedded-java.com wrote: Working with DS, I often feel the need to dig in and find out how the various components are getting along. Some frameworks have shell commands which allow one to examine the status of components (e.g. Felix, mBS) while others haven't or at least not yet (Knopflerfish). What I would most like though would be to design a probe which can inspect its environment and produce reports. Is there a (framework-independent) way to do this? Bundles and services are quite easy to enumerate and to track (race conditions aside), but components? Am I missing something? Best regards Chris ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
