Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Won't Fix or Usage Issue
-
None
-
None
-
S1
-
Pre-production defect
-
2
-
Mule 4 M4 - Sprint 2
Description
I traced this issue to the point where the MuleArtifactContext is build. In line 153 it loads the ComponentBuildingDefinitionProvider*s, but it doesn't find the one for transports (*org.mule.compatibility.config.spring.TransportComponentBuildingDefinitionProvider) when running with isolation.
Take RedeliveryPolicyNamespaceHandlerTestCase on branch MULE-10659.
When BeanDefinitionFactory#resolveComponentRecursively processes the innerComponent for transports:inboundEndpoint, it goes to the else branch and uses the old parsing mechanism.
On 4.x, this case uses the new mechanism continuing the recursive call and the test runs correctly.
The difference in the executions is when hasDefinition checks for componentBuildingDefinitionRegistry.getBuildingDefinition(componentIdentifier).isPresent() (it returns true on 4.x but false in MULE-10659).