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 <https://www.everit.biz/>
Everit OpenSource
http://everit.org
On Tue, Jan 14, 2014 at 3:31 PM, Balázs Zsoldos
<[email protected] <mailto:[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 <tel:%2B36-70%2F594-92-34>
Everit Kft.
https://www.everit.biz <https://www.everit.biz/>
Everit OpenSource
http://everit.org
On Tue, Jan 14, 2014 at 1:45 PM, BJ Hargrave <[email protected]
<mailto:[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]_ <mailto:[email protected]>
office: +1 386 848 1781 <tel:%2B1%20386%20848%201781>
mobile: +1 386 848 3788 <tel:%2B1%20386%20848%203788>
From: Balázs Zsoldos <[email protected]
<mailto:[email protected]>>
To: OSGi Developer Mail List <[email protected]
<mailto:[email protected]>>
Date: 2014/01/14 03:09
Subject: [osgi-dev] Adding more monitoring capabilities to
Declarative Services
Sent by: [email protected]
<mailto:[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 <tel:%2B36-70%2F594-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] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
