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
|