Re: [VOTE] Release Apache Jackrabbit Oak 1.22.16

[Marcel Reutegger]

On 14.07.23, 07:39, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.16.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.22.16

Regards
Marcel

Re: MongoDB 5/6 support

[Marcel Reutegger]

Hi Alexander

On 07.07.23, 11:12, "Alexander Lüders"  wrote:
> we are using JackrabbitOak 1.42 that officially supports MongoDB 4.4.x.
> Do you have MongoDB 5/6 support on your roadmap? Unfortunately we were
> not able to find this information by ourselves on the site below.

Automated builds currently do not run tests on MongoDB 5 and 6, but the
MongoDB Java Driver version used by Oak is compatible with these newer
versions. I expect it to work, but as mentioned, there are currently
no automated tests that verify this combination.

You can try it out e.g. by running MongoDB 5 with default port on the
same machine you are building Oak and report any issues you see.

> Additionally, it would be great to understand if this MongoDB support
> would be only implemented on the newer branches of Jackrabbit Oak that
> require Java 11.

Jackrabbit Oak 1.22.x use the same MongoDB Java Driver version as more
recent Oak versions. That is, MongoDB compatibility should be the same.
If there are any issues with Oak 1.22.x running on newer MongoDB versions
that we can certainly fix that.

Regards
Marcel

Re: Require OSGi R7

[Marcel Reutegger]

Hi Konrad

On 03.07.23, 13:27, "Konrad Windszus"  wrote:
> I would recommend to require at least OSGi R7 for Oak (released in 2018)
> and at the same time no longer use the aggregate dependency but rather
> the individual chapter dependencies of OSGi separately [3] which are
> (from Compendium)
> - Configuration Admin 1.6
> - Declarative Services 1.4
> - Metatype Service 1.4
>
> Does anything speak against raising the dependencies accordingly?

Does this require any code changes? I vaguely remember an earlier attempt
to update OSGi configuration related code throughout the project, which
required many changes and could introduced subtle changes in behaviour if
not done correctly.

> Is there any known consumer still relying on Oak in an OSGi container
> which is not at least R7 compliant?

Can you provide more details how this manifests? Thanks.

Regards
Marcel

Re: Moving to Oak 1.50 or newer

[Marcel Reutegger]

Hi Jorge,

On 16.05.23, 20:37, "Jorge Flórez"  wrote:
> we are planning to update our oak dependencies, from 1.12.0 to 1.50.0
> (or maybe 1.52.0). We are aware that we need to use Java 11 (already
> using it) and update our Mongo servers. It seems it will be to version 6
> (not my decision). If I have existing repositories created and filled
> using 1.12.0, should I do something additional to make them work with
> the latest version of Oak?

>From a DocumentNodeStore perspective, I'm not aware of anything you need
to do for the update. The MongoDB Java driver is compatible with MongoDB
6.0, but please note, our automated tests currently do not exercise this
combination. I suggest you properly test and report back if you identify
any issues on MongoDB 6.0.

Regards
Marcel

Updated short url for oak-mongo.js

[Marcel Reutegger]

Hi,

Today I noticed the short url for oak-mongo.js [0] was still pointing
to SVN [1]. I updated it to now redirect to git [2].

Regards
Marcel

[0] https://s.apache.org/oak-mongo.js
[1] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-run/src/main/js/oak-mongo.js
[2] 
https://raw.githubusercontent.com/apache/jackrabbit-oak/trunk/oak-run/src/main/js/oak-mongo.js

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.15

[Marcel Reutegger]

On 04.04.23, 08:48, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.15.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.22.15

Regards
Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.50.0

[Marcel Reutegger]

On 18.03.23, 10:50, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.50.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.50.0

Regards
Marcel

Re: Oak Jenkins build takes up too many resources

[Marcel Reutegger]

On 16.12.22, 20:01, "Konrad Windszus"  wrote:
> @Marcel: Are you still looking into optimizations?

No, I’m not.

Regards
Marcel

Re: Oak Jenkins build takes up too many resources

[Marcel Reutegger]

Hi,

On 11.11.22, 15:11, "Robert Munteanu"  wrote:
> I think it would be worthile to check if the build can be optimised

FYI, I also changed the Job configuration to not build PRs in draft state.

Regards
Marcel

Re: Oak Jenkins build takes up too many resources

[Marcel Reutegger]

On 14.11.22, 16:29, "Konrad Windszus"  wrote:
> Can you come up with a PR?
See https://github.com/apache/jackrabbit-oak/pull/755
Though, I don’t think the build it triggers actually uses the updated 
Jenkinsfile.
Regards
Marcel

Re: Oak Jenkins build takes up too many resources

[Marcel Reutegger]

Hi,

On 11.11.22, 15:11, "Robert Munteanu"  wrote:
> I think it would be worthile to check if the build can be optimised,
> otherwise Oak builds are blocking many execution slots of the Jenkins
> ASF instance.

I did notice one thing. Our PRs may schedule a build each time commits
are pushed to the branch. Is there a way to cancel an already running
build when there are new changes coming in from a PR?

Regards
Marcel

Re: Oak Jenkins build takes up too many resources

[Marcel Reutegger]

Hi Robert,

On 11.11.22, 15:11, "Robert Munteanu"  wrote:
> I was waiting for a small PR of mine in Sling to be built by Jenkins and
> I saw that it was not picked for some time. Looking at the executing
> jobs I noticed that there were many, different, Oak stages being ran.
>
> A sample PR check [1] shows that there are many stages (one per module?)
> but each of them takes at least 20 minutes, usually over 30.

Yes, each stage builds a module.

I think the durations on this page are misleading. Yes, there are some
modules that take more than 30 minutes, but most are pretty quick.
While the page says the second execution of oak-api stage took 33
minutes, the log files shows it must have run for less than a minute [0].

Maybe the duration includes wait time?

Regards
Marcel

[0] 
https://ci-builds.apache.org/blue/rest/organizations/jenkins/pipelines/Jackrabbit/pipelines/oak-trunk-pr/branches/snfe_during_recovery/runs/2/nodes/54/log/?start=0

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.13

[Marcel Reutegger]

On 13.10.22, 11:46, "Nitin Gupta"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.13.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.22.13

Regards
Marcel

Re: Removing a version does not remove associated labels

[Marcel Reutegger]

Hi Arun,

On 29.08.22, 09:05, "Arun Ram"  wrote:
> I have checked the classic jackrabbit . Here i dont see the problem.
> In classic jackrabbit InternalVersionHistoryImpl[1] removes the
> versionLabel before removing the version.
> Also regarding ReferentialIntegrityException of removeVersion , it is
> consistent with classic jackrabbit. It is thrown when you remove the
> current latest version.

Thanks for checking. Then I think Oak should also remove a potential
label automatically when a version is removed.

> I think changes related to remove the version label should be kept in
> ReadWriteVersionManager.java[2] since validation logic for version is
> present here.

The ReadWriteVersionManager you reference is in oak-jcr, but there is
also a corresponding class in oak-core, where the actual work is done.

I'd say the following method needs to be changed:

https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/version/ReadWriteVersionManager.java#L176

Regards
Marcel

Re: 180 open PRs on Github

[Marcel Reutegger]

Hi,

On 10.08.22, 12:30, "Stefan Seifert"  wrote:
> this sounds like a job that should be automated - e.g. using the stale
> github action.

+1

I’m also in favour of automating this task.

Some of the PRs just need a nudge, but many can probably be closed
because the issue is no longer that relevant.

Regards
Marcel

Re: Removing a version does not remove associated labels

[Marcel Reutegger]

Hi Arun,

On 25.08.22, 13:20, "Arun Ram"  wrote:
> We have encountered a behavior of versionStorage and versionLabels which I
> think is bug.
>
> *Current behavior:*
>
>1. Create a node and make it *versionable*
>2. Now create more than two versions (for example two version is  *1.0*
>and *1.1* respectively)
>3. Now add label at version 1.0 via *VersionHistory* Object (for example
>label is *Label_1.0*)
>4. Now remove the version 1.0 via calling *removeVersion(1.0)* method of
>*VersionHistory* object
>5. Now call method *hasVersionLabel(Label_1.0)  *of versionHistory . its
>now returning true.
>
> *Expected behaviour:*
>
> Call to the *hasVersionLabel(Label_1.0)*  of *versionHistory* should not
> return true because version associated with label does not exist. And
> removing the version should remove associated labels.

I agree, the current behaviour is rather unexpected and looks wrong to me.

> If we say that *hasVersionLabel(Label_1.0)*  of *versionHistory* returning
> true is expected behavior because label is not removed. Then call to the
> function getVersionByLabel(*Label_1.0) of versionHistory* will throw
> VersionException because version does not exist. So the repository goes
> into inconsistent state.

I think the repository should not get into a state where there is a
dangling version label. In my view the implementation of removeVersion()
must be changed.

> *Solution proposal:*
>
> One of the solution can be that whenever consumer of  versionHistory
> removes the version , he should be forced to remove the versionLabel first
> by throwing LabelExistException

I was trying to find the relevant section in the specification, but did
not find something useful. JavaDoc for VersionHistory.removeVersion()
gives a hint. The method signature does not mention LabelExistException,
but it says about ReferentialIntegrityException:

