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/03 08:20:02 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
Hi,
Am Mittwoch, den 02.01.2008, 12:00 +0200 schrieb Jukka Zitting:
> Hi,
>
> On Jan 2, 2008 10:18 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> > My changes to the code use (some ugly) method reflection instead of
> > relying on a specific interface. We could either go this way (in addition
> > we could also check if the repository in question implements the
> > interface by checking for the interface *name*) or we could require
> > that the jackrabbit api is put into a shared class loader. For ease
> > of use I would go the first way.
>
> The "correct" solution would IMHO be to have the Jackrabbit API in a
> shared class loader, just like the JCR API.
I completely agree.
And no, there is no third solution, because the second is the right
one :-)
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
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>.
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:
> 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.
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.
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>.
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.
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:
>
> As long as the Jackrabbit API jar file is in the class path, the Sling
> Web App (launcher/webapp) is configured to include the jackrabbit API in
> the boot class path. See
>
> http://svn.apache.org/repos/asf/incubator/sling/trunk/launcher/webapp/src/main/webapp/WEB-INF/jcr-client.properties
>
Yes, thanks - that was what I found and meant with indirections :)
Anyway, it works as expected so I reverted the change.
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.
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 Carsten,
Am Donnerstag, den 03.01.2008, 13:42 +0100 schrieb Carsten Ziegeler:
> Carsten Ziegeler wrote:
> > Felix Meschberger wrote:
> >> Not quite: The launcher should be configured such that the Jackrabbit
> >> API classes are added to the bootclass path just like the JCR API
> >> classes. You still need the jcr/api bundle because it also has the
> >> session pooling.
> > Yes, right.
> >
> >> Thanks you OSGi package resolution, the JCR API and Jackrabbit API
> >> classes will be used from the system bundle and not from the jcr/api
> >> bundle - this is why bundles exporting packages must also import these
> >> packages.
> >>
> > Yepp - is the jcr api currently already added to the boot classpath?
> >
> Ok, the answer is yes - I got a little bit lost in the indirection of
> "sling.include.*" with the property file :)
>
> So I'll try if putting the jackrabbit api into the boot classpath will
> solve the problem and then revert the change.
As long as the Jackrabbit API jar file is in the class path, the Sling
Web App (launcher/webapp) is configured to include the jackrabbit API in
the boot class path. See
http://svn.apache.org/repos/asf/incubator/sling/trunk/launcher/webapp/src/main/webapp/WEB-INF/jcr-client.properties
Regards
Felix
>
> Carsten
>
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>.
Carsten Ziegeler wrote:
> Felix Meschberger wrote:
>> Not quite: The launcher should be configured such that the Jackrabbit
>> API classes are added to the bootclass path just like the JCR API
>> classes. You still need the jcr/api bundle because it also has the
>> session pooling.
> Yes, right.
>
>> Thanks you OSGi package resolution, the JCR API and Jackrabbit API
>> classes will be used from the system bundle and not from the jcr/api
>> bundle - this is why bundles exporting packages must also import these
>> packages.
>>
> Yepp - is the jcr api currently already added to the boot classpath?
>
Ok, the answer is yes - I got a little bit lost in the indirection of
"sling.include.*" with the property file :)
So I'll try if putting the jackrabbit api into the boot classpath will
solve the problem and then revert the change.
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 Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
>
> Not quite: The launcher should be configured such that the Jackrabbit
> API classes are added to the bootclass path just like the JCR API
> classes. You still need the jcr/api bundle because it also has the
> session pooling.
Yes, right.
>
> Thanks you OSGi package resolution, the JCR API and Jackrabbit API
> classes will be used from the system bundle and not from the jcr/api
> bundle - this is why bundles exporting packages must also import these
> packages.
>
Yepp - is the jcr api currently already added to the boot classpath?
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 Donnerstag, den 03.01.2008, 10:27 +0100 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
> > Hi,
> >
> > Am Mittwoch, den 02.01.2008, 12:00 +0200 schrieb Jukka Zitting:
> >> Hi,
> >>
> >> On Jan 2, 2008 10:18 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> >>> My changes to the code use (some ugly) method reflection instead of
> >>> relying on a specific interface. We could either go this way (in addition
> >>> we could also check if the repository in question implements the
> >>> interface by checking for the interface *name*) or we could require
> >>> that the jackrabbit api is put into a shared class loader. For ease
> >>> of use I would go the first way.
> >> The "correct" solution would IMHO be to have the Jackrabbit API in a
> >> shared class loader, just like the JCR API.
> >
> > I completely agree.
> >
> > And no, there is no third solution, because the second is the right
> > one :-)
> >
> Oh :(
>
> Ok, if the second solution is the right one this means that in this case
> more or less the whole jcr api bundle should not be used but these
> classes should be loaded via the root class loader, right?
Not quite: The launcher should be configured such that the Jackrabbit
API classes are added to the bootclass path just like the JCR API
classes. You still need the jcr/api bundle because it also has the
session pooling.
Thanks you OSGi package resolution, the JCR API and Jackrabbit API
classes will be used from the system bundle and not from the jcr/api
bundle - this is why bundles exporting packages must also import these
packages.
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 Mittwoch, den 02.01.2008, 12:00 +0200 schrieb Jukka Zitting:
>> Hi,
>>
>> On Jan 2, 2008 10:18 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> My changes to the code use (some ugly) method reflection instead of
>>> relying on a specific interface. We could either go this way (in addition
>>> we could also check if the repository in question implements the
>>> interface by checking for the interface *name*) or we could require
>>> that the jackrabbit api is put into a shared class loader. For ease
>>> of use I would go the first way.
>> The "correct" solution would IMHO be to have the Jackrabbit API in a
>> shared class loader, just like the JCR API.
>
> I completely agree.
>
> And no, there is no third solution, because the second is the right
> one :-)
>
Oh :(
Ok, if the second solution is the right one this means that in this case
more or less the whole jcr api bundle should not be used but these
classes should be loaded via the root class loader, right?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org