[CAMEL-9562] OSGi classloader problem

• Type: Improvement
• Status: Resolved
• Priority: Minor
• Resolution: Abandoned
• Affects Version/s: 2.16.2
• Component/s: camel-osgi
• Estimated Complexity: Moderate
• Flags: Important
• Assignee: Unassigned
• Reporter: Brad Johnson
• Created: 02/Feb/16 16:48
• Updated: 31/Jul/19 09:22
• Resolved: 31/Jul/19 09:22

Description

At least: OSGiClassResolver and OSGiPackageScanner but probably others. A strict mode flag should be added to enforce using the OSGi classloader. By default it could be false to be backwardly compatible but when it set to true then the secondary attempt at using the application context classloader would be circumvented. This should really be the default behavior in an OSGi environment but because of backward compatibility issues that might not be possible.

This fix should be relatively easy and unnoticeable by most. But for those working OSGi environments we usually want the strict mode in order to be in compliance with OSGi. Without it the current design reflects a classloader leak that shouldn't be allowed. If a class can't be found then it isn't being exported correctly or a bundle is hiding a class it shouldn't or Camel blueprint isn't being set up correctly or.... But in all cases it should fail.

The OSGi classloader mechanics includes a fall back mechanism that uses the global classloader to find classes if it can't find them in OSGi registry it cheats with SU.
OSGiClassResolver:
if (clazz == null && camelContext != null) {
// fallback and load class using the application context classloader
clazz = super.loadClass(name, camelContext.getApplicationContextClassLoader());
if (LOG.isTraceEnabled()) {
LOG.trace("Loading class {} using CamelContext {} -> {}", new Object[]

{name, camelContext, clazz}

);
}
}

OSGiPackageScanClassResolver.
// if we did not find any new, then fallback to use regular non bundle class loading
if (classes.size() == classesSize) {
// Using the non-OSGi classloaders as a fallback
// this is necessary when use JBI packaging for servicemix-camel SU
// so that we get chance to use SU classloader to scan packages in the SU
log.trace("Cannot find any classes in bundles, not trying regular classloaders scanning: {}", packageName);
for (ClassLoader classLoader : super.getClassLoaders()) {
if (!isOsgiClassloader(classLoader))

{ find(test, packageName, classLoader, classes); }

}
}

Issue Links

• relates to: CAMEL-9570 Blueprint Proxies are not used when injected into Java RouteBuilders