> "if the specified version is currently the target of a REFERENCE property
> elsewhere in the repository (not necessarily in this workspace) and the
> current Session has read access to that REFERENCE property."

This could also cover the version label, because it is in fact a
reference property. So, I think one option would be to throw a
ReferentialIntegrityException when there is a label on the version to
be removed.

> Another solution can be we should remove version label whenever user
> removes the version.

This also sounds reasonable. Did you check the behaviour of classic
Jackrabbit? I think it would be good to have consistent behaviour for
classic Jackrabbit and Oak.

Regards
Marcel

Re: Bulk load [migration] to oak using RDB Document node store

[Marcel Reutegger]

Hi Selvaraj,

On 27.07.22, 10:31, "Selvaraj chennappan"  wrote:
> We are migrating to Apache jackrabbit oak .
> RDB Document node store
> Postgres
>
> oak 1.42.0
> java 8
>
> issue : Loading is extremely slow (10x) when compared with Segment node
> store .
> Could you please suggest any improvement here on RDB Document node store

How frequently do you save changes? You may get better results when
saving in batches.

It is also not clear to me what the source is. If the source is also JCR
then you may try oak-upgrade
(https://jackrabbit.apache.org/oak/docs/migration.html), though I'm not
sure it will be faster in your case.

Regards
Marcel

Re: [ANNOUNCE] Apache Jackrabbit Oak 1.44.0 released

[Marcel Reutegger]

Hi,

On 22.07.22, 12:46, "Konrad Windszus"  wrote:
> I use this information to quickly check:
>
> - which is the latest release

To me the displayed version is just confusing. Currently
it says 1.43-SNAPSHOT. How do I know 1.44.0 is the latest
release? Beware, it's a trap! ;)

> - whether the documentation is probably outdated

I think the 'Last Published' data is much better suited
for this.

Anyway, I created the following issue. I'll be away
next week. Feel free to merge the PR or close when there
is consensus what to do with the version info.

https://issues.apache.org/jira/browse/OAK-9854

Regards
Marcel

Re: [ANNOUNCE] Apache Jackrabbit Oak 1.44.0 released

[Marcel Reutegger]

Hi,

On 22.07.22, 12:18, "Konrad Windszus"  wrote:
> The version Is part of the header contained in every page of the site,
> so IMHO a release (i.e. version change) requires a republish.

The version on those pages never matches the latest release. It's always
just the current SNAPSHOT version. In my view this information is useless
and I'd even suggest we remove it.

Regards
Marcel

Re: [ANNOUNCE] Apache Jackrabbit Oak 1.44.0 released

[Marcel Reutegger]

Hi Konrad,

On 21.07.22, 15:30, "Konrad Windszus"  wrote:
> Neither the website (https://jackrabbit.apache.org/oak/docs/index.html)
> nor the published javadoc
> (https://jackrabbit.apache.org/oak/docs/apidocs/) have been updated
> unfortunately.

I did not make any changes to Oak pages. So I didn't see a need to update
that part of the website.

The JavaDocs I forgot to generate and I'll do that right away.

> Do we need to make that more explicit in
> https://jackrabbit.apache.org/jcr/creating-releases.html#part-ii-after-
> the-release-vote?

Yes, might be good to amend point 9. It talks about Jackrabbit, which is
probably the reason why I skipped it. A pointer to oak-doc/README.md
would also be helpful.

Regards
Marcel

[ANNOUNCE] Apache Jackrabbit Oak 1.44.0 released

[Marcel Reutegger]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Oak 1.44.0. The release is available for download at:

 http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:

Release Notes -- Apache Jackrabbit Oak -- Version 1.44.0

Introduction


Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

Apache Jackrabbit Oak 1.44.0 is an incremental feature release based
on and compatible with earlier stable Jackrabbit Oak 1.x
releases. This release is considered stable and targeted for
production use.

While Oak 1.44.0 compiles and tests successfully on Java 17, Javadocs
generation fails on Java 17 (but works as expected on Java 8).

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

Changes in Oak 1.44.0
-

Technical task

[OAK-9585] - BrokenNetworkIT fails on Java 17
[OAK-9703] - benchmarks comparing new restrictions to rep:glob
[OAK-9833] - UpgradeIT fails on Java 17

Bug

[OAK-9564] - Lease failure when update takes longer than socket timeout
[OAK-9649] - Improve multithreaded download retry strategy during indexing
[OAK-9656] - Recovery runs mistakenly when system clock jumps ahead
[OAK-9676] - In CompositeNodeStore, mounts are ignored when
iterating through child nodes
[OAK-9684] - elastic: avoid ingesting FVs with size different from
the one in the index definition
[OAK-9695] - Deleting a property fails in case there is a residual
protected property definition in its node type with a non-matching
type
[OAK-9700] - RevisionGC may fail with NPE
[OAK-9708] - Invalid logging of 'improper' regex WARN
[OAK-9709] - PropertyDelegate.isProtected() throws NPE when parent is stale
[OAK-9729] - Reduce execution time for oak-search-elastic tests
[OAK-9732] - oak-it-osgi ITs broken on Windows
[OAK-9735] - Reset/update corrupt index counter in metrics
[OAK-9736] - oak-store-composite ITs broken
[OAK-9750] - Oak-search-elastic: Add right tika dependency
[OAK-9751] - Exception while reading external changes from journal
[OAK-9769] - PathPredicate not being used properly when building
FlatFileStore
[OAK-9773] - DefaultSyncContext#syncMembership() compares external
ids case-sensitively
[OAK-9775] - ACEs with unsupported restrictions must be cleared upon editing
[OAK-9779] - PermissionConstants.PERMISSION_PROPERTY_NAMES does
not list rep:isAllow
[OAK-9782] - CompositeRestrictionProvider must call validate on
aggregated providers
[OAK-9791] - Missing check for restriction node being present
[OAK-9793] - AbstractRestrictionProvider: validation to respect
aggregation for unsupported paths
[OAK-9797] - Direct access blob cache override breaks metrics and monitoring
[OAK-9798] - Inconsistent handling of supported permissions in
CompositePermissionProviderOr
[OAK-9809] - oak-run server: update Jetty because of outdated
servlet API version
[OAK-9813] - [oak-run-commons] LoggingInitializer shutdownLogging
should not shut down if not initialized
[OAK-9817] - Index stats logging indexing cycle failures after
changes from OAK-9802

Epic

[OAK-9538] - Oak should compile & test on Java 17
[OAK-9614] - Document best pratices for Oak Access Control
Management and Permission Evaluation

New Feature

[OAK-9680] - Container level SAS URI Support in Oak-Segment-Azure
[OAK-9689] - When BlobEndpoint is not configured use AccountName
in connection string for  Azure  blob store connector
[OAK-9704] - oak-blob-cloud-azure: in AzureBlobStoreBackend,
interpret empty string like null for boolean properties

Story

[OAK-9726] - Improve index purge old version commands logs
[OAK-9734] - Index purge should prevent fully delete index
definition which is is read-only repo

Improvement

[OAK-9612] - write to a readonly builder throws a
java.lang.UnsupportedOperationException
[OAK-9662] - Perform inequality matches in Lucene+Elastic, rather
than just in the query engine
[OAK-9663] - Configuration option for allowed system-principals in
ExternalPrincipalConfiguration
[OAK-9664] - Reduce Slow Query threshold
[OAK-9665] - Unparseable date property causes entire node to fail indexing
[OAK-9672] - Robust Json formatting
[OAK-9673] - JackrabbitAccessControlManagerDelegator should
implement privilegeCollectionFromNames
[OAK-9674] -
AbstractAccessControlManager.privilegeCollectionFromNames should
validate the passed privilege names
[OAK-9685] - Bump and align testcontainers dependency to v1.16.3
[OAK-9690] - Add support to bring elastic async index uptodate
post an OutofBand reindex operation
[OAK-9701] - Additional restrictions to simplify permission se

[RESULT] [VOTE] Release Apache Jackrabbit Oak 1.44.0

[Marcel Reutegger]

Hi,

The vote passes as follows:

+1 Marcel Reutegger
+1 Julian Reschke
+1 Woonsan Ko
+1 Angela Schreiber
+1 Nitin Gupta

Thanks for voting. I’ll push the release out.

Regards
Marcel

Re: Subject: [VOTE] Release Apache Jackrabbit Oak 1.22.12

[Marcel Reutegger]

On 15.07.22, 07:27, "Nitin Gupta"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.12.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.22.12

Regards
Marcel

Re: Jackrabbit Oak 1.44.0 release plan

[Marcel Reutegger]

Hi Konrad,

On 12.07.22, 18:44, "Konrad Windszus"  wrote:
> Although I appreciate a release, I see that this has been done already
> now. I would appreciate if you would give the Jackrabbit community a bit
> more in advance notice (maybe one week) to allow others to contribute
> fixes and also to consider at least the approved PR reviews

Fair point, I'll keep this in mind next time I create a release. Though,
I'm not sure about approved PRs. Most of these were approved even before
1.42.0. If there is real interest in these changes, then I'd argue there
was plenty of time getting them into trunk. In my view the burden shouldn't
be on the person creating the release to get those changes in, but rather
the individuals who created and approved the PRs.

> The amount of open PRs (172) also seems to indicate that the process for
> contributions does not work well. Maybe everyone of the Oak committers
> can dedicate some more time to do timely reviews…

I agree on the last part and I'm guilty of that as well. However, some
or even many of those PRs were simply abandoned and can be closed without
merging. This is work no one really wants to invest :-/ But it may indeed
be good to spend the time and clean up the clutter.

Regards
Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.44.0

[Marcel Reutegger]

On 12.07.22, 17:16, "Marcel Reutegger"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.44.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.44.0

Regards
Marcel

[VOTE] Release Apache Jackrabbit Oak 1.44.0

[Marcel Reutegger]

Hi,

A candidate for the Jackrabbit Oak 1.44.0 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.44.0/

The release candidate is a zip archive of the sources in:

 https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.44.0/

The SHA1 checksum of the archive is 9953efef17ffe2d09e963462b47a8b483603615f.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.44.0 9953efef17ffe2d09e963462b47a8b483603615f

Please vote on releasing this package as Apache Jackrabbit Oak 1.44.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.44.0
[ ] -1 Do not release this package because...

Regards
Marcel

Jackrabbit Oak 1.44.0 release plan

[Marcel Reutegger]

Hi,

It’s been more than 6 month since the last Oak feature release. I’d like to 
release 1.44.0 after blocking issues have been resolved.

Issues currently open for 1.44.0 are here:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20OAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.44.0

I consider the Java 17 related issues and OAK-9669 a blocker, but not the 
various improvements scheduled for 1.44.0.

Let me know if you have any objections.

Regards
Marcel

Re: FileVault support for version storage

[Marcel Reutegger]

Hi,

On 27.04.22, 11:17, "Timothée Maret"  wrote:
> 1. Add support for merging versions into a version history which is
> essentially OAK-1402

This is something different. VersionManager.merge() pulls in changes
from corresponding nodes in a different workspace through a shared
version history.

> 2. Extend System View importer to handle version history protected
> nodes. This would take the form of a o.a.j.o.s.x.ProtectedNodeImporter
> implementation targeting rep:versionStorage, nt:versionHistory,
> nt:version, and nt:frozenNode
> 3. Extend the VersionStorageEditor to support merging history nodes
> using the ReadWriteVersionManager

Agreed. I think that's the right approach.

Regards
Marcel

Re: OAK-9712: blob-cloud-azure instead of segment-azure?

[Marcel Reutegger]

Hi,

On 08.03.22, 15:55, "Matt Ryan"  wrote:
> - Open issues, questions, concerns, etc. in tickets and PRs must be
> addressed satisfactorily before code is committed.

I agree. To me it seems like changes for OAK-9712 were rushed in.
The PR also had failed checks for most of the modules, because
a license header was missing. I admit, a missing license header
is not a big deal. But it looks like for this PR the Jenkins test results
were simply ignored and impact could have been worse.

Regards
Marcel

New Jackrabbit Committer: José Andrés Cordero Benítez

[Marcel Reutegger]

Hi,

Please welcome José Andrés Cordero Benítez as a new committer and PMC
member of the Apache Jackrabbit project. The Jackrabbit PMC recently
decided to offer José committership based on his contributions. I'm
happy to announce that he accepted the offer and that all the related
administrative work has now been taken care of.

Welcome to the team, José!

Regards
 Marcel

Re: Javadocs

[Marcel Reutegger]

Hi,

On 31.01.22, 16:50, "Konrad Windszus"  wrote:
> Can we publish the most recent release again?

Apologies, I don't know why that happened. It looks like I was
updating the website in November 2021 with some minor corrections
and this also wiped Javadoc.

I re-generated the site with Javadoc and they are back online.

Regards
 Marcel

Re: [jackrabbit-oak] branch upstream-trunk updated: [maven-release-plugin] prepare for next development iteration

[Marcel Reutegger]

Hi,

On 10.01.22, 09:23, "Marcel Reutegger"  wrote:
> Something went wrong at this step of the release. The following commit
> updated the project version to 1.43-SNAPSHOT on branch 'upstream-trunk'
> instead of 'trunk'.
> 
> Trunk is still on 1.41-SNAPSHOT.

Created https://github.com/apache/jackrabbit-oak/pull/456 to update version
to 1.43-SNAPSHOT in trunk.

Regards
 Marcel

Re: [jackrabbit-oak] branch upstream-trunk updated: [maven-release-plugin] prepare for next development iteration

[Marcel Reutegger]

Hi Miro,

Something went wrong at this step of the release. The following commit
updated the project version to 1.43-SNAPSHOT on branch 'upstream-trunk'
instead of 'trunk'.

Trunk is still on 1.41-SNAPSHOT.

Regards
 Marcel

On 06.01.22, 13:00, "miros...@apache.org"  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
> 
> miroslav pushed a commit to branch upstream-trunk
> in repository https://gitbox.apache.org/repos/asf/jackrabbit-oak.git
> 
> 
> The following commit(s) were added to refs/heads/upstream-trunk by this push:
> new 70f9e05  [maven-release-plugin] prepare for next development iteration
> 70f9e05 is described below
> 
> commit 70f9e0585b2eef7ddd762eb1b3f311fa95a50177
> Author: smiroslav 
> AuthorDate: Thu Jan 6 13:00:29 2022 +0100
> [...]

Re: [VOTE] Release Apache Jackrabbit Oak 1.42.0

[Marcel Reutegger]

On 07.01.22, 13:04, "Miroslav Smiljanic"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.42.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.42.0

Regards
 Marcel

Re: garbage collection with azure blob store

[Marcel Reutegger]

Hi,

Those lists are indeed a bit confusing. I added AzureDataStore below
the DocumentNodeStore.

Regards
 Marcel

On 19.11.21, 10:55, "Marco Piovesana"  wrote:
> in the blob store page
>  under
> the section "Blob Garbage Collection" is written that blob GC is
> applicable for a list of blob stores. The document node store does not
> contain the Azure data store in its list, while the segment node store
> does. Did I misunderstood the meaning of that section?

Re: garbage collection with azure blob store

[Marcel Reutegger]

Hi,

On 18.11.21, 11:18, "Marco Piovesana"  wrote:
> the documentation states that the blob garbage collection is not
> applicable when using a document node store with an azure blob store,
> while it is applicable when using a segment node store with an azure
> blob store. So what happens to the deleted binaries with the
> document+azure configuration? Are they never deleted?

This sounds like mistake in the documentation. Where did you read this?

Blob garbage collection is always needed, independent of the node store
implementation in use. The only exception might be when all blobs are
inlined in the node store, but that's a rather unusual case.

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.22

[Marcel Reutegger]

On 15.11.21, 14:44, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.6.22.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.6.22

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

[Marcel Reutegger]

Hi,

On 16.07.21, 11:20, "Marcel Reutegger"  wrote:
> You can always fall back to Jukka's release auditing guidelines

Or better yet, the authoritative source [0].

Regards
 Marcel

[0] https://www.apache.org/legal/release-policy.html#release-approval

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

[Marcel Reutegger]

Hi,

On 15.07.21, 18:35, "Angela Schreiber"  wrote:
> IMHO we should not vote on a release if everyone is requied to manually
> alter the check-release.sh in order to verify that the checks are ok.

It's unfortunate that GitHub's SVN export is unreliable and the release
check script may fail. But this release vote is not about how convenient
it is to check the release.

I consider Oak 1.22.8 OK and voted accordingly.

You can always fall back to Jukka's release auditing guidelines [0].

Regards
 Marcel

[0] 
http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200701.mbox/%3c510143ac0701211520j5ee319e2hadea0f58259c8...@mail.gmail.com%3E

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

[Marcel Reutegger]

On 15.07.21, 12:05, "Andrei Dulceanu"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.8.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

Checks OK after I did some manual changes to the check-release.sh as
suggested in https://issues.apache.org/jira/browse/JCR-4706

+1 Release this package as Apache Jackrabbit Oak 1.22.8

Regards
 Marcel

Re: [RESULT] [VOTE] Migrate to Git

[Marcel Reutegger]

Hi Konrad,

This is great news. Thanks a lot for volunteering and driving
this forward.

Regards
 Marcel

On 23.06.21, 12:46, "Konrad Windszus"  wrote:
> The repository has been successfully migrated and the patches and PR
> were applied. Now the documentation should be up2date. For details refer
> to https://issues.apache.org/jira/browse/OAK-9440.
> 
> Please consider
> https://jackrabbit.apache.org/oak/docs/developing-with-git.html if you
> never worked with ASF/GitHub before.

Re: [RESULT] [VOTE] Migrate to Git

[Marcel Reutegger]

Hi Konrad

On 18.06.21, 11:01, "Konrad Windszus"  wrote:
> I haven't received any feedback on the patches or the PR, I therefore
> defer migration for one week. Please have a look at
> https://issues.apache.org/jira/browse/OAK-9440 and the attached patches
> and PR

Thanks for preparing those changes. They look good to me.

Regards
 Marcel

Re: User Feedback

[Marcel Reutegger]

Hi Aaron,

On 12.06.21, 18:54, "Aaron Anderson"  wrote:
> After completing my development there are a few very minor enhancements
> for the Elasticsearch plugin that I would like to contribute to the
> project. Should I create an issue first or may I directly create a
> Github pull request?

It's best you do both and mention the PR in the OAK issue.

> 1. What is the purpose of the whiteboard and can it be used for all Oak
> configuration?

No, it can't. The 'features' supported via the whiteboard are limited.
IIRC the main purpose is to act as a facade and allows for easier
integration with an OSGi container. As you might have seen, there are
different implementations. Some configuration is done via the whiteboard,
but other is more static and done with the Oak and Jcr builder classes.

> When I was setting up the Elasticsearch IndexProvider and
> IndexEditorProvider implementations I configured them directly on the
> Oak builder. Is it possible to register those implementation on the
> whiteboard instead?

I'm not an expert in this area, but I don't think this is possible.

> 2. Is there any way to convert/cast between a JCR Repository and an Oak
> ContentRepository or are they mutually exclusive and must be maintained
> separately?

No, this is not possible. There was a recent request to provide this
ability, but the Oak team decided not to implement it. For more details
see https://issues.apache.org/jira/browse/OAK-9416

> 3. Does the AWS NodeSegment support concurrent access? It uses a Dynamo
> DB lock table so I presume it does but I couldn't find a confirmation in
> the documentation and the only clustering documentation I could locate
> was the Lucene and MongoDB configuration. 

All segment based NodeStore implementations only support access through
a single Oak process.

But there are some prototypes that aim to achieve what you ask for:
- https://issues.apache.org/jira/browse/OAK-8613
- https://issues.apache.org/jira/browse/OAK-7932

Regards
 Marcel

Re: Patch: Small documentation imrovements

[Marcel Reutegger]

Hi Aravindo,

can you please create an OAK issue for component ‘doc’ and attach the
patch there? Alternatively, you can also reference a GitHub PR in the
issue. Thanks!

Regards
 Marcel

On 11.06.21, 20:48, "Aravindo Wingeier"  wrote:
> I did small improvements to the segments documentation, adding commas
> and fixing the ascii graph. Please merge the attached patch.

Re: [VOTE] Migrate to Git

[Marcel Reutegger]

Hi Konrad,

On 19.05.21, 09:24, "Konrad Windszus"  wrote:
> I hereby propose to
> 
> 1. migrate the SVN repository at
> https://svn.apache.org/repos/asf/jackrabbit/oak/ to a Git repository
> named "jackrabbit-oak"
> 2. migrate GitHub SVN mirror at https://github.com/apache/jackrabbit-oak
> to mirror the new native Git repo (at Gitbox)
> 3. change the main branch name from "trunk" to "main"
> 4. make the SVN repository read only

+1, I'm in favour of this proposal.

However, I don't see a strong reason to change the main branch.

I'm aware of a few 3rd party build jobs that currently depend on SVN and
will need some update with this switch to GitHub. Can we agree on a schedule
when the migration is done? This would give me and probably others a bit of
time to prepare those changes and prevent interruptions in external build
processes.

Regards
 Marcel

[ANNOUNCE] Apache Jackrabbit Oak 1.22.7 released

[Marcel Reutegger]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Oak 1.22.7. The release is available for download at:

 http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:



Release Notes -- Apache Jackrabbit Oak -- Version 1.22.7

Introduction


Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

Jackrabbit Oak 1.22.7 is a patch release that contains fixes and
improvements over Oak 1.22. Jackrabbit Oak 1.22.x releases are
considered stable and targeted for production use.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.


Changes in Oak 1.22.7
-

Bug

[OAK-8582] - Failing test in MongoDB 4.2.0:
BasicDocumentStoreTest.testLongId
[OAK-9176] - sweep upgrade of pre 1.8 branch commits not always
sets "_bc" for parents/root
[OAK-9306] - Faceting: IllegalArgumentException: dimension ... was
not indexed
[OAK-9358] - DocumentNodeStore may accumulate split candidates

Improvement

[OAK-9134] - Remove mix:referenceable from nt:frozenNode definition
[OAK-9290] - Respect nt:frozenNode definition on upgrade and migration
[OAK-9291] - Refactor check for referenceable nt:frozenNode definition
[OAK-9352] - move SystemPropertySupplier from document to commons
[OAK-9357] - Update to MongoDB Java driver 3.12
[OAK-9359] - Use SystemPropertySupplier to ease backport

This release contains a fix for OAK-9176, which performs a one time repository
scan to fix missing _bc (branch commit) entries. This only affects repositories
running on DocumentNodeStore (MongoDB and RDB). Use the system property
-Doak.documentMK.disableSweep2=true to disable this scan in case it should be
skipped explicitly.

In addition to the above-mentioned changes, this release contains
all changes included up to the previous Apache Jackrabbit Oak 1.22.x release.

For more detailed information about all the changes in this and other
Oak releases, please see the Oak issue tracker at

  https://issues.apache.org/jira/browse/OAK

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.md file for instructions on how to build this release.

The source archive is accompanied by a SHA512 checksums and a PGP
signature that you can use to verify the authenticity of your
download. The public key used for the PGP signature can be found at
https://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit Oak
---

Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

For more information, visit http://jackrabbit.apache.org/oak

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

[RESULT] [VOTE] Release Apache Jackrabbit Oak 1.22.7

[Marcel Reutegger]

Hi,

The vote passes as follows.

+1 Marcel Reutegger
+1 Miroslav Smiljanic
+1 Angela Schreiber
+1 Julian Reschke
+1 Woonsan Ko

Thanks for voting. I'll push the release out.

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.7

[Marcel Reutegger]

On 09.04.21, 12:49, "Marcel Reutegger"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.7.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.22.7

Regards
 Marcel

[VOTE] Release Apache Jackrabbit Oak 1.22.7

[Marcel Reutegger]

Hi,

A candidate for the Jackrabbit Oak 1.22.7 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.7/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.22.7/

The SHA1 checksum of the archive is 4a8b7752abbe0d5bb7b58791cf620ec810d9b5ff.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.22.7 4a8b7752abbe0d5bb7b58791cf620ec810d9b5ff

Please vote on releasing this package as Apache Jackrabbit Oak 1.22.7.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.22.7
[ ] -1 Do not release this package because...

Regards
 Marcel

Jackrabbit Oak 1.22.7 release plan

[Marcel Reutegger]

Hi,

I'm planning to cut Jackrabbit Oak 1.22.7 tomorrow.

The list of open issues scheduled for 1.22.7 is empty.

https://issues.apache.org/jira/issues/?jql=project%20%3D%20OAK%20AND%20fixVersion%20%3D%201.22.7%20AND%20resolution%20%3D%20Unresolved

The candidate release notes are here:

https://svn.apache.org/repos/asf/jackrabbit/oak/branches/1.22/RELEASE-NOTES.txt

Let me know if there are any objections.

Regards
Marcel

Re: Sending NODE_ADDED Events for Dynamic Resources / Nodes

[Marcel Reutegger]

Hi Andy,

Oak does not allow an application to generate such events.
These events are the result of modifications on content stored
in the repository. An EventListener on the repository will
only get a NODE_ADDED event when a node has been added to the
repository that matches the filter definition of the listener.

Regards
 Marcel


On 13.03.21, 00:13, "Andreas Schaefer"  wrote:

Hi

I am working on Sling and want to send an Event.NODE_ADDED event to inform 
others that there is a Dynamic Resource / Node available.

I could not figure out how to do that in Sling or Oak and was wondering if that 
is possible and how I would send out such an Event?

Cheers - Andy

Re: Mongo DB name max length

[Marcel Reutegger]

Hi,

On 03.02.21, 18:17, "jorgeeflorez"  wrote:
> My question is: is there another way to "create" the database having 64
> characters? or should I establish 63 (or maybe less) as the limit for db
> names?

You could try creating the database before starting Oak. Otherwise it may
also be a flaw in the driver and worth a JIRA ticket with MongoDB.

https://jira.mongodb.org/browse/JAVA

Regards
 Marcel

[ANNOUNCE] Apache Jackrabbit Oak 1.22.6 released

[Marcel Reutegger]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Oak 1.22.6. The release is available for download at:

 http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:



Release Notes -- Apache Jackrabbit Oak -- Version 1.22.6

Introduction


Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

Jackrabbit Oak 1.22.6 is a patch release that contains fixes and
improvements over Oak 1.22. Jackrabbit Oak 1.22.x releases are
considered stable and targeted for production use.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

Changes in Oak 1.22.6
-

Bug

[OAK-9130] - DocumentDiscoveryLiteService.hasBacklog logging
regression (inverted version check)
[OAK-9304] - Filename with special characters in direct download
URI Content-Disposition are causing HTTP 400 errors from Azure

Improvement

[OAK-9261] - Upgrade Apache Solr to 8.6.3 and remove Embedded Solr Server

Task

[OAK-8769] - oak-auth-ldap pom needs maintenance
[OAK-9034] - update commons-lang3 to 3.10
[OAK-9270] - Update Oak trunk and 1.22 to Jackrabbit 2.20.2
[OAK-9299] - Update Tika dependency to 1.24.1 (backport)

Technical task

[OAK-9007] - RDB*Store: update postgresql jdbc driver reference to 42.2.12


In addition to the above-mentioned changes, this release contains
all changes included up to the previous Apache Jackrabbit Oak 1.22.x release.

For more detailed information about all the changes in this and other
Oak releases, please see the Oak issue tracker at

  https://issues.apache.org/jira/browse/OAK

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.md file for instructions on how to build this release.

The source archive is accompanied by a SHA512 checksums and a PGP
signature that you can use to verify the authenticity of your
download. The public key used for the PGP signature can be found at
https://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit Oak
---

Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

For more information, visit http://jackrabbit.apache.org/oak

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

[RESULT][VOTE] Release Apache Jackrabbit Oak 1.22.6

[Marcel Reutegger]

Hi,

The vote passes as follows.

+1 Marcel Reutegger
+1 Julian Reschke
+1 Miroslav Smiljanic
+1 Woonsan Ko
+1 Matt Ryan

Thanks for voting. I'll push the release out.

Regards
 Marcel

Jackrabbit Oak 1.22.6 release plan

[Marcel Reutegger]

Hi,

I'm planning to cut Jackrabbit Oak 1.22.6 tomorrow.

The list of open issues scheduled for 1.22.6 is empty.

https://issues.apache.org/jira/issues/?jql=project%20%3D%20OAK%20AND%20fixVersion%20%3D%201.22.6%20AND%20resolution%20%3D%20Unresolved

The candidate release notes are here:

https://svn.apache.org/repos/asf/jackrabbit/oak/branches/1.22/RELEASE-NOTES.txt

Let me know if there are any objections.

Regards
 Marcel

Re: Having Problems to startup standalone with mongo

[Marcel Reutegger]

Hi Ratna,

it appears you need to add authentication to the MongoDB URI. In the log file
you attached, reading from MongoDB fails with:

2020-09-25 23:10:01.079 ERROR 126802 --- [   main] 
o.apache.jackrabbit.oak-store-document   : 
[org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService(45)] The 
bindBlobStore method has thrown an exception (com.mongodb.MongoQueryException: 
Query failed with error code 13 and error message 'command find requires 
authentication' on server localhost:27017)

com.mongodb.MongoQueryException: Query failed with error code 13 and error 
message 'command find requires authentication' on server localhost:27017

Regards
 Marcel

On 26.09.20, 17:23, "Ratna K"  wrote:

Hi,

I want to try out / learn jcr-oak. So I started with standalone in 
ocr-examples. I am trying to start by following instructions in readme. Please 
find below stacktrace for the error message I am getting:

Caused by: javax.jcr.RepositoryException: Repository could not be started in 10 
seconds
at 
org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory.getRepository(OakOSGiRepositoryFactory.java:213)
at 
org.apache.jackrabbit.oak.standalone.RepositoryInitializer.createRepository(RepositoryInitializer.java:132)
at 
org.apache.jackrabbit.oak.standalone.RepositoryInitializer.initRepository(RepositoryInitializer.java:111)
at 
org.apache.jackrabbit.oak.standalone.RepositoryInitializer.initialize(RepositoryInitializer.java:83)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:366)
at 
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:311)
at 
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:134)
... 83 common frames omitted
Caused by: java.util.concurrent.TimeoutException: Timeout waiting for task.
at 
com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:269)
at 
com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:96)
at 
org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory.getRepository(OakOSGiRepositoryFactory.java:195)
... 93 common frames omitted


