Thanks for this Andrew.
There is a design issue with multiple extenders competing to extend a particular application bundle. The OSGi Alliance is defining some standard generic capabilities that extenders can provide and applications can require so that an application can say that it needs a particular extender, although I'm not sure that much thought has been given to selecting between distinct implementations of the same extender standard. I'll mention this use case
So your patch is probably a necessary evil. ;-)
Please could you raise a bug and attach the patch. ChainActivator seems like a reasonable spot for the new logic.
Your patch would also be useful in scenarios where Gemini Blueprint and Aries Blueprint need to co-exist, such as when running Aries Subsystems in Virgo ([1]).
Regards,
Glyn
I have recently been testing an existing OSGi application on WebSphere
8.5 with its new support for EBAs. The application uses gemini blueprint
for 'spring powered' bundles. To use WebSphere datasources, I need to
include one bundle with a special blueprint with IBM's schema extension
referencing the datasource[1]. When I do this, gemini blueprint's
extender also tries to process the blueprint configuration and fails
because this needs to be done by WebSphere to properly process the IBM
schema extension in it. I added a small patch to ChainActivator in
gemini-blueprint-extender to allow switching off blueprint support
through a system property. Would anyone else be interested in this or is
there perhaps a better way to prevent gemini-blueprint from processing
the blueprint configuration? Otherwise I'm happy to send the patch
along.
Thanks,
Andrew
1: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.osgi.nd.multiplatform.doc%2Ftopics%2Fca_blueprint_resref.html
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
|
