As Richard said, there's no easy way to solve the problem. What we've done in Karaf / Servicemix / Camel where needed is that when using a library that require a TCCL to be set for finding classes or resources, we set it locally before calling that library. A cleaner API would be to actually pass a classloader directly (JaxbContext does that for example IIRC), but it's basically the same: the caller needs to build / find the classloader, so it does not really change anything.
On Tue, Jan 18, 2011 at 21:35, boday <[email protected]> wrote: > > This remains a common/widespread issue and a cumbersome work around. Is > there an alternative to this approach? Has this issue been solved in > Felix/Karaf or is it simply not possible to at the container level? > > I've read about several different approaches to this including Context > Finder, Buddy Policy, etc. > > here are a few references that I found... > > http://wiki.eclipse.org/Context_Class_Loader_Enhancements (for equinox) > > http://stackoverflow.com/questions/2198928/better-handling-of-thread-context-classloader-in-osgi > (no responses) > > If there is a more definitive explanation of the issue and options, please > point me to it. > > thanks... > > ----- > ___________________________________ > Ben - Senior Consultant > using AMQ 5.3/Smx 4.2/Camel 2.2 > -- > View this message in context: > http://old.nabble.com/Can-the-thread-context-classloader-issue-be-solved-at-all--tp28260809p30704054.html > Sent from the Apache Felix - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