Also please find attachment for full logs. I am running below command to start 
the standalone app:
java -jar target/oak-standalone-1.35-SNAPSHOT-exec.jar 
--mongo=mongodb://localhost:27017

My mongo db is up and running and I am sure there is a db called oak in mongodb 
instance.

Help in this would really be appreciated.


Regards
Ratna

Intent to backport OAK-9230 and OAK-9231

[Marcel Reutegger]

Hi,

I'd like to backport OAK-9230 and OAK-9231 to maintenance branches
1.22 and 1.8. This is an improvement disabled by default in
oak-store-document and used by oak-run index selectively for reading
nodes. Depending on the data in the DocumentStore, the speed up of
the read operation can be rather significant and reduce the time to
create an index accordingly.

The risk is limited to the oak-run index command on a DocumentNodeStore.

Regards
 Marcel

Intent to backport OAK-9229

[Marcel Reutegger]

Hi,

I'd like to backport OAK-9229 to maintenance branches 1.22 and 1.8.
The changes are test only. See details in the issue description.

I consider this low risk because no production code is touched.
Let me know if you have any concerns.

Regards
 Marcel

Intent to backport OAK-7553

[Marcel Reutegger]

Hi,

I'd like to backport changes for OAK-7553 to the 1.8
branch. The CommitValueResolver was introduced with 1.8
but slightly refactored with OAK-7553. This currently
makes it more difficult to maintain the 1.8 branch.

