On 10/9/13 08:42 , Christian Schneider wrote:
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.
Again, the extender can already do this with no extra support from the
framework, simply implement an activator that extendee bundles must use.
There is no reason to push more into the framework.
And trying to make this part of the resolve process is probably a
mistake anyway, since the resolve process is already complicated enough.
Technically, an extender could possibly implement something similar to
what you are saying with a resolver hook that filtered its own extender
capability if it felt that the extendee could not be successfully
initialized, thus the extendee would fail to resolve.
However, I wouldn't make this a recommended approach because I am sure
it would make the resolve process harder to understand for the average
person, because they'd really have no idea why the resolve failed.
-> richard
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
