Community
Participate
Working Groups
Build Identifier: 2.1.1 Currently Virgo does not support the BeanDefinitionRegistryPostProcessor. Adding this support enables an elegant way to conditionally enable beans and services that a bundle exposes, by using the postProcessBeanDefinitionRegistry method to add only selected beans to the bundle context. In more restricted environments this enables grouping similar or related services into a single bundle, while at the same time allowing the bundle to provide only necessary services for a particular deployment. In relation to that, it allows for the restricted environment running the bundle to provide only the required dependencies for the enabled services (as opposed to providing all the dependencies that every bundle service needs when they're all enabled). Reproducible: Always Steps to Reproduce: More details on this and a test bundle can be found in Virgo forums, at: http://www.eclipse.org/forums/index.php/t/240084/
As suggested on the forums, Gemini blueprint might be a more appropriate place for this enhancement request.
I've noticed the same problem with BeanDefinitionRegistryPostProcessor apparently just not being supported in Eclipse Gemini. I was stumbling upon it, when I was trying to figure out, why org.mybatis.spring.mapper.MapperScannerConfigurer from mybatis spring integration was not doing as it should: scan my packages for mybatis mapper interfaces. It turned out, that MapperScannerConfigurer is implementing (and thus depending on proper handling of) BeanDefinitionRegistryPostProcessor. I found an admittedly rather kludgy workaround - that will not be resistant to future changes within Eclipse Gemini and/or Spring framework but solved the problem for me for now. The workaround is based on an "Gemini extender configuration" as described at http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.0.RELEASE/html/app-deploy.html#app-deploy:extender-configuration Details: * create a fragment bundle with host bundle "org.eclipse.gemini.blueprint.extender" * create META-INF/spring/extender/config.xml (path must match, file name is arbitrary). Contents: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="applicationContextCreator" class="org.eclipse.gemini.extender.config.internal.CustomizedOsgiApplicationContextCreator" /> </beans> * Create a class extending "org.eclipse.gemini.blueprint.context.support.OsgiBundleXmlApplicationContext" (contents attached - too big to be included here) - this class is providing the required functionality. Actually, the implementation of #invokeBeanFactoryPostProcessors in this class is about what would need to be changed to the original OsgiBundleXmlApplicationContext as a permanent fix for this issue... * Create a class "CustomizedOsgiApplicationContextCreator" in a new package "org.eclipse.gemini.extender.config.internal" (arbitrary actually - just has to match above config.xml class property in bean definition) extending the class "org.eclipse.gemini.blueprint.extender.support.DefaultOsgiApplicationContextCreator" * In this class, override one method: DelegatedExecutionOsgiBundleApplicationContext createApplicationContext(BundleContext bundleContext) It can actually be exactly the same code as in it's super class except that we create our own instance of OsgiBundleXmlApplicationContext Done. Hope it helps, until we have some kind of fix...
Created attachment 211532 [details] OsgiBundleXmlApplicationContext.java required for workaround
I just ran into this issue as well, when trying to make use of Spring Security's websocket support. After digging into why that wasn't working, I discovered it published a BeanDefinitionRegistryPostProcessor into the application context, which was then never invoked. I hadn't seen this bug report prior to my investigation, and developed a work-around fix to Gemini Blueprint's org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext class that addressed the problem for my use case by adapting similar code from Spring's org.springframework.context.support.PostProcessorRegistrationDelegate class. I've pushed up my change here: https://github.com/msqr/gemini.blueprint/tree/BeanDefinitionRegistryPostProcessors-fix in this commit: https://github.com/msqr/gemini.blueprint/commit/9beafbc58240b26855013d69a421fa63e00322e0 This solves the problem for me, but I am not familiar enough with Gemini Blueprint code to really know if this fix is appropriate (and doesn't have any unintended consequences). The build works and existing tests all pass at least. It would be great if this could make its way into Gemini Blueprint proper!
Assigned to upcoming milestone
Released - closing.
