Reading this discussion it seems that what is needed is very much what is
provided by the SCR diagnostics service? If I go to the webconsole in Apache
Felix I can see why a component is not active. Is this not the template we're
looking for? I use it extensively in Xray and it works very nice. So of course
the easy solution is just to use DS and use the diagnostic API provided by
Apache Felix (I think it is also implemented in Equinox now)? :-)
Since there are other extenders, it seems to make sense to provide a registry
of 'issues', where extenders can report a problem on a component, a likely
cause, and maybe an advice to repair it.
I do agree with Richard, BJ, and Marcel. This is NOT a framework issue, and the
Bundle state should be left alone. This is another level.
Kind regards,
Peter Kriens
On 9 okt. 2013, at 17:51, Richard S. Hall <[email protected]> wrote:
>
> On 10/9/13 11:21 , Felix Meschberger wrote:
>> Hi
>>
>> Am 09.10.2013 um 05:24 schrieb Richard S. Hall:
>>
>>> On 10/9/13 05:39 , Christian Schneider wrote:
>>>> Nowadays dependency injection technologies like blueprint, ds and
>>>> spring dm are used a lot in OSGi. All these have in common that they
>>>> are extender based. So instead of using an activator you have an
>>>> extender that detects if you use such a technology and initializes the
>>>> bundle.
>>>>
>>>> Unfortunately this makes diagnosing the status of your system a lot
>>>> harder. A bundle can be active and still the blueprint context may
>>>> have failed to create or the extender is even absent. The case of no
>>>> extender can be nicely solved by capabilities which seem to be
>>>> introduced in the newest spec proposals.
>>>>
>>>> What I have not yet seen is a common status and error reporting. I
>>>> have written such a thing for karaf where the bundle status is
>>>> combined from the OSGi bundle status + e.g. the blueprint status if
>>>> the bundle uses blueprint. I also created a diag command that shows
>>>> blueprint errors to make it easier to spot problems.
>>>>
>>>> Would it make sense to standardize this? Perhaps by allowing an
>>>> extender to override the reported status of a bundle?
>>> No, I don't think such a mechanism makes sense. This is no longer the
>>> extender pattern any more. If you really want to do this as part of your
>>> "extender", you can just provide a standard activator that extendee
>>> bundles must use and this standard activator could do whatever it wanted
>>> to fail activation if it so desired. This is how we had to do DI in OSGi
>>> before you could get access to a bundle's context externally (a la
>>> Service Binder).
>>>
>>> Creating some mechanism to create effectively implicit activators is
>>> going too far.
>> Agreed, but how about this tangent : Allow extenders to hook into the
>> Bundle.adapt(Class) method to expose extend state which then may expose
>> extender information related to the bundle ?
>>
>> (Yes this is still requirements gathering, but I had to write down this idea
>> flying through my head ;-) )
>
> This is precisely why I was against the adapt() method ever being added to
> the spec in the first place since it creates a secondary registry of
> service-like objects. Why not just have an extender register a service that
> has a getMoreInfo(Bundle) method on it? :-)
>
> -> richard
>
>>
>> Regards
>> Felix
>>
>>>> I also think it would be nice to have a common api to get some
>>>> diagnosis state for bundles. You could ask this api about a bundle id
>>>> and it could return a list of exceptions provided by all extenders
>>>> that processed the bundle.
>>> I believe there are already examples of such diagnostic API in Felix'
>>> SCR and iPOJO. It could make sense to standardize, but the question
>>> would be how far could you go, since extenders can have wildly different
>>> capabilities and purposes (e.g., extenders are only for DI).
>>>
>>> -> richard
>>>
>>>> I am currently working an a pax exam improvement to have an assertion
>>>> like this but it would be a lot nicer if the OSGi framework would
>>>> already provide such an API and if the DI framework could already add
>>>> diagnostic infos. So the pax exam assertion could then just rely on
>>>> the api and not care about all the technologies.
>>>>
>>>> Christian
>>>>
>>>>
>>> _______________________________________________
>>> 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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
