I really don't want classloader dinking. On Nov 19, 2013, at 7:19 PM, Willem jiang <willem.ji...@gmail.com> wrote:
> 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 > > >
