Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder

[Ranx]

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
class.


    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
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);
                }
            }  
        }
    }
    



--
View this message in context: 
http://camel.465427.n5.nabble.com/Invoking-Dynamic-OSGi-Blueprint-services-from-a-Java-RouteBuilder-tp5776755p5777108.html
Sent from the Camel - Users mailing list archive at Nabble.com.