Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 3.0.0
-
Fix Version/s: Bug Backlog
-
Component/s: Core: Configuration
-
Labels:None
-
User impact:Medium
-
Similar Issues:None
Description
This may be categorized as "Don't do that!" and "Will not fix" (or maybe even duplicate since I'm not sure how to search for this), but I thought I would raise the issue.
When using embedded Mule with Spring and "Spring-first" configuration, org.springframework.web.context.ContextLoaderListener is typically loaded via web.xml and creates a bean context. org.mule.config.builders.MuleXmlBuilderContextListener is then loaded, which checks to see if there is a org.springframework.web.context.WebApplicationContext available, and sets it as a parent context to the Mule context if so. Finally, the mule.context attribute is set in the ServletContext.
Because bean visibility in the parent context can be obscured by the child context, it's easy for bean namespace collisions to generate spurious errors. For instance a flow with the same name as a component bean in the parent context will be substituted in a <component><spring-object/></component> construction. When Mule (in my case, the Jersey module) tries to initialize the flow as if it were a component, all heck breaks loose, and the errors that Jersey throws out are completely unrelated to the cause.
Is it possible that some strategically-placed type checking could help users more easily find these kind of configuration gaffes? The user impact is very high when the problem presents itself (i.e. for new users), otherwise not very important.