Affects Version/s: 3.0.0
Fix Version/s: Product Backlog
Component/s: Core: Configuration
MULE-5196 Ambiguous bean naming causes spurious errors with parent bean context MULE-4089 Better documentation for Mule Bean Definition Parser framework MULE-5375 spring mule bean definition parsers should leave alone attributes named "xml..." MULE-2060 <mule:component> should ideally be able to reference a standard Spring Factory bean MULE-2221 Check for Mule parent element MULE-659 Mule With existing Spring MULE-955 Spring container MULE-2062 Mule extensions to spring cause the parsing/instantiation of some spring beans to fail MULE-5804 Expose FtpConnectionFactory implementation as Spring bean MULE-647 Add Spring ApplicationEvent support to Mule
The gist of that question is I couldn't get the custom-security-provider to pick up the Spring Security authentication manager that is defined in the parent context of a "Spring-first" context configuration. I think I've found that it's an impossible configuration.
Because the BeanDefinitionBuilder doesn't have access to the parent WebApplicationContext, it seems the bean would have to be defined as lazy so it's not resolved until after the BeanDefinitionReader is done.
But there's no way to set the lazy flag on the custom-security-provider, so it seems like it won't work.
Maybe it's a bad idea to use this "Spring first" pattern. I initially liked it because there's a clean separation between the Mule and Spring contexts, which would hopefully make it easier to separate later.
For what it's worth, CXF has no problem picking up parent context beans in a similar configuration.
|Field||Original Value||New Value|
|Issue Type||Bug [ 1 ]||Improvement [ 4 ]|
|Fix Version/s||Product Backlog [ 10440 ]|
|Priority||To be reviewed [ 6 ]||Major [ 3 ]|
|Workflow||Fixed Main Mule Workflow (after JIRA upgrade) [ 78450 ]||Main Mule Workflow v1.0 [ 136271 ]|