Return-Path: X-Original-To: apmail-camel-dev-archive@www.apache.org Delivered-To: apmail-camel-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A0D7618E7E for ; Tue, 2 Feb 2016 07:12:29 +0000 (UTC) Received: (qmail 20845 invoked by uid 500); 2 Feb 2016 07:12:29 -0000 Delivered-To: apmail-camel-dev-archive@camel.apache.org Received: (qmail 20792 invoked by uid 500); 2 Feb 2016 07:12:29 -0000 Mailing-List: contact dev-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list dev@camel.apache.org Delivered-To: moderator for dev@camel.apache.org Received: (qmail 20472 invoked by uid 99); 1 Feb 2016 22:14:35 -0000 X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.314 X-Spam-Level: ** X-Spam-Status: No, score=2.314 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, URIBL_BLOCKED=0.001, URI_HEX=1.313] autolearn=disabled Date: Mon, 1 Feb 2016 15:14:25 -0700 (MST) From: Ranx To: dev@camel.apache.org Message-ID: <1454364865220-5777123.post@n5.nabble.com> Subject: OSGi strict mode flag MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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.