In theory, what should happen is that the bundle X uses class A from the system bundle and effectively ignores its local copy. This is possible if bundle X both exports and imports the package containing A (which is the case in the case of the Sling JSP bundle) and the version exported from the system bundle is compatible with the version imported by bundle X.
Would highly recommend you read Section 3 of the OSGi spec where this is all laid out (Section 3.7 specifically). Justin On Mon, Apr 11, 2011 at 12:03 PM, tim tam <[email protected]> wrote: > How does that work, if there is already a bundle X that loads class A AND I > specify system bundle to export class A (javax.jsp ) classes ? > > The bundle X exports class A (javax.jsp of specific versions) and my > environment has them in a different version. I want all the bundles that > import these classes to get it from my system bundle as opposed to bundle X. > > > Which bundle (bundleX or system bundle) has precedence in terms of where the > class is loaded from ? what if the versions are different... I am not > grokking something very important here... thanks > Tim > On Mon, Apr 11, 2011 at 9:41 AM, Justin Edelson > <[email protected]>wrote: > >> As you surmised, class A needs to be loaded by C1 (or a parent of C1). >> >> In this particular case, you should have the system bundle export the >> javax.jsp classes so that the Sling JSP bundle will import them from >> the system bundle. You can do this by providing an system bundle >> fragment or (more simply) editing sling.properties. See >> http://sling.apache.org/site/configuration.html for examples of how to >> add packages to the system bundle's exports. >> >> Justin >> >> >> On Sun, Apr 10, 2011 at 9:48 PM, tim tam <[email protected]> wrote: >> > I need to understand how this works fully in order to trouble shoot >> issues I >> > am having. >> > >> > I think I have a handle on how osgi provides modularity by limiting >> > visibility of types via classloaders. I am just not sure how that works >> with >> > something like weblogic container especially in some situations >> > >> > Let say I have the following situation: >> > >> > 1. sling deployed in a war >> > >> > 2. class B taglib class that is a subclass of A, class B is loaded by >> > applicating level classloader C1 >> > >> > 3. class A loaded by osgi bundles classloader C2 (eg javax classes for >> jsp >> > scripting) >> > >> > B cannot be cast to A since they are not really related typewise as they >> are >> > loaded by different classloaders... >> > >> > how is this supposed to be handled ? >> > If I jave a class A that is provided by the environment classloader and >> also >> > a bundle, but a subclass of that class B needs to come from the >> > enviroment... >> > >> > I am having trouble loading custom taglib classes through application >> > classloader, when the jsp stuff is loaded by a bundle... does the taglib >> > HAVE to be made into a bundle ? >> > >> > If I specify boot delegation for classA (in my case the jsp javax >> classes) >> > would that work ? I am getting tired of trying combinations I need to >> think >> > of a more reasonable approach. >> > >> > Thanks >> > Tim >> > >> >
