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, <[email protected]> >> 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 >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> > >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
