camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ranx <>
Subject OSGi strict mode flag
Date Mon, 01 Feb 2016 22:14:25 GMT
This past week I ran into a bug that I found almost inadvertently.  Using a
package scan for route builders the karaf instance fired up and "found" my
service.  Unfortunately what it did was loaded a class that was private to
another bundle.  Obviously I had something misconfigured as it didn't find a
proxy of the interface.  Checking the code for the OSGi Package scanner I
found the catch all classloader mechanism at the end.  

I'm not sure how relevant JBI is anymore but even if it weren't there are
likely plenty of instance applications deployed right now that are
inadvertently using non-OSGi classloading and working, sort of.  So just
taking it out isn't likely an option.  But adding a new flag "strict" that,
when set to true, would byepass any non-OSGi classloading.  If that flag is
set, then any request for a class or service that isn't available in the
standard OSGi way would result in a hard error.  By default the flag could
be set to false so it wouldn't break anything backwardly but on new projects
it could be globally set to true and enforce strict OSGi standards.

I'm just showing this is in the package scanner but I suspect this isn't the
only place it resorts to a fallback to a global classloader solution.

  public void find(PackageScanFilter test, String packageName,
Set<Class> classes) {
        packageName = packageName.replace('.', '/');
        // remember the number of classes found so far
        int classesSize = classes.size();
        // look in osgi bundles
        loadImplementationsInBundle(test, packageName, classes);
        // 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
            // so that we get chance to use SU classloader to scan packages
in the SU             log.trace("Cannot find any classes in bundles, not
regular classloaders scanning: {}", packageName);
            for (ClassLoader classLoader : super.getClassLoaders()) {
                if (!isOsgiClassloader(classLoader)) {
                    find(test, packageName, classLoader, classes);

View this message in context:
Sent from the Camel Development mailing list archive at

View raw message