You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2008/01/04 10:07:56 UTC
Re: svn
commit: r607215 - in /incubator/sling/trunk/jcr/api/src/main/java/org/apache/sling/jcr/api:
NodeTypeLoader.java internal/loader/Loader.java
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
Re: svn
commit: r607215 - in /incubator/sling/trunk/jcr/api/src/main/java/org/apache/sling/jcr/api:
NodeTypeLoader.java internal/loader/Loader.java
Posted by Felix Meschberger <fm...@gmail.com>.
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
>
Re: svn commit: r607215 - in /incubator/sling/trunk/jcr/api/src/main/java/org/apache/sling/jcr/api:
NodeTypeLoader.java internal/loader/Loader.java
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi,
>
> Am Freitag, den 04.01.2008, 10:24 +0100 schrieb Carsten Ziegeler:
>> Felix Meschberger wrote:
>>
>>> (Warning: longish OSGi specific text ahead :-) )
>> Hehe, thanks for the warning - so I stopped reading here... :)
>>
>> Very good explanation - what about adding these things to our wiki?
>
> Done in our brand-new FAQ page [1] :-)
>
Awesome :)
Thanks
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re:
svn commit: r607215 - in /incubator/sling/trunk/jcr/api/src/main/java/org/apache/sling/jcr/api:
NodeTypeLoader.java internal/loader/Loader.java
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 04.01.2008, 10:24 +0100 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
>
> > (Warning: longish OSGi specific text ahead :-) )
>
> Hehe, thanks for the warning - so I stopped reading here... :)
>
> Very good explanation - what about adding these things to our wiki?
Done in our brand-new FAQ page [1] :-)
Regards
Felix
[1] http://cwiki.apache.org/SLING/faq.html
>
> Thanks
> Carsten
> >
> > 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
> >
> >
> >
>
>
Re: svn commit: r607215 - in /incubator/sling/trunk/jcr/api/src/main/java/org/apache/sling/jcr/api:
NodeTypeLoader.java internal/loader/Loader.java
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> (Warning: longish OSGi specific text ahead :-) )
Hehe, thanks for the warning - so I stopped reading here... :)
Very good explanation - what about adding these things to our wiki?
Thanks
Carsten
>
> 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
>
>
>
--
Carsten Ziegeler
cziegeler@apache.org