Frank, The difference is to do with implicit versus explicit dependencies.
As a general rule, if you use any package you must import it so that your dependencies are fully self-documenting. This applies just as much to JRE packages as it applies to “normal” application packages (the sole exception is the java.* packages because these must only ever be loaded by the boot classloader; this is a hard rule of the Java platform). The problem of course is that you sometimes depend on packages from the Java runtime that are not Java SE packages and therefore not exported by the framework. This is why we have the org.osgi.framework.system.packages and org.osgi.framework.system.packages.extra properties. In general you should always prefer this to bootdelegation. The bootdelegation feature in OSGi is really intended as a workaround for some assumptions made in JRE implementations. Certain internal classes are expected to be visible from *any* classloader, which would not normally be the case in OSGi, and so they have to be added to bootdelegation. You may also need to use bootdelegation when you have a bytecode instrumentation tool, e.g. a code coverage or performance measurement tool that adds a little bit of code to every class. The instrumented code usually has dependencies, but you wouldn’t want to explicitly add to the Import-Package statement of every bundle because you will probably remove the instrumentation before the bundle goes into production. For me, the risks associated with bootdelegation are quite severe. The first is that a bundle might seem to be working, but only accidentally due to the bootdelegation setting of the platform you are running it on. When you move it to another OSGi application it suddenly throws NoClassDefFoundError. You should have imported the package, because then it’s clear to everybody what needs to be done to make the bundle work. The second problem is that bootdelegation overrides the choices of every bundle. When you put a package in bootdelegation, it’s not just that every bundle “can” use that package… in fact every bundle *must* use that package, even if they had their own copy or if they wanted to import a different version, etc. In other words it breaks the foundation of OSGi’s modularity. Unfortunately I can’t help with the problem you’re experiencing in Camel. You might want to try the Camel-specific mailing list. Neil > On 6 May 2015, at 15:49, Frank Langel <fr...@frankjlangel.com> wrote: > > Hello, > > question regarding bootdelegation vs > org.osgi.framework.system.packages.extra if I may: > > Here my understanding > ===================== > > 1. When I add additional packages to > org.osgi.framework.system.packages.extra (using -runsystempackages in > BndTools) , OSGI adds the packages to the system bundle and if a class X > is not found in a bundle itself (either through its imports or in its > private space), it tries to find this class using the system bundle. > > 2. If the system bundle exports the class, it will be found > > 3. This always worked fine using sun.misc ( I always use > -runsystempackages) in other cases > > 4. However, when I try in corporate camel, I need to set the boot > delegatio to =sun.misc as described here > http://www.liferay.com/community/forums/-/message_boards/message/46779514 > > > -runproperties: \ > org.osgi.framework.bootdelegation=sun.misc > > Above works fine, and my Unsafe class is found. > > > My question > =========== > > A. Why wouldnąt the camel bundle be able to find the Unsafe class that was > exported from the system bundle, why do I have to add it the the JVM class > loader via boot delegation? > > B. Is adding classes to the boot delegation dangerous ? I know its not > considered best practice > > Thanks a lot in advance > Frank > > > Appendix > ======== > > Links/Docu: > ---------- > http://wiki.osgi.org/wiki/Boot_Delegation > > http://moi.vonos.net/java/osgi-classloaders/ > > > MiniApp: > -------- > > > @Component(immediate=true) > public class RunCamelContext { > > private BundleContext context; > > @Activate > public void activate(BundleContext context){ > this.context = context; > > CamelContext camelContext = new OsgiDefaultCamelContext(context); > System.out.println("Activated OSGI is working"); > > } > > > } > > > > > Error without Boot Delegation: > ------------------------------ > > > java.lang.NoClassDefFoundError: sun/misc/Unsafe > at > org.apache.camel.com.googlecode.concurrentlinkedhashmap.ConcurrentHashMapV8 > .getUnsafe(ConcurrentHashMapV8.java:4136) > at > org.apache.camel.com.googlecode.concurrentlinkedhashmap.ConcurrentHashMapV8 > .<clinit>(ConcurrentHashMapV8.java:4101) > at > org.apache.camel.com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHas > hMap.<init>(ConcurrentLinkedHashMap.java:221) > at > org.apache.camel.com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHas > hMap.<init>(ConcurrentLinkedHashMap.java:104) > at > org.apache.camel.com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHas > hMap$Builder.build(ConcurrentLinkedHashMap.java:1598) > at org.apache.camel.util.LRUCache.<init>(LRUCache.java:84) > Š > > at aQute.launcher.Launcher.main(Launcher.java:90) > Caused by: java.lang.ClassNotFoundException: sun.misc.Unsafe not found by > org.apache.camel.camel-core [15] > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation > (BundleWiringImpl.java:1532) > at > org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.jav > a:75) > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(Bun > dleWiringImpl.java:1955) > at java.lang.ClassLoader.loadClass(ClassLoader.java:358) > > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