I consider the backport low risk because there is no
functional change, just refactoring.

Regards
 Marcel

Re: Getting commit 'origin' in a CommitHook/Editor

[Marcel Reutegger]

Hi Robert,

On 10.09.20, 19:01, "Robert Munteanu"  wrote:
> I am trying to get commit origin information in an Editor ( well,
> Validator actually ). The scenario is that I want to log writes to paths
> that should belong to the immutable mount (/libs, /apps) in a composite
> setup when preparing. The intercept is done simply to analyse who writes
> to /libs and /apps and report unexpected writes.
> 
> What I am doing right now is create a ValidatorProvider and record all
> the childNodeXXX operations. In the 'leave' method of the root validator
> I am doing the logging and walking up the current thread's stack trace
> to eliminate 'permitted' callers, like repoinit and the FileVault
> package installer.
> 
> Is this approach sound at a high-level? Is there a better way of getting
> the commit 'origin'?

It depends how you define 'origin'. Alternatively, if 'origin' is more about
_who_ writes, then your validator could use CommitInfo passed to
ValidatorProvider.getRootValidator(). E.g. the CommitInfo contains the
userId of the session that performs the write operation.

But I guess you are more interested in the code that invokes the write
operation.

Regards
 Marcel

[ANNOUNCE] Apache Jackrabbit Oak 1.34.0 released

