[
https://issues.apache.org/jira/browse/CAMEL-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139277#comment-15139277
]
Brad Johnson commented on CAMEL-9562:
-------------------------------------
I doubt that it could be removed at this point. I found the issue as I was
moving between blueprint and the package scanner for route builders and found
that when I ran it it was not proxying the private implementation of a service
from another bundle. The actual class was being used. That means there are
likely folks out there who have functioning code in place that functions due to
a classloader leak. The only reason I noticed it was some flakiness I was
seeing when I would swap bundles. I'd get exceptions due to the missing
implementation. After running a restart on the bundle it worked.
So a Boolean strictMode setting that could be set in the configuration file for
future projects would likely be required so that already deployed code would
not break. By default the strictMode would be set to false and checked as
follows. The default would be Boolean.FALSE so all mechanics would work as
expected. For new projects that could be set to TRUE and breaks could be dealt
with.
OSGiPackageScanClassResolver.
// if we did not find any new, then fallback to use regular non bundle class
loading
if(strictMode.equals(Boolean.TRUE) throw new
ClassNotFoundInOSGiRegistryException(clazz);
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); }
}
> OSGi classloader problem
> ------------------------
>
> Key: CAMEL-9562
> URL: https://issues.apache.org/jira/browse/CAMEL-9562
> Project: Camel
> Issue Type: Improvement
> Components: camel-osgi
> Affects Versions: 2.16.2
> Reporter: Brad Johnson
> Priority: Minor
>
> 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);
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
