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