[Marcel Reutegger]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Oak 1.34.0. The release is available for download at:

 http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:


Release Notes -- Apache Jackrabbit Oak -- Version 1.34.0

Introduction


Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

Apache Jackrabbit Oak 1.34.0 is an incremental feature release based
on and compatible with earlier stable Jackrabbit Oak 1.x
releases. This release is considered stable and targeted for
production use.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

Changes in Oak 1.34.0
-

Bug

[OAK-9130] - DocumentDiscoveryLiteService.hasBacklog logging
regression (inverted version check)
[OAK-9146] - Elastic indexes - Updates get lost if connection is
not available
[OAK-9162] - Elastic indexes - Index creation fails if multiple
suggest fields are present
[OAK-9163] - ElasticIndexTracker should never use stored index definitions
[OAK-9166] - Elastic indexes - Fulltext query requires more rules
than expected
[OAK-9178] - PasswordHistory.updatePasswordHistory may return false status

New Feature

[OAK-7744] - Persistent cache for the Segment Node Store
[OAK-9131] - oak-run tool for scanning for references to nt:frozenNode

Improvement

[OAK-9106] - Support spellchecking in Oak ES
[OAK-9134] - Remove mix:referenceable from nt:frozenNode definition
[OAK-9136] - Allow elasticsearch port to be read from secrets
[OAK-9139] - Log message on frozen node lookup by identifier
[OAK-9142] - AzureDataStore should use concurrent request count
for all API calls
[OAK-9144] - Indexing: dynamic boost is not robust
[OAK-9147] - Config option for NRT queue timeout
[OAK-9151] - Support term suggestion in Oak ES
[OAK-9156] - Port lucene tests
[OAK-9165] - Lucene: unique sync property index don't work properly
[OAK-9170] - Make loading segment disk cache fail safe in case
when write operation is interrupted by failure
[OAK-9173] - Oak-run indexing fails with "This map is closed"
[OAK-9180] - Optimise synchronisation between threads when writing
to 3rd level segment cache
[OAK-9184] - Very slow, potential endless loop in
LucenePropertyIndex.loadDocs()
[OAK-9194] - oak-search-elastic: propertyIndex with nodeScopeIndex
should be stored in :fulltext only

Task

[OAK-9138] - Have a mechanism to track failed docs in ES
[OAK-9140] - Don't use stored index definition in elastic indexes
[OAK-9143] - Use seed instead of reindexCount for elastic index suffix
[OAK-9148] - Use IndexTracker in oak-search-elastic
[OAK-9152] - Implement factor 2 writes
[OAK-9164] - oak-search-elastic: expose relevant metrics
[OAK-9167] - Expose last indexed time as a metric
[OAK-9169] - Remove remote elastic indexes when index definition is removed
[OAK-9179] - Documentation (and comments) about rep:glob patterns
in ACE restriction is confusing
[OAK-9188] - Upgrade to Elasticsearch 7.9.0

Technical task

[OAK-9070] - Remove unnecessary (un)boxing in
oak-authorization-principalbased
[OAK-9186] - Create Benchmark(s)
[OAK-9189] - Benchmark Results - Status Quo


In addition to the above-mentioned changes, this release contains all
changes up to the previous release.

For more detailed information about all the changes in this and other
Oak releases, please see the Oak issue tracker at

  https://issues.apache.org/jira/browse/OAK

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.md file for instructions on how to build this release.

The source archive is accompanied by SHA512 checksums and a
PGP signature that you can use to verify the authenticity of your
download. The public key used for the PGP signature can be found at
https://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit Oak
---

Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

For more information, visit http://jackrabbit.apache.org/oak

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apac

