Sorry for the direct mail from my side too.. I guess I just hit reply
instead reply all.
On 11.10.2013 16:18, Arjun Panday wrote:
Sorry for the direct email, we should probably stick to the mailing
list to avoid forking discussions (see chris's mail below).
I agree with Richard that extenders can have many different purposes,
not only DI, and indeed extenders do not prevent a bundle from
starting; at most they won't be able to do what they're supposed to do
(but other extenders could work on the same bundle)
First extenders typically track bundles only once they're started (or
installed, in which case they don't care about the bundle life cycle).
I think this is part of the problem. Extenders are so loosely coupled to
the bundle lifecycle that errors are difficult to spot.
Extenders typically track a resource in the bundle or a manifest
header or scan annotations.. One common error is to misspell the
manifest header or file name (when they're not automatically
generated). This situation is pretty hard to diagnose since the
extender won't even start to do anything with the bundle.
This should be easy once we use capabilities. The bundle then specifies
e.g. a blueprint-extender capability and the framework knows the
extender is needed.
Then extender then can also report if it does not find the config it needs.
Then if really it comes down to an uncaught exception when starting a
service (or when parsing some extender specific resource), the
extender implementation could choose to simply stop the bundle but
that would probably be a pretty harsh behavior!
Yes . I think an extender should not directly change the status of a
bundle. Perhaps we need something other than the extender pattern. For
example
a DI framework could register as an additional "initializer" of a
bundle. The OSGI framework could then call the DI framework on start and
stop of the bundle and also react on failures. So this would be an
extension of the BundleActicator idea.
The bundle status directly reflects the bundle life cycle: installed,
started, stopped.. fairly simple. But a "status" which would reflect
an aggregation of the status of all possible extenders seem quite hard
to represent, and interpret. The extender implementation can simply
dump the exception in the logs and possibly reflect the error in a
dedicated webconsole plugin.
The OSGi framework could aggregate the status of all "initializers". It
would simply run one after the other. The bundle then would only go into
status ACTIVE if all initializers have run succesfully.
Alternatively, a standardized way of looking at it could be that all
extenders register an "Error" object containing the extender ID, the
bundle that failed and an error description. Then a centralized
service (or webconsole plugin) could display all such errors.
Of course I do not believe my idea with the initializers would come any
time soon if at all. So some registry of errors is a very good idea for
mid term.
Looking forward to see what we can agree on.
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
