camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Johnson (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CAMEL-9562) OSGi classloader problem
Date Tue, 09 Feb 2016 17:43:18 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139277#comment-15139277
] 

Brad Johnson edited comment on CAMEL-9562 at 2/9/16 5:43 PM:
-------------------------------------------------------------

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 they currently do.  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); }

} 



was (Author: ranx):
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)

Mime
View raw message