Just thinking loudly. Why would be a DS specific monitoring solution necessary at all? There could be a solution based on org.osgi.resource.Resource and org.osgi.core.Capability classes. If there was a solution where the missing constraints could be defined in a standard way, it could be used by any technology (Declarative Services, Blueprint, etc..)
In case of Declarative Services, a Component would be a Resource with Capabilities and Requirements. A project like XRay could draw a graph that would show every runtime wirings (not just Bundle but Component wiring) with the missing constraints as well. Problem solving would be way much faster. In case someone wants to register a new OSGi service inside the Activate method of the of a component, he/she wanted to add a new Capability for the Component(Resource). In case someone started a ServiceTracker, BundleTracker or WhateverTracker in the Activate method of the Component, they would add a Requirement so the graph could be shown. This would mean that a component could be in ACTIVE state and yet have unsatisfied Requirement (added in the activate method programmatically). If you do not agree with the last part (accessing the monitoring part programmatically from within the component), I think it is still worthy to think about the first part (Component-Resource and Capability-Requirement) before releasing something. Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz Everit OpenSource http://everit.org On Tue, Jan 14, 2014 at 3:31 PM, Balázs Zsoldos <[email protected]>wrote: > Hi, > > thanks for the info. I have not checked it yet. I will do now. > > BTW.: Would it be possible to take the title of the RFC into the name of > the folder at https://github.com/osgi/design/tree/master/rfcs ? It is > really hard to keep in mind what-is-what based on number codes. Also, if > there was a commit on a folder, the commit message does not say what the > RFC is about. > > Thanks and regards, > > Balazs Zsoldos > Software Architect > Mobile: +36-70/594-92-34 > > Everit Kft. > https://www.everit.biz > > Everit OpenSource > http://everit.org > > > On Tue, Jan 14, 2014 at 1:45 PM, BJ Hargrave <[email protected]> wrote: > >> 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* <http://www.osgi.org/> >> *[email protected]* <[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* <https://www.everit.biz/> >> >> Everit OpenSource >> *http://everit.org* <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 >> > >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
