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?
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.
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)
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. 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
