> On 15. Jun 2023, at 10:49, Julian Reschke <[email protected]> wrote:
>
> On 14.06.2023 09:48, Konrad Windszus wrote:
>> Hi,
>> Currently there is an implementation of
>> org.apache.jackrabbit.api.security.JackrabbitAccessControlEntry and
>> org.apache.jackrabbit.api.security.JackrabbitAccessControlList in
>> org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlEntry[1]/AccessControlList[2].
>> In case jcr2spi is deployed in an OSGi container this leads to a narrow
>> import-version ranges on the Jackrabbit API package
>> org.apache.jackrabbit.api.security which is a problem, because that package
>> gets a new major version quite frequently [4].
>
> "minor", not "major", right?
Right :-)
>
>> Is this supposed to be like this according to Jackrabbit SPI
>> architecture[3]? Is the Jackrabbit API really supposed to be implemented in
>> the “Client” part?
>
> JCR2SPI implements the JCR API, delegating to the SPI interfaces.
> Whether this happens in the client or in the server depends on where you
> use it.
“Client” and “Server” is the notion used in [3].
>
>> How can one then deploy a bundle which is compatible with a broad range of
>> Jackrabbit API which is embedding JCR2SPI (like FileVault RCP [5])?
>
> (Note the link in
> <https://github.com/apache/jackrabbit-filevault/blob/master/vault-rcp/readme.md>
> seems to be broken)
Thanks, just fixed it.
>
>> Is the Jackrabbit API then supposed to be embedded as well (and not reused
>> from the existing OSGi container)?
>
> Potentially.
>
> IIUC, the problem is partly caused by the fact that Oak has switched to
> Java 11 in January, and Jackrabbit hasn't made that switch yet; thus
> there is no Jackrabbit branch - in particular stable branch - that
> implement Jackrabbit API changes made since.
Actually I need a newer version of Jackrabbit API for the RCP bundle than what
is provided in the OSGi container, so not related.
>
> If this is the problem, or part of the problem, it would help to:
>
> - switch Jackrabbit trunk to Java 11, use the latest version of
> Jackrabbit API, and start making stable releases from that, or
>
> - backport these Jackrabbit API changes to Oak 1.22.*, so they would get
> visible in Jackrabbit JDK world.
>
>
> Best regards, Julian
For now I will just embed (the newer) Jackrabbit API in the RCP bundle, as that
seems to be the cleanest solution.
Thanks for the comments,
Konrad
