Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
JCR ContentLoader 2.4.2
-
None
-
None
-
None
Description
Currently starting the jcr.contentloader bundle and loading initial content bundles leads to the following warning (e.g. in Sling Starter 12-SNAPSHOT)
org.apache.jackrabbit.oak.jcr.lock.LockDeprecation Support for JCR Locking is deprecated and will be disabled in a future version of Jackrabbit Oak (see OAK-6421 for further information) - operation 'addMixin mix:lockable' called from: org.apache.sling.jcr.contentloader.internal.BundleContentLoaderListener.getBundleContentInfo(BundleContentLoaderListener.java:343) org.apache.sling.jcr.contentloader.internal.BundleContentLoader.registerBundleInternal(BundleContentLoader.java:155) org.apache.sling.jcr.contentloader.internal.BundleContentLoader.registerBundle(BundleContentLoader.java:122) org.apache.sling.jcr.contentloader.internal.BundleContentLoaderListener.loadBundle(BundleContentLoaderListener.java:266) org.apache.sling.jcr.contentloader.internal.BundleContentLoaderListener.activate(BundleContentLoaderListener.java:246)
Locking is currently used to make sure that in a clustered environment (i.e. multiple sling instances leveraging the same repository) initial-content is only processed once.
Depending on the bundle location one might process content initialisation only on the cluster leader.
For bundles which are only installed one one cluster instance (e.g. local installation) initial-content should always be performed (after checking the potentially existing bundle content info from the repo).
Attachments
Issue Links
- relates to
-
OAK-6421 Phase out JCR Locking support
- Open