I would be very grateful if you could send the RFP to me. Thanks!
On Tue, Jan 14, 2014 at 4:38 PM, Christian Schneider < [email protected]> wrote: > Hi Balazs, > > you might be interested in this discussion: > http://www.mail-archive.com/[email protected]/msg02999.html > > I asked about a standardized way to get diagnostics in a common way for > various dependency injection frameworks. We decided to start an RFP for > this. > You are welcome to participate. David Bosschaert offered to mentor this > effort. > > I created an initial version of the RFP. I think currently Jean Baptiste > Onofré is revising it. If you are interested I can send you my initial > version. So you can see how far it applies to your problem. Your idea of > basing the diagnostics on Requirements and Capabilities sounds like a good > idea to me. > > Christian > > > On 14.01.2014 16:12, Balázs Zsoldos wrote: > > 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 <%2B1%20386%20848%201781> >>> mobile: +1 386 848 3788 <%2B1%20386%20848%203788> >>> >>> >>> >>> >>> >>> 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 > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Christian Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > > > _______________________________________________ > 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
