On 09.10.2013 14:24, Richard S. Hall wrote:
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.
Yes probably it does not make sense to let the extender directly
influence the bundle status. Still I think an extender should be
involved in determining the status of the bundle. Of course this can
only happen if the extender is a little bit less decoupled from the
bundle lifecycle than right now.
So for example I could imagine that the resolver sees that the bundle
has a requirement for a blueprint extender. So we could have an API were
providers of capabilities could register their initialization services.
For blueprint this service would read the context xml and establish the
blueprint context.
The service could return the success or failure status. Then the
framework could use this to determine the bundle state and also store
the error for the common status reporting I mentioned below.
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).
I am not sure how it should look exactly. What I imagine is to have one
initialization result per extender or requirement / capability. The
result could have a status and an exception. I think this should at
least be able to cover some of the cases.
Christian
--
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