[RESULT] [VOTE] Release Apache Jackrabbit Oak 1.34.0

[Marcel Reutegger]

Hi,

The vote passes as follows.

+1 Julian Reschke
+1 Woonsan Ko
+1 Matt Ryan

Thanks for voting. I'll push the release out.

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.34.0

[Marcel Reutegger]

Hi Julian,

On 08.09.20, 08:05, "Julian Reschke"  wrote:
> ..., I now need relax the Windows firewall config, otherwise the Redis
> server used in tests does not start. It would be good if we could avoid
> that.

Can you please create a JIRA issue for this?

Regards
 Marcel

[VOTE] Release Apache Jackrabbit Oak 1.34.0

[Marcel Reutegger]

Hi,

A candidate for the Jackrabbit Oak 1.34.0 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.34.0/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.34.0/

The SHA1 checksum of the archive is dbc1f492f052377f909d4715a8c604c32f019d38.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.34.0 dbc1f492f052377f909d4715a8c604c32f019d38

Please vote on releasing this package as Apache Jackrabbit Oak 1.34.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.34.0
[ ] -1 Do not release this package because...

Regards
 Marcel

Jackrabbit Oak 1.34.0 release plan

[Marcel Reutegger]

 Hi,

I'm planning to cut Jackrabbit Oak 1.34.0 on Monday.

The list of open issues scheduled for 1.34.0 is empty. I moved
all issues scheduled for 1.34.0 and not in progress to 1.36.0.

https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%201.34.0%20AND%20project%20%3D%20OAK%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

The candidate release notes are here:

https://svn.apache.org/repos/asf/jackrabbit/oak/trunk/RELEASE-NOTES.txt

If there are any objections please let me know.

Regards
Marcel

[ANNOUNCE] Apache Jackrabbit Oak 1.32.0 released

[Marcel Reutegger]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Oak 1.32.0. The release is available for download at:

 http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:



Release Notes -- Apache Jackrabbit Oak -- Version 1.32.0

Introduction


Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

Apache Jackrabbit Oak 1.32.0 is an incremental feature release based
on and compatible with earlier stable Jackrabbit Oak 1.x
releases. This release is considered stable and targeted for
production use.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

Changes in Oak 1.32.0
-

Bug

[OAK-9064] - Build failure: The forked VM terminated without
properly saying goodbye
[OAK-9086] - Flaky test
SegmentWriteQueueTest#testThreadInterruptedWhileAddigToQueue
[OAK-9089] - oak-search-elastic: remove remote index in eleastic
benchmarks cleanup
[OAK-9095] - MapRecord corruption when adding more than
MapRecord.MAX_SIZE entries in branch record
[OAK-9096] - RDBDocumentStore: Update error code for MSSQL 2019
[OAK-9102] - AwsJournalFileConcurrencyIT writes log messages to stdout

New Feature

[OAK-9127] - Introduce Similarity Search (Text) support in
oak-search-elastic
[OAK-9132] - Feature toggles

Improvement

[OAK-9087] - oak-search-elastic: class / package names refactoring
[OAK-9092] - Exception root cause message is swallowed
[OAK-9093] - Reindexing using --doc-traversal-mode may log too much
[OAK-9099] - Improve segment write resiliency for remote segment store
[OAK-9108] - Change default timeout to mark indexes corrupt
[OAK-9113] - Make the segment migrator more resilient to timeouts
[OAK-9121] - Oak-run indexing: add a cache to flatfile/PersistedLinkedList
[OAK-9122] - Bring IndexDefinitionBuilder's implementation in
oak-search at par with the one in oak-lucene and remove the oak-lucene
implementation
[OAK-9126] - TestFramework: create tests for both lucene and elastic
[OAK-9128] - Support s3 regions apart from default AWS regions

Task

[OAK-9090] - Upgrade to Elasticsearch 7.7.0
[OAK-9097] - Add Facet tests to oak-benchmarks
[OAK-9098] - Write a perf test class in oak-search elastic module
[OAK-9101] - Monitoring for maximum number of entries in biggest map record
[OAK-9105] - Update Oak trunk and 1.22 to Jackrabbit 2.20.1

Technical task

[OAK-9069] - Remove unnecessary (un)boxing in oak-auth-external
[OAK-9071] - Remove unnecessary (un)boxing in oak-benchmarks
[OAK-9074] - Remove unnecessary (un)boxing in oak-core
[OAK-9075] - Remove unnecessary (un)boxing in oak-exercise
[OAK-9079] - Remove unnecessary (un)boxing in oak-security-spi


In addition to the above-mentioned changes, this release contains all
changes up to the previous release.

For more detailed information about all the changes in this and other
Oak releases, please see the Oak issue tracker at

  https://issues.apache.org/jira/browse/OAK

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.md file for instructions on how to build this release.

The source archive is accompanied by SHA512 checksums and a
PGP signature that you can use to verify the authenticity of your
download. The public key used for the PGP signature can be found at
https://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit Oak
---

Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

For more information, visit http://jackrabbit.apache.org/oak

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

[RESULT] [VOTE] Release Apache Jackrabbit Oak 1.32.0

[Marcel Reutegger]

Hi,

The vote passes as follows.

+1 Marcel Reutegger
+1 Woonsan Ko
+1 Julian Reschke

Thanks for voting. I'll push the release out.

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.4

[Marcel Reutegger]

On 13.07.20, 13:04, "Nitin Gupta"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.4.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.22.4

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.32.0

[Marcel Reutegger]

On 10.07.20, 11:20, "Marcel Reutegger"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.32.0.
> The vote is open for the next 120 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.32.0

Regards
 Marcel

[VOTE] Release Apache Jackrabbit Oak 1.32.0

[Marcel Reutegger]

A candidate for the Jackrabbit Oak 1.32.0 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.32.0/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.32.0/

The SHA1 checksum of the archive is badb08abcbba2aba22501f239220e8c21d0cbd73.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.32.0 badb08abcbba2aba22501f239220e8c21d0cbd73

Please vote on releasing this package as Apache Jackrabbit Oak 1.32.0.
The vote is open for the next 120 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.32.0
[ ] -1 Do not release this package because...

Regards
 Marcel

Re: [RT] Limited write support for non-default CompositeNodeStore mounts

[Marcel Reutegger]

Hi,

On 09.07.20, 15:39, "Robert Munteanu"  wrote:
> The details are rough and my memory of the implementation is not that
> good

Same here.

Besides the problem with a potential two phase commit, I think the
biggest concern was impact of a change in a mounted subtree on
repository wide data structures. E.g. what happens when an access
control entry is added to such a subree? How are indexes updated for
nodes changed in the subtree?

I'm also wondering whether and where the current implementation assumes
mounted subtrees are read-only and takes short cuts. These would need to
be changed as well.

Regards
 Marcel

Jackrabbit Oak 1.32.0 release plan

[Marcel Reutegger]

Hi,

I'm planning to cut Jackrabbit Oak 1.32.0 tomorrow.

The list of open issues scheduled for 1.32.0 is empty. I moved
all issues scheduled for 1.32.0 and not in progress to 1.34.0.

https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%201.32.0%20AND%20project%20%3D%20OAK%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

The candidate release notes are here:

https://svn.apache.org/repos/asf/jackrabbit/oak/trunk/RELEASE-NOTES.txt

If there are any objections please let me know.

Regards
Marcel

Re: [Proposal] Feature toggles

[Marcel Reutegger]

Hi,

On 09.07.20, 10:13, "Julian Sedding"  wrote:
> I don't have a use case, but could imagine that introspection of the
> state could be useful for reporting (e.g. a web-console report of all
> active toggles and their state). I understand the desire to keep an API
> minimal, but on the other hand I find it frustrating when an API doesn't
> offer seemingly obvious features (obvious in my mind anyways).

Good point about reporting and a web console plugin. I'll add the method ;)

Regards
 Marcel

Re: [Proposal] Feature toggles

[Marcel Reutegger]

Hi,

I wanted to keep dependencies to a minimum and provide flexibility
how features are actually toggled. The proposal only depends on the
already existing Oak concept of a Whiteboard. In most cases this
indeed means a feature toggle is registered as an OSGi service.

Regards
 Marcel

On 07.07.20, 11:24, "Roy Teeuwen"  wrote:

Hey Marcel,

As I also mentioned in the JIRA ticket. What is the reasoning to put this in 
Oak code, and not directly in Felix? I see no clear connection with Oak and you 
even use a lot of OSGi concepts

Greets,
Roy

