I would be pleased to work on this RFP too.
Regards
JB
On 10/09/2013 11:51 AM, David Bosschaert wrote:
Hi Christian,
If you think it makes sense to standardize something like this, I can
work with you on getting an OSGi RFP started on this topic. Once there
is some initial content, we can put it on
https://github.com/osgi/design for further feedback.
Cheers,
David
On 9 October 2013 10:43, Jean-Baptiste Onofré <[email protected]> wrote:
Hi Christian,
as blueprint is part of OSGi specification, it makes sense to be introduce a
new "optional" status for bundle that use blueprint.
Let see what the others think about that.
Regards
JB
On 10/09/2013 11:39 AM, 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? 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 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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
_______________________________________________
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
