camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ranx <>
Subject Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Date Mon, 01 Feb 2016 17:51:01 GMT
I think in my case the problem was with how the package scan is working but
I'm not positive.  In the Camel Core OSGi package scanner class there is a
section.  If it can find it in OSGi it shrugs, throws up its hands and
resorts to brute force classloading.  Instead of getting hard error Camel
was being accommodating and instantiating a non-proxied version of the

    public void find(PackageScanFilter test, String packageName,
Set<Class&lt;?>> 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 trying
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 - Users mailing list archive at

View raw message