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] [Commented] (CAMEL-9562) OSGi classloader problem
Date Tue, 09 Feb 2016 18:36:18 GMT

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

Brad Johnson commented on CAMEL-9562:
-------------------------------------

I'd like to add that I probably had something misconfigured in one of the bundles.  But I'd
want that to fail hard.

> 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