You can get the CamelContext from the Exchange which can be accessed from CamelLogProcessor. But I’m not sure if the setting the TCCL can resolve the issue of CAMEL-6694.
-- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Wednesday, November 20, 2013 at 8:31 AM, Raul Kripalani wrote: > Hey guys, > > To solve CAMEL-6694, I'm having to enhance the constructors of the > CamelLogger and CamelLogProcessor to pass in either: > > - the ClassLoader of the Camel context (obtained with > CamelContext#getApplicationClassLoader) - or - > > - the Camel context itself, letting the constructors call > CamelContext#getApplicationClassLoader. > > This API change will percolate up to several other classes, such as: > > DeadLetterChannelBuilder > DefaultErrorHandlerBuilder > LoggingErrorHandlerBuilder > LoggingExceptionHandler > etc. > > I really dislike this solution, but I don't think there's another way to > get hold of the CamelContext. Or is there? Some clever trick I'm unaware of? > > If there's no other way out, we should postpone this change until Camel > 3.0, where we're allowed to introduce API changes. Agree? > > P.S.: I've enhanced the ObjectHelper with a new method <T> T > runWithClassLoader(ClassLoader cl, Callable<T> callable). > > Thanks! > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk
