Jackrabbit 2.0 support for OSGi/Sling

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Jackrabbit 2.0 support for OSGi/Sling

Felix Meschberger-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Vidar Ramdal-2
On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <[hidden email]> 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 <[hidden email]> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Ian Boston
In reply to this post by Felix Meschberger-2

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


Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Bertrand Delacretaz
In reply to this post by Felix Meschberger-2
On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Carsten Ziegeler
In reply to this post by Felix Meschberger-2
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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Felix Meschberger-2
In reply to this post by Bertrand Delacretaz
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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Jukka Zitting
In reply to this post by Felix Meschberger-2
Hi,

On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Felix Meschberger-2
Hi Jukka,

Jukka Zitting schrieb:

> Hi,
>
> On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Ian Boston

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 <[hidden email]
>> > 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


Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Carsten Ziegeler
In reply to this post by Felix Meschberger-2
Felix Meschberger wrote:

> Hi Jukka,
>
> Jukka Zitting schrieb:
>> Hi,
>>
>> On Fri, Nov 27, 2009 at 2:47 PM, Felix Meschberger <[hidden email]> 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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Felix Meschberger-2
In reply to this post by Felix Meschberger-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Ian Boston

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

Reply | Threaded
Open this post in threaded view
|

Re: Jackrabbit 2.0 support for OSGi/Sling

Felix Meschberger-2
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