Hi Claus, I thought about that, but I don't think it'll work.
Definitely not for the CamelLogger class; and I'm 90% confident that it won't work either for the CamelLogProcessor, as it doesn't live in the Registry. It is constructed programmatically. Given that route initialization/construction happens in a single thread, my idea is to create a CurrentCamelConfig class (naming WIP) with static methods to "pin" a CamelContext to a thread via a ThreadLocal, i.e. CurrentCamelConfig.setCamelContext(); <= used by the constructors of Camel Contexts to pin themselves to the thread CurrentCamelConfig.getCamelContext(); <= used by any configuration-time element that wishes to access the CamelContext thereafter CurrentCamelConfig.clearCamelContext(); <= called when configuration is complete or fails, to release the reference to the CamelContext (otherwise it won't be GC'ed). This is analogous to the technique used by JSF with FacesContext.getCurrentInstance(). Like this, any component down "the configuration stream" can access the CamelContext through: CurrentCamelConfig.getCamelContext(); 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 Wed, Nov 20, 2013 at 7:42 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > You can implement CamelContextAware and have CamelContext injected. > Though this only happens for services and whatnot Camel setup for you. > > Not sure if it the injection would happen for these classes you mention > though. > > > 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 >
