[CAMEL-10747] CamelContext is not been set in VMConsumer when used with POJO @Consume

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.17.4, 2.17.5, 2.18.1
• Fix Version/s: 2.17.6, 2.18.3, 2.19.0
• Component/s: camel-core

Environment

Ubuntu 16.04, OpenJDK 1.7, OpenJDK 1.8, Spring 4.2.6.RELEASE

• Estimated Complexity: Unknown
• Assignee: Claus Ibsen
• Reporter: Christopher Harris
• Created: 25/Jan/17 13:54
• Updated: 29/Jan/17 12:21
• Resolved: 29/Jan/17 12:21

Description

In Spring environment, DefaultCamelBeanPostProcessor relies on CamelPostProcessorHelper to inject consumer , when CamelPostProcessorHelper creates a VMConsumer from the endpoint based on the use of @Consume annotation, it then tries to start the consumer as a service.

Because the consumer endpoint of @Consume was created using the camel context from CamelPostProcessorHelper, it puts the VMConsumer service in to deferred start until the camel context is finished starting. The service is ultimately been added to the DeferServiceStartupListener. Then the DeferServiceStartupListener tries to start the VMConsumer at a later stage. 2.17.3 and 2.18.0 does not suffer this problem.

The problem is non of the process above has considered the fact that the VMConsumer is an instance of CamelContextAware and injects the correct camel context to it. This then leads to the VMConsumer tries to prepare the exchange with a null pointer reference as its camel context.

Because the exchange now has null as camel context, a NPE is thrown at https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/impl/DefaultExchange.java#L519 when it tries to create the exchange id.

This problem only happened after issue CAMEL-10406 is merged in

Issue Links

• relates to: CAMEL-10406 VM endpoint caching leak the wrong camel context