On 3/30/12 12:41 PM, "Bram de Kruijff" <[email protected]> wrote:
>On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann ><[email protected]> wrote: >> 2012/3/30 Holger Hoffstätte <[email protected]>: >> >>> I don't know if that is "what you want" (or not), but it is certainly >>>not >>> what would happen. :) The Bundles will be installed into the framework >>>as >>> if installed "manually", and each will have its own classloader. >>> Essentially you will play the role of a deployment agent, which means >>>you >>> will also be responsible for starting, stopping and eventually >>> uninstalling the bundles, as necessary. >> >> What I want is a new ClassLoader with all those bundles and the given >>parent. > >You can't do that. When you install a bundle it gets a >BundleClassloader that gets wired to other bundle's classloaders >according to it's import directives and the Parent/System classloader >for boot delegation. Having one specified parent classloader kind of >defies the purpose. Have a look at the OSGi specification for an >explanation of the class loading architecture. > >What you can do is use an approach like the PAX swissbox >BundleClassLoader [0] which takes a parent to consult first, but that >still will not make the bundles classloader delegate back to it when >it needs to load a class not physically inside the jar It is possible to have jars private to a bundle by way of the "Bundle-ClassPath" entry. Is there a way to do this programmatically? You still wouldn't be able to parent it the way you want. My advice, after years of this, is that every time you're going against the grain of the OSGI framework, you're better off changing your behavior to adapting the existing system to better confirm to the OSGI system. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
