OSGi strict mode flag

[Ranx <br...@mediadriver.com>]

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
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/OSGi-strict-mode-flag-tp5777123.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: OSGi strict mode flag

[Claus Ibsen <cl...@gmail.com>]

Hi

Yeah JBI is dead a long time ago. We could try to remove that old code.
You are welcome to do a patch/PR and log a JIRA

On Mon, Feb 1, 2016 at 11:14 PM, Ranx <br...@mediadriver.com> wrote:
> 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
> 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/OSGi-strict-mode-flag-tp5777123.html
> Sent from the Camel Development mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2