Well, this ticket is about log statements tossed by the Log EIP (and possibly the Log component too) carrying incorrect values for the bundle.name and bundle.id MDC entries.
They invariably refer to the camel-core bundle, because that's where the Logger was initialised from. So my first attempt to fix this ticket is to ensure that the TCCL when constructing the Logger was the Camel Context's application ClassLoader. That's why I needed to get hold of it. But on deeper investigation of Pax Logging, I found that it calculates the calling Bundle by investigating the Java call stack: BundleHelper#getCallerBundle [1]. So the caller bundle will inevitably be camel-core always... Kinda a dead end :( Maybe Achim or Guillaume can lend a hand in figuring out how to get the bundle.name and bundle.id of the bundle where the Camel route lives in the MDC map. [1] http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.logging/pax-logging-api/1.7.0/org/ops4j/pax/logging/internal/BundleHelper.java#BundleHelper.SecurityManagerEx Regards, *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 On Thu, Nov 21, 2013 at 7:25 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Why is it you need that ClassLoader in the first place? > > > On Wed, Nov 20, 2013 at 1:31 AM, Raul Kripalani <r...@evosent.com> 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 > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: cib...@redhat.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen >
