[
https://issues.apache.org/jira/browse/CAMEL-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved CAMEL-4347.
------------------------------------
Resolution: Fixed
Fixed in http://svn.apache.org/viewvc?view=revision&revision=1159171
This fix also sets CamelContext's application context classloader field with
the new thread context classloader to ensure the same object can always be
retrieved again when necessary.
> Set thread context class loader when starting camel-blueprint routes
> --------------------------------------------------------------------
>
> Key: CAMEL-4347
> URL: https://issues.apache.org/jira/browse/CAMEL-4347
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint
> Affects Versions: 2.8.0
> Reporter: Gert Vanthienen
> Assignee: Gert Vanthienen
> Fix For: 2.9.0
>
>
> When routes are getting started by the camel-blueprint component, the thread
> context classloader at that moment is the container's boot classloader. This
> is causing problems for e.g. ActiveMQ object messages that need to get
> deserialized, because the boot classloader is not aware of classes that might
> be available inside the container. The class used for reading the ActiveMQ
> object messages is
> http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/ClassLoadingAwareObjectInputStream.java.
> We can fix this by setting a more appropriate classloader as the thread
> context classloader while starting the CamelContext from a Blueprint
> definition. I see we also have a similar class in camel-jdbc and there are
> no doubt other libraries that depend on this classloader being set as well,
> so this change should help with all of those cases.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
