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 <[email protected]> Sent: Wednesday, April 21, 2021 12:22 PM To: [email protected] <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Sent: Wednesday, April 21, 2021 11:55 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: On 21. Apr 2021, at 11:19, Julian Reschke <[email protected]<mailto:[email protected]>> 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
