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
