Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 357903

Summary: Add support for BeanDefinitionRegistryPostProcessor
Product: [RT] Gemini.Blueprint Reporter: Tin N/A <canobix>
Component: CoreAssignee: Project Inbox <virgo-inbox>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: eclipse.org, olaf, quorg.xtn
Version: unspecified   
Target Milestone: 2.1.0.M01   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
OsgiBundleXmlApplicationContext.java required for workaround none

Description Tin N/A CLA 2011-09-16 00:57:42 EDT 
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/
Comment 1 Tin N/A CLA 2012-02-23 14:31:40 EST 
As suggested on the forums, Gemini blueprint might be a more appropriate place for this enhancement request.
Comment 2 Kay Huber CLA 2012-02-23 15:10:20 EST 
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...
Comment 3 Kay Huber CLA 2012-02-23 15:14:02 EST 
Created attachment 211532 [details]
OsgiBundleXmlApplicationContext.java required for workaround
Comment 4 Matt Magoffin CLA 2016-09-25 17:29:57 EDT 
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!
Comment 5 Olaf Otto CLA 2017-02-03 06:21:25 EST 
Assigned to upcoming milestone
Comment 6 Olaf Otto CLA 2017-05-09 09:41:37 EDT 
Released - closing.