FYI, the Felix list message is here: http://www.mail-archive.com/dev%40felix.apache.org/msg02700.html
Regards Felix Am Freitag, den 04.01.2008, 10:07 +0100 schrieb Felix Meschberger: > Am Freitag, den 04.01.2008, 09:16 +0100 schrieb Carsten Ziegeler: > > Felix Meschberger wrote: > > > Am Donnerstag, den 03.01.2008, 14:00 +0100 schrieb Carsten Ziegeler: > > >> But it seems that the osgi console is in these cases not displaying the > > >> imports correctly: the javax.jcr classes are not listed in the imported > > >> packages list of the jcr api bundle. > > > > > > This is strange, as I can see this import - at least when running > > > standalone. > > > > > Yes, I just retested again. If I don't put the jackrabbit api classes > > into the startup class path of the servlet engine (and therefore into > > the boot classpath of sling), I get classcast exceptions. > > This is expected. Cool. > > > If I put the lib there, everything works - so it seems that the classes > > are loaded from there. But in this case the display in the web console > > still displays that the jcr and jackrabbit classes are coming from the > > jcr api bundle - which seems to be wrong. > > (Warning: longish OSGi specific text ahead :-) ) > > Hmm, this is an interesting question needing some elaboration. First of > all, OSGi defines two framework properties concerning class loading: > > org.osgi.framework.bootdelegation : All classes matching any entry in > this list > are always loaded from the parent class loader and not through > the OSGi > framework infrastructure. > > org.osgi.framework.system.packages : Additional package declarations > for packages > to be exported from the system bundle. This property is a > simple package > declaration list just like any Export-Package manifest header > > Currently, Sling uses the bootdelegation property to list additional > classes to be used from the environment. This is done in the > org.apache.sling.launcher.app.Sling.resolve() method. > > This raises two questions: > > * Why does Sling use bootdelegation ? Maybe because I was initially > worried by the > requirement for the system.packages property that "Exposing > packages from the parent > class loader in this fashion must also take into account any uses > directives of the > underlying packages." (OSGi Core R4.1, Section 3.8.5, Parent > Class Loader). And I > couldn't create the uses directives.. > > Maybe we might just not provide the "uses" and still use the > system.packages property ? > WDYT ? > > > * Why does the Sling console list the packages as imported from the > API bundle ? I can only > explain this such, that when Apache Felix Framework resolves the > package it resolves > all imports as instructed. So, there are the imports from the API > bundle. But to load > the classes actually, the bundle class loader asks the parent > class loader for the > "bootdelegation" classes (see step two in the process described > in OSGi Core R4.1, > Section 3.8.4, Overall Search Order). Hence it works as expected. > Remains the question: Should a package contained in the > "bootdelegation" actually be > resolved ? This would of course be a question for the Felix Dev > List ... Will post > it there. > > > Regards > Felix >