> On 7 Jul 2020, at 10:45, Julian Sedding  wrote:
> 
> Hi Marcel,
> 
> I think the API is elegant. Short of running "feature" code in a
> closure, a "try with resource" block encourages developers to clearly
> delimit the block of code that is subject to the feature toggle,
> hopefully resulting in readable code.
> 
> I'm not sure about the aspect of the implementation, that
> FeatureToggle is Closeable and probably often short-lived. Given that
> the FeatureToggleAdapter is registered with the whiteboard, and thus
> likely with the OSGi service registry, this _may_ put unnecessary load
> on the service registry. Furthermore, enabling/disabling the toggle
> would need to be done in a way that respects this dynamism. And
> lastly, even if a FeatureToggleAdapter is already registered for a
> feature, a new service would be registered if the same code was run in
> a second thread.
> 
> From an OSGi perspective, I would lean towards a long-lived singleton
> service that can be toggled. The FeatureToggle could then be adjusted
> to retrieve the matching service if available, or otherwise register
> its own.
> 
> Regarding the API, I would probably rename FeatureToggle to Feature
> and FeatureToggleAdapter to FeatureToggle. But that's of course a
> matter of taste. Also, I would add an "isEnabled" method to
> FeatureToggleAdapter, in order to allow the code setting the toggle to
> introspect the current state.
> 
> Regards
> Julian
> 
> 
> On Mon, Jul 6, 2020 at 7:10 PM Marcel Reutegger
>  wrote:
>> 
>> Hi,
>> 
>> There is a proposal ready in OAK-9132 [0] that introduces the concept of
>> feature toggles [1]. A FeatureToggle is basically a boolean value that
>> controls whether some new feature is available. The implementation uses
>> the Oak Whiteboard to register a feature toggle. It is then up to
>> another bundle to control the state of the feature toggles at
>> initialization and/or runtime.
>> 
>> A very simple implementation that wires feature toggles to system
>> properties is presented in OAK-9132. More sophisticated implementations
>> that talk to a central feature toggle service are also easy to implement
>> with an OSGi component that keeps track of registered feature toggles.
>> 
>> Feedback welcome.
>> 
>> Regards
>> Marcel
>> 
>> [0] https://issues.apache.org/jira/browse/OAK-9132
>> [1] https://martinfowler.com/articles/feature-toggles.html
>> 

Re: [Proposal] Feature toggles

[Marcel Reutegger]

Hi,

Thanks for the feedback Julian.

On 07.07.20, 10:45, "Julian Sedding"  wrote:
> I'm not sure about the aspect of the implementation, that FeatureToggle
> is Closeable and probably often short-lived. Given that the
> FeatureToggleAdapter is registered with the whiteboard, and thus likely
> with the OSGi service registry, this _may_ put unnecessary load on the
> service registry. 

If used as a short-lived object, that is indeed a problem. My intention 
with the FeatureToggle is actually that it is long-lived, though it can
obviously also be used differently. The try-with-resource block in the
tests is just convenient.

> And lastly, even if a FeatureToggleAdapter is already registered for a
> feature, a new service would be registered if the same code was run in a
> second thread.

This is by design. It is valid to have multiple feature toggles registered
with the same name. It's not the primary use case, but they can be used
that way.

> From an OSGi perspective, I would lean towards a long-lived singleton
> service that can be toggled. The FeatureToggle could then be adjusted to
> retrieve the matching service if available, or otherwise register its
> own.

I'm not sure I understand. Can you elaborate what you have in mind?

> Regarding the API, I would probably rename FeatureToggle to Feature and
> FeatureToggleAdapter to FeatureToggle. But that's of course a matter of
> taste. 

Thanks for the suggestion. I like it.

> Also, I would add an "isEnabled" method to FeatureToggleAdapter, in
> order to allow the code setting the toggle to introspect the current
> state.

I considered this as well, but did not see a use case for it. What would
you do with this method?

Regards
 Marcel

[Proposal] Feature toggles

[Marcel Reutegger]

Hi,

There is a proposal ready in OAK-9132 [0] that introduces the concept of
feature toggles [1]. A FeatureToggle is basically a boolean value that
controls whether some new feature is available. The implementation uses
the Oak Whiteboard to register a feature toggle. It is then up to
another bundle to control the state of the feature toggles at
initialization and/or runtime.

A very simple implementation that wires feature toggles to system
properties is presented in OAK-9132. More sophisticated implementations
that talk to a central feature toggle service are also easy to implement
with an OSGi component that keeps track of registered feature toggles.

Feedback welcome.

Regards
 Marcel

[0] https://issues.apache.org/jira/browse/OAK-9132
[1] https://martinfowler.com/articles/feature-toggles.html

Re: Intend to backport OAK-9065 to 1.8, 1.10, and 1.22

[Marcel Reutegger]

Hi,

I don't have general concerns with the backport, but please note the 1.10 
branch was retired on April 6th. See also 
https://jackrabbit.apache.org/oak/docs/roadmap.html
We shouldn't do any backports to that branch anymore.

Regards
 Marcel

On 05.06.20, 17:30, "Thomas Mueller"  wrote:


Hi,

I intend to backport the fix for OAK-9065 to the 1.8, 1.10, and 1.22 branches. 
The risk should be very limited.

Let me know i you have any concerns.

Regards,
Thomas

https://issues.apache.org/jira/browse/OAK-9065

[VOTE] Release Apache Jackrabbit Oak 1.30.0

[Marcel Reutegger]

Hi,

A candidate for the Jackrabbit Oak 1.30.0 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.30.0/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.30.0/

The SHA1 checksum of the archive is b634b7b05d6c0913a9540e1f53d631348cea9d89.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.30.0 b634b7b05d6c0913a9540e1f53d631348cea9d89

Please vote on releasing this package as Apache Jackrabbit Oak 1.30.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.30.0
[ ] -1 Do not release this package because...

Regards
 Marcel

[RESULT] [VOTE] Release Apache Jackrabbit Oak 1.28.0

[Marcel Reutegger]

Hi,

The 72 hours vote period is not yet over. However, it seems unlikely
the release will be approved given the feedback so far. I therefore
decided to close the vote with the following results:

+1 Woonsan Ko
+1 Matt Ryan
-1 Amit Jain
-1 Julian Reschke
-1 Andrei Dulceanu

I will cancel the release and respin it when the issues have been
fixed.

Regards
 Marcel

[VOTE] Release Apache Jackrabbit Oak 1.28.0

[Marcel Reutegger]

Hi,

A candidate for the Jackrabbit Oak 1.28.0 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.28.0/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.28.0/

The SHA1 checksum of the archive is f1d3324a8f2b84c4ca208bf4ea123a16210465b7.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.28.0 f1d3324a8f2b84c4ca208bf4ea123a16210465b7

Please vote on releasing this package as Apache Jackrabbit Oak 1.28.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.28.0
[ ] -1 Do not release this package because...

Regards
 Marcel

Jackrabbit Oak 1.28.0 release plan

[Marcel Reutegger]

Hi,

I'm planning to cut Jackrabbit Oak 1.28.0 tomorrow.

The list of open issues scheduled for 1.26.0 is empty. I moved
all issues scheduled for 1.26.0 and not in progress to 1.30.0.

https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%201.28.0%20AND%20project%20%3D%20OAK%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

The candidate release notes are here:

https://svn.apache.org/repos/asf/jackrabbit/oak/trunk/RELEASE-NOTES.txt

If there are any objections please let me know.

Regards
 Marcel

Re: sonarcloud.io for jackrabbit-oak

[Marcel Reutegger]

Hi,

The following Sling wiki page describes the steps they did:
https://cwiki.apache.org/confluence/display/SLING/SonarCloud+analysis

Regards
 Marcel

On 18.05.20, 11:11, "Aravindo Wingeier"  wrote:

Hi

I noticed there is an apache account on sonarcloud [0], that is connected to 
the apache github account. It would be great to also have the 
jackrabbit-oak github mirror project 
analysed.

Who would be able to add this to sonarcloud?

[0]: https://sonarcloud.io/organizations/apache/projects

Thanks,
Aravindo

Re: [DISCUSS] Oak 1.10 is retired, what does this mean for Jackrabbit 2.18?

[Marcel Reutegger]

Hi,

Sounds good to me. +1

Regards
 Marcel


On 06.04.20, 11:07, "Julian Reschke"  wrote:

Hi there,

so we just retired Oak's 1.10 branch, which has been replaced by Oak 
1.22. Oak 1.22 uses Jackrabbit 2.20; Oak 1.10 was using Jackrabbit 2.18. 
No other Oak branch needs Jackrabbit 2.18.

AFAIR, the main differences between 2.18 and 2.20 are:

- removal of jackrabbit-api (now in Oak)
- refactoring of jackrabbit-standalone (new artifact 
jackrabbit-standalone-components)
- Remove all usage of java.security.acl.Group for Java 14 (JCR-4467), 
causing one incompatible change in jcr-rmi's exported packages

So the switch from 2.18 to 2.20 *might* cause the need to re-compile and 
adjust POMs.

As we did not plan to retire 2.18 yet, my proposal is to update the 
roadmap (), 
and to plan for one final release later this year, then retire the 
branch after that release.

Feedback appreciated.

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.26.0

[Marcel Reutegger]

Hi,

On 20.03.20, 09:33, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.26.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.26.0

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.21

[Marcel Reutegger]

Hi,

On 18.03.20, 11:23, "Julian Reschke"  wrote:
> > That's a test problem I've seen as well; should go away if you run a
> > local Mongo instance. Now the interesting question is why this hasn't
> > surfaced before...
> >
> > Best regards, Julian
> 
> Aha, it *is* a recent change, see OAK-8938. Marcel?

Apologies for the late reply. Yes, this is indeed a test that fails
when no local MongoDB instance is running. OAK-8964 skips
the test when there is no MongoDB.

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.2

[Marcel Reutegger]

On 11.03.20, 09:25, "Nitin Gupta"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.2.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.22.2

Regards
 Marcel

Re: Use of Observer vs ObservationManager for indexes?

