You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Konrad Windszus <ko...@gmx.de> on 2021/04/21 07:59:26 UTC
Evolution of Jackrabbit API vs Oak API
Hi everyone,
I am wondering if it makes sense to still extend the Jackrabbit API given that Jackrabbit 2 is mostly in maintenance mode.
In the context of https://issues.apache.org/jira/browse/JCRVLT-515 I would need some API to get all(!) bound principals for one session (https://issues.apache.org/jira/browse/JCR-4689)
Neither JCR nor Jackrabbit API have a method for that, but OTOH Oak API has (https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/api/AuthInfo.html#getPrincipals--).
Unfortunately there is no easy way to get the Oak API entities from the JCR objects like Session (when running in Oak). This is often necessary as custom module running inside Sling or AEM use JCR entities exclusively (as access to the repository is managed by Sling).
Is there somewhere an overview what should be exposed by Jackrabbit API vs by Oak API?
To prevent extending the Jackrabbit API for all those edge cases I would recommend to rather introduce a simple way to convert a Oak-based JCR Session object into a Content Session (https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/api/ContentSession.html). That way one could easily use Oak API if Oak is used (without being forced to pass both Oak and JCR objects around).
WDYT?
Konrad
Re: Evolution of Jackrabbit API vs Oak API
Posted by Angela Schreiber <an...@adobe.com>.
hi konrad
if you look at the architectural big picture (http://jackrabbit.apache.org/oak/docs/architecture/overview.html) you will notice that there are 3 API layers in the design of Jackrabbit Oak
* JCR/Jackrabbit API
* Oak API
* NodeStore API
i think that explains Julian's and my reluctance mix 2 layers.
as far as extending Jackrabbit API is concerned: this wouldn't necessarily be needed. we could consider treating it as session attribute.... i haven't yet carefully thought about the security impact though.
kind regards
angela
________________________________
From: Konrad Windszus <ko...@gmx.de>
Sent: Wednesday, April 21, 2021 12:22 PM
To: dev@jackrabbit.apache.org <de...@jackrabbit.apache.org>
Subject: Re: Evolution of Jackrabbit API vs Oak API
I would appreciate some reasoning and also a clear differentiation between Oak and Jackrabbit API.
The one from Julian is not too convincing for me (yet):
- Jackrabbit API *extends* the JCR API; so it is for situations where
you access the repo using the JCR API, but need a few extensions
- Oak API should only be used if you're ok to depend on Oak as JCR
implementation. Not sure about what stability guarantees there are
> Well, the same stability as for Jackrabbit API I would say, there is semantic versioning in place AFAICS.
- Jackrabbit API is implemented by both classic Jackrabbit and Oak (it's
just that some features might not be available when using classic
Jackrabbit).
> Why should we extend Jackrabbit API for features only implemented by Oak (and not Jackrabbit 2)? Why not using Oak API for those use cases?
Thanks for your input,
Konrad
On 21. Apr 2021, at 12:15, Angela Schreiber <an...@adobe.com>> wrote:
hi konrad
i commented on the issue. in general i agree with julian that this looks bad and i am not in favor or that proposal.
kind regards
angela
________________________________
From: Konrad Windszus <ko...@gmx.de>>
Sent: Wednesday, April 21, 2021 11:55 AM
To: dev@jackrabbit.apache.org<ma...@jackrabbit.apache.org> <de...@jackrabbit.apache.org>>
Subject: Re: Evolution of Jackrabbit API vs Oak API
I created https://issues.apache.org/jira/browse/OAK-9416 to track this improvement and attached a PR.
Please have a look.
On 21. Apr 2021, at 11:29, Konrad Windszus <ko...@gmx.de>> wrote:
On 21. Apr 2021, at 11:19, Julian Reschke <ju...@gmx.de>> wrote:
Am 21.04.2021 um 10:47 schrieb Konrad Windszus:
What about providing a bridge from JCR to Oak API by adding the following method to org.apache.jackrabbit.oak.jcr.JCR:
@NotNull
public static org.apache.jackrabbit.oak.api.ContentSession toContentSession(javax.jcr.Session session)
that can return the underlying Oak API entity if the JCR session is backed by Oak, otherwise throws an ISE?
IMHO it doesn't make sense to duplicate methods exposed by Oak API already in Jackrabbit API...
Konrad
That would introduce a dependency on the Oak API; I don't think we would
want that.
The proposal is about extending the already exported JCR class in module "oak-jcr" (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java) which already has and needs a dependency on "oak-api" (https://github.com/apache/jackrabbit-oak/blob/77f243b8b810f7c611d1b1cd9b06abfc5e546446/oak-jcr/pom.xml#L224)
Best regards, Julian
Re: Evolution of Jackrabbit API vs Oak API
Posted by Konrad Windszus <ko...@gmx.de>.
I would appreciate some reasoning and also a clear differentiation between Oak and Jackrabbit API.
The one from Julian is not too convincing for me (yet):
- Jackrabbit API *extends* the JCR API; so it is for situations where
you access the repo using the JCR API, but need a few extensions
- Oak API should only be used if you're ok to depend on Oak as JCR
implementation. Not sure about what stability guarantees there are
> Well, the same stability as for Jackrabbit API I would say, there is semantic versioning in place AFAICS.
- Jackrabbit API is implemented by both classic Jackrabbit and Oak (it's
just that some features might not be available when using classic
Jackrabbit).
> Why should we extend Jackrabbit API for features only implemented by Oak (and not Jackrabbit 2)? Why not using Oak API for those use cases?
Thanks for your input,
Konrad
> On 21. Apr 2021, at 12:15, Angela Schreiber <an...@adobe.com> wrote:
>
> hi konrad
>
> i commented on the issue. in general i agree with julian that this looks bad and i am not in favor or that proposal.
>
> kind regards
> angela
>
>
> From: Konrad Windszus <ko...@gmx.de>
> Sent: Wednesday, April 21, 2021 11:55 AM
> To: dev@jackrabbit.apache.org <de...@jackrabbit.apache.org>
> Subject: Re: Evolution of Jackrabbit API vs Oak API
>
> I created https://issues.apache.org/jira/browse/OAK-9416 <https://issues.apache.org/jira/browse/OAK-9416> to track this improvement and attached a PR.
> Please have a look.
>
>> On 21. Apr 2021, at 11:29, Konrad Windszus <konrad_w@gmx.de <ma...@gmx.de>> wrote:
>>
>>
>>
>>> On 21. Apr 2021, at 11:19, Julian Reschke <julian.reschke@gmx.de <ma...@gmx.de>> wrote:
>>>
>>> Am 21.04.2021 um 10:47 schrieb Konrad Windszus:
>>>> What about providing a bridge from JCR to Oak API by adding the following method to org.apache.jackrabbit.oak.jcr.JCR:
>>>>
>>>> @NotNull
>>>> public static org.apache.jackrabbit.oak.api.ContentSession toContentSession(javax.jcr.Session session)
>>>>
>>>> that can return the underlying Oak API entity if the JCR session is backed by Oak, otherwise throws an ISE?
>>>>
>>>> IMHO it doesn't make sense to duplicate methods exposed by Oak API already in Jackrabbit API...
>>>>
>>>> Konrad
>>>
>>> That would introduce a dependency on the Oak API; I don't think we would
>>> want that.
>>>
>>
>> The proposal is about extending the already exported JCR class in module "oak-jcr" (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java <https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java>) which already has and needs a dependency on "oak-api" (https://github.com/apache/jackrabbit-oak/blob/77f243b8b810f7c611d1b1cd9b06abfc5e546446/oak-jcr/pom.xml#L224 <https://github.com/apache/jackrabbit-oak/blob/77f243b8b810f7c611d1b1cd9b06abfc5e546446/oak-jcr/pom.xml#L224>)
>>
>>> Best regards, Julian
Re: Evolution of Jackrabbit API vs Oak API
Posted by Angela Schreiber <an...@adobe.com>.
hi konrad
i commented on the issue. in general i agree with julian that this looks bad and i am not in favor or that proposal.
kind regards
angela
________________________________
From: Konrad Windszus <ko...@gmx.de>
Sent: Wednesday, April 21, 2021 11:55 AM
To: dev@jackrabbit.apache.org <de...@jackrabbit.apache.org>
Subject: Re: Evolution of Jackrabbit API vs Oak API
I created https://issues.apache.org/jira/browse/OAK-9416 to track this improvement and attached a PR.
Please have a look.
On 21. Apr 2021, at 11:29, Konrad Windszus <ko...@gmx.de>> wrote:
On 21. Apr 2021, at 11:19, Julian Reschke <ju...@gmx.de>> wrote:
Am 21.04.2021 um 10:47 schrieb Konrad Windszus:
What about providing a bridge from JCR to Oak API by adding the following method to org.apache.jackrabbit.oak.jcr.JCR:
@NotNull
public static org.apache.jackrabbit.oak.api.ContentSession toContentSession(javax.jcr.Session session)
that can return the underlying Oak API entity if the JCR session is backed by Oak, otherwise throws an ISE?
IMHO it doesn't make sense to duplicate methods exposed by Oak API already in Jackrabbit API...
Konrad
That would introduce a dependency on the Oak API; I don't think we would
want that.
The proposal is about extending the already exported JCR class in module "oak-jcr" (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java) which already has and needs a dependency on "oak-api" (https://github.com/apache/jackrabbit-oak/blob/77f243b8b810f7c611d1b1cd9b06abfc5e546446/oak-jcr/pom.xml#L224)
Best regards, Julian
Re: Evolution of Jackrabbit API vs Oak API
Posted by Konrad Windszus <ko...@gmx.de>.
I created https://issues.apache.org/jira/browse/OAK-9416 to track this improvement and attached a PR.
Please have a look.
> On 21. Apr 2021, at 11:29, Konrad Windszus <ko...@gmx.de> wrote:
>
>
>
>> On 21. Apr 2021, at 11:19, Julian Reschke <ju...@gmx.de> wrote:
>>
>> Am 21.04.2021 um 10:47 schrieb Konrad Windszus:
>>> What about providing a bridge from JCR to Oak API by adding the following method to org.apache.jackrabbit.oak.jcr.JCR:
>>>
>>> @NotNull
>>> public static org.apache.jackrabbit.oak.api.ContentSession toContentSession(javax.jcr.Session session)
>>>
>>> that can return the underlying Oak API entity if the JCR session is backed by Oak, otherwise throws an ISE?
>>>
>>> IMHO it doesn't make sense to duplicate methods exposed by Oak API already in Jackrabbit API...
>>>
>>> Konrad
>>
>> That would introduce a dependency on the Oak API; I don't think we would
>> want that.
>>
>
> The proposal is about extending the already exported JCR class in module "oak-jcr" (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java <https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java>) which already has and needs a dependency on "oak-api" (https://github.com/apache/jackrabbit-oak/blob/77f243b8b810f7c611d1b1cd9b06abfc5e546446/oak-jcr/pom.xml#L224 <https://github.com/apache/jackrabbit-oak/blob/77f243b8b810f7c611d1b1cd9b06abfc5e546446/oak-jcr/pom.xml#L224>)
>
>> Best regards, Julian
Re: Evolution of Jackrabbit API vs Oak API
Posted by Konrad Windszus <ko...@gmx.de>.
> On 21. Apr 2021, at 11:19, Julian Reschke <ju...@gmx.de> wrote:
>
> Am 21.04.2021 um 10:47 schrieb Konrad Windszus:
>> What about providing a bridge from JCR to Oak API by adding the following method to org.apache.jackrabbit.oak.jcr.JCR:
>>
>> @NotNull
>> public static org.apache.jackrabbit.oak.api.ContentSession toContentSession(javax.jcr.Session session)
>>
>> that can return the underlying Oak API entity if the JCR session is backed by Oak, otherwise throws an ISE?
>>
>> IMHO it doesn't make sense to duplicate methods exposed by Oak API already in Jackrabbit API...
>>
>> Konrad
>
> That would introduce a dependency on the Oak API; I don't think we would
> want that.
>
The proposal is about extending the already exported JCR class in module "oak-jcr" (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java) which already has and needs a dependency on "oak-api" (https://github.com/apache/jackrabbit-oak/blob/77f243b8b810f7c611d1b1cd9b06abfc5e546446/oak-jcr/pom.xml#L224)
> Best regards, Julian
Re: Evolution of Jackrabbit API vs Oak API
Posted by Julian Reschke <ju...@gmx.de>.
Am 21.04.2021 um 10:47 schrieb Konrad Windszus:
> What about providing a bridge from JCR to Oak API by adding the following method to org.apache.jackrabbit.oak.jcr.JCR:
>
> @NotNull
> public static org.apache.jackrabbit.oak.api.ContentSession toContentSession(javax.jcr.Session session)
>
> that can return the underlying Oak API entity if the JCR session is backed by Oak, otherwise throws an ISE?
>
> IMHO it doesn't make sense to duplicate methods exposed by Oak API already in Jackrabbit API...
>
> Konrad
That would introduce a dependency on the Oak API; I don't think we would
want that.
Best regards, Julian
Re: Evolution of Jackrabbit API vs Oak API
Posted by Konrad Windszus <ko...@gmx.de>.
What about providing a bridge from JCR to Oak API by adding the following method to org.apache.jackrabbit.oak.jcr.JCR:
@NotNull
public static org.apache.jackrabbit.oak.api.ContentSession toContentSession(javax.jcr.Session session)
that can return the underlying Oak API entity if the JCR session is backed by Oak, otherwise throws an ISE?
IMHO it doesn't make sense to duplicate methods exposed by Oak API already in Jackrabbit API...
Konrad
> On 21. Apr 2021, at 10:43, Julian Reschke <ju...@gmx.de> wrote:
>
> Am 21.04.2021 um 10:18 schrieb Konrad Windszus:
>> Thanks, that makes it even more blurry for me what is supposed to be exposed by Jackrabbit API vs by Oak API if Oak is now the only implementation of more recent Jackrabbit API versions...
>> ...
>
> AFAIU:
>
> - Jackrabbit API *extends* the JCR API; so it is for situations where
> you access the repo using the JCR API, but need a few extensions
>
> - Oak API should only be used if you're ok to depend on Oak as JCR
> implementation. Not sure about what stability guarantees there are
>
> - Jackrabbit API is implemented by both classic Jackrabbit and Oak (it's
> just that some features might not be available when using classic
> Jackrabbit).
>
> Best regards, Julian
Re: Evolution of Jackrabbit API vs Oak API
Posted by Julian Reschke <ju...@gmx.de>.
Am 21.04.2021 um 10:18 schrieb Konrad Windszus:
> Thanks, that makes it even more blurry for me what is supposed to be exposed by Jackrabbit API vs by Oak API if Oak is now the only implementation of more recent Jackrabbit API versions...
> ...
AFAIU:
- Jackrabbit API *extends* the JCR API; so it is for situations where
you access the repo using the JCR API, but need a few extensions
- Oak API should only be used if you're ok to depend on Oak as JCR
implementation. Not sure about what stability guarantees there are
- Jackrabbit API is implemented by both classic Jackrabbit and Oak (it's
just that some features might not be available when using classic
Jackrabbit).
Best regards, Julian
Re: Evolution of Jackrabbit API vs Oak API
Posted by Konrad Windszus <ko...@gmx.de>.
Thanks, that makes it even more blurry for me what is supposed to be exposed by Jackrabbit API vs by Oak API if Oak is now the only implementation of more recent Jackrabbit API versions...
> On 21. Apr 2021, at 10:16, Julian Reschke <ju...@gmx.de> wrote:
>
> Am 21.04.2021 um 09:59 schrieb Konrad Windszus:
>> Hi everyone,
>> I am wondering if it makes sense to still extend the Jackrabbit API given that Jackrabbit 2 is mostly in maintenance mode.
>
> jackrabbit-api nowadays is an Oak component (I have moved the Jira issue
> accordingly).
>
>> ...
>
> Best regards, Julian
Re: Evolution of Jackrabbit API vs Oak API
Posted by Julian Reschke <ju...@gmx.de>.
Am 21.04.2021 um 09:59 schrieb Konrad Windszus:
> Hi everyone,
> I am wondering if it makes sense to still extend the Jackrabbit API given that Jackrabbit 2 is mostly in maintenance mode.
jackrabbit-api nowadays is an Oak component (I have moved the Jira issue
accordingly).
> ...
Best regards, Julian