Re: [osgi-dev] Monitoring the SCR
That example is usually pretty well logged ... though I am usually too stupid to look in the log until I wasted half an hour. The hardest case is to realize you actually have to install DS ... Kind regards, Peter Kriens On 9 jun 2011, at 21:20, chris.g...@k-embedded-java.com wrote: 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 ___ 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
[osgi-dev] Monitoring the SCR
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
Re: [osgi-dev] Monitoring the SCR
Chris, The Felix SCR implementation offers a service interface org.apache.felix.scr.ScrService that gives you an introspection API for the state of DS components. I believe the Equinox DS implementation now offers the same service, so it's becoming a kind of de facto standard, but I would also like to see it become a real, specified standard API. Regards Neil 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