[Marcel Reutegger]

Hi,

On 12.03.20, 00:04, "Matt Ryan"  wrote:
> Further digging revealed what I suspected - that the ObservationManager
> approach actually uses an Observer registered with the whiteboard under
> the covers.
> 
> The question remains though - why the two approaches, and in specific
> why are indexes registered as Observers rather than via the
> ObservationManager method?

The main difference is at what layer an Observer is registered compared
to a JCR EventListener. An Observer gets the new root state of the repository
and it is up to the implementation to figure out what changed. A JCR
EventListener gets the actual changes as events. Another major difference
is authorization. An Observer sees everything and basically runs with admin
privileges, while a JCR EventListener is restricted to only see events for
changes on nodes the corresponding Session is able to read.

Regards
 Marcel

Re: oak-osgi : lucene searching not working

[Marcel Reutegger]

Hi Sandeep,

In both scenarios you describe how a DocumentNodeStore instance
is created. Your application must have more components than just
a NodeStore implementation to get search working in Oak using
Lucene. The NodeStore implementation itself does not provide
any search functionality. Please check how the DocumentNodeStore
is further used in your application to initialize an Oak ContentRepository
or a JCR Repository. I assume, this is where the difference is.

Regards
 Marcel


On 09.03.20, 08:43, "Sandeep Ambule"  wrote:
> >So, this is not about RDB, but about using the DocumentNodeStoreService
> or not, right?
> 
> Yes, This is not about RDB ,Its about using osgi service, here i am
> using DocumentNodeStoreService.
> 
> In scenario 2: i have injected datascource,and Using
> DocumentNodeStoreService created repository . i can store data and
> create index but not able to do full text search.
> 
> In scenario 1: i have created DocumentNodeStre created dataSource using
> RDBDataSourceFactory and created DocumentNodeStore using
> RDBDocumentNodeStoreBuilder insted of injecting osgi service. Using this
> scenario fulltext search working correctly
> 
> may be i am missing something while creating repository while using osgi
> service?
> 
> but if you see my code i have used same code to create repository only
> difference is
> 
> DocumentNodeStoreService.
> 
> In scenario 1 , i have provided DocumenNodeStore and In scenario 2: i
> have provided

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.20

[Marcel Reutegger]

Hi,

On 28.01.20, 20:33, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.8.20.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.8.20

Regards
 Marcel

Re: [PROPOSAL] Branch 1.22.0

[Marcel Reutegger]

Hi,

This sounds good to me. It wasn't immediately clear to me why the branch
would be from the 1.22.0 release instead of 1.24.0, but I think I
understand now. One of the goals of the 1.22 branch would be to replace
and retire the 1.10 branch, which means the releases from the 1.22 branch
should provide a smooth upgrade path from 1.10.x releases. Hence, the
proposed flip of the default for lazy index loading. I think it's important
this is documented clearly.

Regards
 Marcel

On 29.01.20, 15:03, "Julian Reschke"  wrote:
> When we introduced the new release/branching strategy last March, it was
> clear that we might have to create branches once incompatible changes
> happen.
> 
> Now is the time. (Well, soon).
> 
>  will make incompatible
> changes (so that we can compile & run on Java 14). I therefore propose
> to create a branch, from which we can continue to cut releases that are
> fully compatible with 1.22.0.
> 
> The good news is that we have confirmed that 1.22.* can be used as
> drop-in replacement for 1.10.*, thus at the same time (or close to it)
> we could retire 1.10.
> 
> The only issue we found was due to slightly changed system behaviour
> when lazy loading of Lucene index files is in effect. I would therefore
> propose to disable that feature in the first release from that branch
> (see , there's a system
> property for this, we would just have to flip the default value).
>
> (And yes, this proposal is equivalent to just replay *any* change made
> in trunk to 1.10.*)
> 
> The concrete steps would be:
> 
> - create the branch based on the tag 1.22.0 - flip the default for lazy
> loading of Lucene index files - backport selected changes from trunk
> (such as related to yesterday's CVE) - release 1.22.1 - (later on)
> retire 1.10.*
> 
> As to why not to branch based on 1.24.0: I'd like to avoid any confusion
> about what is "newer". If we released 1.24.1 people might think this is
> something to upgrade from 1.24.0 from (and that would be incorrect due
> to the change related to OAK-7947).

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.19

[Marcel Reutegger]

On 18.01.20, 13:25, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.8.19.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.8.19

Regards
 Marcel

Re: Import problem

[Marcel Reutegger]

Hi,

The Guava method sameThreadExecutor() was removed in version 21 [0].
I assume there must be a more recent Guava version than 15 on your
classpath.

Regards
 Marcel

[0] https://github.com/google/guava/wiki/Release21#commonutilconcurrent

On 18.01.20, 22:22, "jorgeeflorez ."  wrote:

Hello all,
I am trying to build a standalone application that will use Jackrabbit and
Oak (a Gradle project). I am having problems when the node store is being
built. This is the stack trace:

Exception in thread "main" java.lang.NoSuchMethodError:

com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor()Lcom/google/common/util/concurrent/ListeningExecutorService;
at

org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBuilder.getExecutor(DocumentNodeStoreBuilder.java:440)
at

org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.(DocumentNodeStore.java:554)

It seems a Guava related problem. I tried to declare the dependency in my
project to 15.0 version but the problem persists.

Any help is welcome.

Regards,

Jorge

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.25

[Marcel Reutegger]

On 14.01.20, 07:32, "Nitin Gupta"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.4.25.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.4.25

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.0

[Marcel Reutegger]

Hi,

On 13.01.20, 13:27, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.22.0

Regards
 Marcel
 

Re: Regarding DocumentStore and BlobStore

[Marcel Reutegger]

Hi,

On 12.01.20, 15:40, "jorgeeflorez ."  wrote:
> If I use MongoDB as document store will I be able to set as blob store
> one of the six available, right?

Any blob store implementation can be configured in combination with the
DocumentNodeStore on MongoDB. Though, for production use file or cloud
storage based blob stores are recommended.

> If the answer to the previous question is yes, if I create two backends
> (Oak instances), both using the same type of document and blob store,
> and both pointing to the same "location" (folder in a file system, S3
> path, etc). will they work without collisions or conflicts when
> reading/storing files?

For the blob stores this is generally true. When it comes to NodeStore
implementations, only the DocumentNodeStore will also work in a clustered
setup. The SegmentNodeStore implementation does support multiple active
processes working on the same storage.

Regards
 Marcel

Re: Deprecating API signatures referring to Guava in 1.10

[Marcel Reutegger]

Hi,

On 06.12.19, 14:07, "Julian Reschke"  wrote:
> once we do a stable release from trunk with the removal (say, 1.26),
> there would be no officially supported Oak release which deprecates the
> API. That is, 1.10.* (and earlier) would contain the old API (and not
> deprecate it), 1.26.0 (and later) would only contain the new API.

I agree that it would be good to have a smooth migration path between
supported releases. But then, backporting changes to a maintenance branch
that are rather enhancements also looks a bit odd to me.

Alternatively, we could declare 1.24 a long term support release and
create a branch at that point. Given our previous discussion around
when to branch, it is something we should consider anyway.

https://jackrabbit.apache.org/oak/docs/release-schedule.html#Branching

Applications on 1.10 using deprecated API would then upgrade to 1.24
first, change the application to use the new API and then finally upgrade
to 1.26 (or whatever more recent that is compatible).

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.20.0

[Marcel Reutegger]

Hi,

On 20.11.19, 07:17, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.20.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.20.0

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.10.6

[Marcel Reutegger]

Hi,

On 07.11.19, 11:42, "Julian Reschke"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.10.6.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.10.6

Regards
 Marcel

Re: Disabling lease check for read repository

[Marcel Reutegger]

Hi Yogesh,

On 04.10.19, 00:48, "yogesh upadhyay"  wrote:
> - what's the role of lease check if you are using Mysql.

The lease check is part of the clusterId mechanism that gives each cluster node
a unique id. This is not specific to the DocumentStore backend in use and is
needed for any backend.

See also 
https://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cluster-node-metadata

> - Can we disable leasecheck for read repository ?

This is already the case when you construct a read-only DocumentNodeStore [0].

> - What is the consequence of disabling lease check in prod ? (repository
> corruption ?)

One of the problems that can occur are described here:
https://issues.apache.org/jira/browse/OAK-3883

Consistency can be at risk when lease checks are disabled and recovery is 
performed
by another cluster node even though the (temporarily?) unresponsive cluster node
is still alive and then continues to write.

There are also implications on the Sling Topology when lease checks are 
disabled.
The system may end up in a situation where multiple leaders exist.

Regards
 Marcel

[0] 
https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.18.0/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreBuilder.java#L267

Re: [DISCUSS] Impact of not updating last-modified time when writing a blob that already exists?

[Marcel Reutegger]

Hi,

On 02.10.19, 09:22, "Matt Ryan"  wrote:
> The question is:  What would be the impact if we were unable to
> update the last-modified time in this situation?

I think the update is important for the datastore garbage collection
to work correctly. There was an issue with the MongoBlobStore
implementation a while ago that had a very similar problem:
https://issues.apache.org/jira/browse/OAK-7389

According to comments in the issue, the datastore garbage collector
may remove such blobs.

Regards
 Marcel