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
