Have you looked at RFC 190 and the proposed ServiceComponentRuntime introspective service? This is the direction we are going.
I am not sure I see that adding API to the component space is the best thing for a declarative services model especially since most people should be using it in a POJO manner (and not even using the DS API directly). -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Balázs Zsoldos <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2014/01/14 03:09 Subject: [osgi-dev] Adding more monitoring capabilities to Declarative Services Sent by: [email protected] Hi, we switched to OSGi 2-3 years ago. My colleagues (especially the ones who has just got started with OSGi) suffer a lot due to the reason that it is hard to find out why the application is not started. The log is filled with many information and it is hard to find the part that tells the cause. Using the ds and xray plugin for WebConsole it is easier to find out the cause of the problem but in many cases it is not enough. When a Component works in the way that it registers service(s) programmatically, when it uses a Service- or BundleTracker inside to wait for satisfaction, it cannot be shown on any screen. I think it would be very useful to extend the Declarative Services spec. to have functions on the ComponentContext that allows the programmer to push information to the monitoring tools. I was thinking something like the following: /** * Retrieving a Monitor Context that makes it possible to add more * information about the Component for administrators and developers. **/ MonitorContext getMonitorContext(); The MonitorContext interface would have the following functions: /** * Setting a message provides information about the current state of * the Component. */ void setMessage(String message); /** * Adding a service reference that is used by the Component with a * short description in what use-case it is used. */ void addServiceUsage(ServiceReference<?> reference, String description); /** * Removing a service usage. */ void removeServiceUsage(ServiceReference<?> reference); /** * Adding a Bundle Capability that is used by the Component with a * short description in what use-case it is used. */ void addServiceUsage(BundleCapability capability, String description); /** * Removing a capability usage. */ void removeServiceUsage(BundleCapability capability); /** * Add cause why the component is still unsatisfied. */ UnsatisfactionCause addUnsatisfactionCause(String cause); The UnsatisfactionCause object would make it possible to remove it from the MonitorContext. The MonitorContext would inherit from the interface ComponentMonitor that would contain the getters. The ComponentMonitor could be retrieved from the ComponentInstance. What do you think? In my opinion, a solution like this would speed up development a lot. This is a draft idea. In case you find it useful, I will spend a bit more time to prepare a complete plan (that could be a base of an RFC). Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz Everit OpenSource http://everit.org_______________________________________________ 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
