Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 3.0.0-M4
-
Fix Version/s: Bug Backlog
-
Component/s: Core: Components
-
Labels:None
-
User impact:High
-
Affects Docs:Yes
-
Similar Issues:None
Description
On migrating mule-config.xml from 2.2.1 to 3.0.0M4 version, we found that the custom interceptors no longer work and throws the below exception stack trace.
Caused by: org.mule.api.lifecycle.InitialisationException: The required object/property "object factory" is null
at org.mule.component.AbstractJavaComponent.doInitialise(AbstractJavaComponent.java:155)
at org.mule.component.AbstractComponent.initialise(AbstractComponent.java:263)
at org.mule.service.AbstractService.doInitialise(AbstractService.java:431)
at org.mule.model.seda.SedaService.doInitialise(SedaService.java:145)
at org.mule.service.AbstractService$1.onTransition(AbstractService.java:181)
at org.mule.service.AbstractService$1.onTransition(AbstractService.java:154)
at org.mule.lifecycle.LifecycleManagerSupport.invokePhase(LifecycleManagerSupport.java:138)
at org.mule.service.ServiceLifecycleManager.fireInitialisePhase(ServiceLifecycleManager.java:74)
at org.mule.service.AbstractService.initialise(AbstractService.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1414)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1375)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1335)
... 33 more
================
Here is how the custom interceptor stack is configured:
<component>
<interceptor-stack ref="default" />
</component>
Here is the mule-config.xml
<interceptor-stack name="default">
<custom-interceptor
class=".........."/>
<custom-interceptor
class="........"/>
<custom-interceptor
class="........."/>
</interceptor-stack>
<model name="............">
<service name="............">
<inbound>
<inbound-endpoint address="http://localhost:8888"
transformer-refs="............" exchange-pattern="request-response"/>
</inbound>
<component>
<interceptor-stack ref="default" />
</component>
<outbound>
<filtering-router>
<outbound-endpoint
address="..........."
transformer-refs="........." responseTransformer-refs="........... "
exchange-pattern="request-response" />
</filtering-router>
</outbound>
</service>
Also, as an FYI, we do not use any service components per se...We are using mule purely as a gateway to route the http requests with some transformations. The outbound endpoints are all http based and all the transformers are custom transformers. Please let me know in case more info is needed. Thanks.
Issue Links
- is duplicated by
-
MULE-4980
Custom Interceptors stopped working in 3.0.0M4 version
-
This isn't an interceptor issue per se but rather caused by the fact you are using interceptors without a component instance. They are not designed to be used like this but this obviously did work in 2.2.x as you say.
With 3.0 you'll be able to avoid this roundabout approach to achieving what you need and rather:
Interceptors are message processors and interceptor-stacks are still supported to you could actually just use <interceptor-stack ref="default" /> in between inbound end outbound endpoints. Alternatively you can use <custom-processor class=""/> , <composite-processor/> and <processor ref=""/> to construct anything you want grouping up reusable sets of processors into composites and composing them as required.
This is all still work in progress, but it' coming soon. If you use snapshots you can start playing around with this and if you have and feedback get it to use before we freeze api/confg.