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 2009/11/27 14:47:49 UTC
Jackrabbit 2.0 support for OSGi/Sling
Hi all,
Right now we have a number of JCR related bundles in Sling. With the JCR
API 2.0 now public and Jackrabbit runnuning towards its first 2.0
release providing full JCR API 2.0 support, I wonder where we would be
heading with these bundles....
I would like to hear your opinions how to handle the Jackrabbit based
bundles in the future.
I would think some bundles belong to Sling (e.g. the compiler or prefs
bundles). Some bundles would rather belong to the Jackrabbit project.
But then I am not sure about some bundles ....
Here are the bundles I am talking about
bundles/jcr/api
Provides the SlingRepository iterface. This bundle just
depends on JCR and has no Jackrabbit dependencies.
--> Keep it here
bundles/jcr/base
Provides an abstract base implementation of the SlingRepository
interface and has Jackrabbit dependencies.
--> Investigate separation of Jackrabbit specific and generic
JCR parts and split the bundle in two: The Jackrabbit part goes
to Jackrabbit, the JCR-only part remains here
bundles/jcr/classloader
Depends on the Jackrabbit JCR Classloader but extends it for
some Sling specific parts.
--> Keep it here
bundles/jcr/contentloader
Initial Content Loader, currently has dependency on Jackrabbit
API for ACL stuff. For JCR 2.0 this will be converted into a
pure JCR 2.0 dependency, hence be completely independent of
Jackrabbit
--> Keep it or offer to Jackrabbit ?
bundles/jcr/jackrabbit-accessmanager
Access Control Management servlets leveraging Sling
functionality.
--> Keep it here
bundles/jcr/jackrabbit-server
Embedded Jackrabbit Repository providing Service API to plugin
LoginModules as OSGi services.
--> Offer to Jackrabbit
bundles/jcr/jackrabbit-usermanager
User Manager for Jackrabbit (might be converted into a generic
JCR 2.0 user manager ?) leveraging Sling functionality.
--> Keep it here
bundles/jcr/ocm
OSGi bundle with Jackrabbit-OCM providing a Sling
AdapterFactory for resources. Plugs heavily into Sling.
--> Keep it here or offer to Jackrabbit ?
bundles/jcr/resource
JCRResourceResolver
--> We keep this ;-)
bundles/jcr/webdav
(Simple) WebDAV servlet(s)
--> Offer to Jackrabbit
contrib/jcr/compiler
Compiles Java Classes into the Repository. This is part of
Sling.
--> Keep it here
contrib/jcr/jackrabbit-api
Old OSGi bundle wrapping of Jackrabbit API. This is not used
any longer, since Jackrabbit already provides OSGi bundles of
some libraries, including the Jackrabbit API
--> Deprecate and remove sometime in the future (move to "attic"?)
contrib/jcr/jackrabbit-client
Provides access to non-embedded repositories, mostly Jackrabbit
oriented.
--> Offer to Jackrabbit
contrib/jcr/prefs
JCR bindings for the Apache Felix OSGi Preferences Service
implementation.
--> Keep it here
I have inlined my opinions with respect to each bundle (marked with -->).
Please comment. Thanks alot.
Regards
Felix
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Ian Boston <ie...@tfd.co.uk>.
On 30 Nov 2009, at 08:50, Felix Meschberger wrote:
> Hi Jukka,
>
> Jukka Zitting schrieb:
>> Hi,
>>
>> On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <fmeschbe@gmail.com
>> > wrote:
>>> bundles/jcr/classloader
>>> Depends on the Jackrabbit JCR Classloader but extends it for
>>> some Sling specific parts.
>>> --> Keep it here
>>
>> Would Sling be interested in taking over the entire JCR Classloader
>> codebase? I don't see much development of it in Jackrabbit and I
>> don't
>> think the component is used too much beyond Sling. For maintenance
>> and
>> further development it might be easier if this was just a single
>> component.
>
> I would think, that merging the Sling and Jackrabbit codebases with
> respect to the classloader (while trying to maintain support for using
> the classloader in a non-OSGi environment) would probably make sense.
>
> Other opinions ?
Structurally, that makes sense to me,
but my view is probably not well informed as the jcr classloader is an
area where I haven't spent much time.
Ian
>
> Regards
> Felix
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi Jukka,
>
> Jukka Zitting schrieb:
>> Hi,
>>
>> On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <fm...@gmail.com> wrote:
>>> bundles/jcr/classloader
>>> Depends on the Jackrabbit JCR Classloader but extends it for
>>> some Sling specific parts.
>>> --> Keep it here
>> Would Sling be interested in taking over the entire JCR Classloader
>> codebase? I don't see much development of it in Jackrabbit and I don't
>> think the component is used too much beyond Sling. For maintenance and
>> further development it might be easier if this was just a single
>> component.
>
> I would think, that merging the Sling and Jackrabbit codebases with
> respect to the classloader (while trying to maintain support for using
> the classloader in a non-OSGi environment) would probably make sense.
>
Yes merging seems to make sense - if there is no need at jackrabbit for this
stuff, maybe there is no need for this classloader in a non-osgi env either?
If it is easy to support the non-osgi env, we should do it; if not, I
don't see it as a requirement atm.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Jukka,
Jukka Zitting schrieb:
> Hi,
>
> On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> bundles/jcr/classloader
>> Depends on the Jackrabbit JCR Classloader but extends it for
>> some Sling specific parts.
>> --> Keep it here
>
> Would Sling be interested in taking over the entire JCR Classloader
> codebase? I don't see much development of it in Jackrabbit and I don't
> think the component is used too much beyond Sling. For maintenance and
> further development it might be easier if this was just a single
> component.
I would think, that merging the Sling and Jackrabbit codebases with
respect to the classloader (while trying to maintain support for using
the classloader in a non-OSGi environment) would probably make sense.
Other opinions ?
Regards
Felix
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <fm...@gmail.com> wrote:
> bundles/jcr/classloader
> Depends on the Jackrabbit JCR Classloader but extends it for
> some Sling specific parts.
> --> Keep it here
Would Sling be interested in taking over the entire JCR Classloader
codebase? I don't see much development of it in Jackrabbit and I don't
think the component is used too much beyond Sling. For maintenance and
further development it might be easier if this was just a single
component.
BR,
Jukka Zitting
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Vidar Ramdal <vi...@idium.no>.
On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Here are the bundles I am talking about
[...]
> bundles/jcr/contentloader
> Initial Content Loader, currently has dependency on Jackrabbit
> API for ACL stuff. For JCR 2.0 this will be converted into a
> pure JCR 2.0 dependency, hence be completely independent of
> Jackrabbit
> --> Keep it or offer to Jackrabbit ?
I'd like to do some more hacking on the contentloader when I get time.
Being a Sling commiter, and not a Jackrabbit commiter, I'd certainly
prefer to have it here. But maybe that's just being egoistic :)
Maybe there's also a third option (which may also apply to other
bundles): Keep it, but remove most/all dependencies to other Sling
bundles, so that our bundles can be used by other
projects/applications without using the entire Sling enchilada.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Ian Boston <ie...@tfd.co.uk>.
On 27 Nov 2009, at 13:47, Felix Meschberger wrote:
> Hi all,
>
> Right now we have a number of JCR related bundles in Sling. With the
> JCR
> API 2.0 now public and Jackrabbit runnuning towards its first 2.0
> release providing full JCR API 2.0 support, I wonder where we would be
> heading with these bundles....
>
> I would like to hear your opinions how to handle the Jackrabbit based
> bundles in the future.
>
> I would think some bundles belong to Sling (e.g. the compiler or prefs
> bundles). Some bundles would rather belong to the Jackrabbit project.
> But then I am not sure about some bundles ....
>
> Here are the bundles I am talking about
>
> bundles/jcr/api
> Provides the SlingRepository iterface. This bundle just
> depends on JCR and has no Jackrabbit dependencies.
> --> Keep it here
>
> bundles/jcr/base
> Provides an abstract base implementation of the
> SlingRepository
> interface and has Jackrabbit dependencies.
> --> Investigate separation of Jackrabbit specific and generic
> JCR parts and split the bundle in two: The Jackrabbit part
> goes
> to Jackrabbit, the JCR-only part remains here
>
> bundles/jcr/classloader
> Depends on the Jackrabbit JCR Classloader but extends it for
> some Sling specific parts.
> --> Keep it here
>
> bundles/jcr/contentloader
> Initial Content Loader, currently has dependency on Jackrabbit
> API for ACL stuff. For JCR 2.0 this will be converted into a
> pure JCR 2.0 dependency, hence be completely independent of
> Jackrabbit
> --> Keep it or offer to Jackrabbit ?
IMHO, keep, as it binds to OSGi and does things specific to Sling.
>
> bundles/jcr/jackrabbit-accessmanager
> Access Control Management servlets leveraging Sling
> functionality.
> --> Keep it here
>
> bundles/jcr/jackrabbit-server
> Embedded Jackrabbit Repository providing Service API to plugin
> LoginModules as OSGi services.
> --> Offer to Jackrabbit
IMHO, keep this,
There are some aspects of it that are needed for Sling like the plugins.
We might expect JR to create a OSGi Jackrabbit core bundle, but I
think Sling would need to customize it to take care of deployment
issues and local integration points.
I will declare some self interest since this is one of the remaining
bundles that I, with a Sakai hat on, havent been able to avoid
customizing, since the DefaultAccessManager wont cover quite a number
of our use cases and injecting one from a new bundle means writing a
huge amount of very complex code, not something I really want to do.
I am told that the DefaultAccessManager has been re-written for JCR2,
but when I looked at the ACLTemplate and ACLEditor code in svn trunk
it looked quite similar with group deny added (one of our use cases).
So I *am* a bit confused at the moment.
Ian
>
> bundles/jcr/jackrabbit-usermanager
> User Manager for Jackrabbit (might be converted into a generic
> JCR 2.0 user manager ?) leveraging Sling functionality.
> --> Keep it here
>
> bundles/jcr/ocm
> OSGi bundle with Jackrabbit-OCM providing a Sling
> AdapterFactory for resources. Plugs heavily into Sling.
> --> Keep it here or offer to Jackrabbit ?
>
> bundles/jcr/resource
> JCRResourceResolver
> --> We keep this ;-)
>
> bundles/jcr/webdav
> (Simple) WebDAV servlet(s)
> --> Offer to Jackrabbit
>
> contrib/jcr/compiler
> Compiles Java Classes into the Repository. This is part of
> Sling.
> --> Keep it here
>
> contrib/jcr/jackrabbit-api
> Old OSGi bundle wrapping of Jackrabbit API. This is not used
> any longer, since Jackrabbit already provides OSGi bundles of
> some libraries, including the Jackrabbit API
> --> Deprecate and remove sometime in the future (move to "attic"?)
>
> contrib/jcr/jackrabbit-client
> Provides access to non-embedded repositories, mostly
> Jackrabbit
> oriented.
> --> Offer to Jackrabbit
>
> contrib/jcr/prefs
> JCR bindings for the Apache Felix OSGi Preferences Service
> implementation.
> --> Keep it here
>
>
> I have inlined my opinions with respect to each bundle (marked with
> -->).
>
> Please comment. Thanks alot.
>
> Regards
> Felix
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
This sounds like a good compromise approach for those parts that we
ultimately offer to Jackrabbit: We feel some things belong more to
Jackrabbit than to Sling, yet we have some expertise in them and would
like to keep maintaining it.
So, I could imagine asking the Jackrabbit PMC whether they could open
the OSGi oriented subproject to Sling committers...
Regards
Felix
Bertrand Delacretaz schrieb:
> On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> ...I would think some bundles belong to Sling (e.g. the compiler or prefs
>> bundles). Some bundles would rather belong to the Jackrabbit project.
>> But then I am not sure about some bundles ....
>
> I haven't looked at the details yet, but some Apache projects (Cocoon
> and Forrest for example) give write access to some parts of their svn
> repository to committers of both projects.
>
> Committers are then just expected to ask or mention (depending on the
> importance of their changes) on the list of the project that "owns"
> the module when they commit changes, but technically they have full
> write access to those common modules.
>
> Maybe that would be a good solution for those bundles that do not
> clearly belong to one project or the other?
>
> We could also probably extend that to other OSGi-related projects
> where that makes sense.
>
> -Bertrand
>
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...I would think some bundles belong to Sling (e.g. the compiler or prefs
> bundles). Some bundles would rather belong to the Jackrabbit project.
> But then I am not sure about some bundles ....
I haven't looked at the details yet, but some Apache projects (Cocoon
and Forrest for example) give write access to some parts of their svn
repository to committers of both projects.
Committers are then just expected to ask or mention (depending on the
importance of their changes) on the list of the project that "owns"
the module when they commit changes, but technically they have full
write access to those common modules.
Maybe that would be a good solution for those bundles that do not
clearly belong to one project or the other?
We could also probably extend that to other OSGi-related projects
where that makes sense.
-Bertrand
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
I'll just comment on those were I have a different opinion or additional
comment :)
Felix Meschberger wrote:
> bundles/jcr/base
> Provides an abstract base implementation of the SlingRepository
> interface and has Jackrabbit dependencies.
> --> Investigate separation of Jackrabbit specific and generic
> JCR parts and split the bundle in two: The Jackrabbit part goes
> to Jackrabbit, the JCR-only part remains here
Not sure if it is worth to separate, I would just donate everything to
Jackrabbit. If other repository implementations are interested we can
investigate further.
> bundles/jcr/contentloader
> Initial Content Loader, currently has dependency on Jackrabbit
> API for ACL stuff. For JCR 2.0 this will be converted into a
> pure JCR 2.0 dependency, hence be completely independent of
> Jackrabbit
> --> Keep it or offer to Jackrabbit ?
Keep it.
> bundles/jcr/ocm
> OSGi bundle with Jackrabbit-OCM providing a Sling
> AdapterFactory for resources. Plugs heavily into Sling.
> --> Keep it here or offer to Jackrabbit ?
Keep it
>
> contrib/jcr/jackrabbit-api
> Old OSGi bundle wrapping of Jackrabbit API. This is not used
> any longer, since Jackrabbit already provides OSGi bundles of
> some libraries, including the Jackrabbit API
> --> Deprecate and remove sometime in the future (move to "attic"?)
I think we can just remove it.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Ian,
Ian Boston schrieb:
>
> On 4 Dec 2009, at 08:35, Felix Meschberger wrote:
>
>>>
>>> bundles/jcr/jackrabbit-server
>>> Embedded Jackrabbit Repository providing Service API to plugin
>>> LoginModules as OSGi services.
>>> --> Offer to Jackrabbit
>>
>> ==> Offer to Jackrabbit, but decide on "how" -- the most important
>> question is to ensure our extensions and to even go a step further and
>> support Ian's requirement for fully flexible access control plugin (not
>> requiring to extend DefaultAccessManager)
>
> If we could achieve that it would be fantastic, and save me lots of time
> in the future :), very happy to help.
Excellent ! I will come back as soon as I have sorted out a few things.
Regards
Felix
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Ian Boston <ie...@tfd.co.uk>.
On 4 Dec 2009, at 08:35, Felix Meschberger wrote:
>>
>> bundles/jcr/jackrabbit-server
>> Embedded Jackrabbit Repository providing Service API to
>> plugin
>> LoginModules as OSGi services.
>> --> Offer to Jackrabbit
>
> ==> Offer to Jackrabbit, but decide on "how" -- the most important
> question is to ensure our extensions and to even go a step further and
> support Ian's requirement for fully flexible access control plugin
> (not
> requiring to extend DefaultAccessManager)
If we could achieve that it would be fantastic, and save me lots of
time in the future :), very happy to help.
Thanks
Ian
Re: Jackrabbit 2.0 support for OSGi/Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
Thanks for your replies.
Here is a consolidated view of the replies with respect to my proposal
Felix Meschberger schrieb:
> bundles/jcr/api
> Provides the SlingRepository iterface. This bundle just
> depends on JCR and has no Jackrabbit dependencies.
> --> Keep it here
==> We keep it (maybe, depending on how we offer the Jackrabbit-Server
and Jackrabbit-Client bundles....)
> bundles/jcr/base
> Provides an abstract base implementation of the SlingRepository
> interface and has Jackrabbit dependencies.
> --> Investigate separation of Jackrabbit specific and generic
> JCR parts and split the bundle in two: The Jackrabbit part goes
> to Jackrabbit, the JCR-only part remains here
==> Investigate further... Potentially donate to Jackrabbit.
> bundles/jcr/classloader
> Depends on the Jackrabbit JCR Classloader but extends it for
> some Sling specific parts.
> --> Keep it here
==> Keep it and even continue on Jukka's proposal of migrating the class
loader core from Jackrabbit to Sling.
> bundles/jcr/contentloader
> Initial Content Loader, currently has dependency on Jackrabbit
> API for ACL stuff. For JCR 2.0 this will be converted into a
> pure JCR 2.0 dependency, hence be completely independent of
> Jackrabbit
> --> Keep it or offer to Jackrabbit ?
==> We keep it
> bundles/jcr/jackrabbit-accessmanager
> Access Control Management servlets leveraging Sling
> functionality.
> --> Keep it here
==> We keep it
> bundles/jcr/jackrabbit-usermanager
> User Manager for Jackrabbit (might be converted into a generic
> JCR 2.0 user manager ?) leveraging Sling functionality.
> --> Keep it here
==> We keep it
>
> bundles/jcr/jackrabbit-server
> Embedded Jackrabbit Repository providing Service API to plugin
> LoginModules as OSGi services.
> --> Offer to Jackrabbit
==> Offer to Jackrabbit, but decide on "how" -- the most important
question is to ensure our extensions and to even go a step further and
support Ian's requirement for fully flexible access control plugin (not
requiring to extend DefaultAccessManager)
> bundles/jcr/ocm
> OSGi bundle with Jackrabbit-OCM providing a Sling
> AdapterFactory for resources. Plugs heavily into Sling.
> --> Keep it here or offer to Jackrabbit ?
==> We keep it
> bundles/jcr/resource
> JCRResourceResolver
> --> We keep this ;-)
==> Well, of course, we keep it. This is part of our crown jewels ;-)
> bundles/jcr/webdav
> (Simple) WebDAV servlet(s)
> --> Offer to Jackrabbit
==> Offer to Jackrabbit
> contrib/jcr/compiler
> Compiles Java Classes into the Repository. This is part of
> Sling.
> --> Keep it here
==> We keep it
> contrib/jcr/jackrabbit-api
> Old OSGi bundle wrapping of Jackrabbit API. This is not used
> any longer, since Jackrabbit already provides OSGi bundles of
> some libraries, including the Jackrabbit API
> --> Deprecate and remove sometime in the future (move to "attic"?)
==> Removing
> contrib/jcr/jackrabbit-client
> Provides access to non-embedded repositories, mostly Jackrabbit
> oriented.
> --> Offer to Jackrabbit
== Offer to Jackrabbit
> contrib/jcr/prefs
> JCR bindings for the Apache Felix OSGi Preferences Service
> implementation.
> --> Keep it here
==> We keep it
I will follow up in separate threads with thoughts about what to offer
to Jackrabbit and how.
I have also prepared a Wiki page for these issues [1]
Regards
Felix
[1]
http://cwiki.apache.org/SLING/donating-jackrabbit-integration-to-apache-jackrabbit.html