You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2008/01/04 10:24:52 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
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
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
> >
> >
> >
>
>