Re: [RESULT][VOTE] Release Apache Jackrabbit Oak {$version}
On 18/08/2016 14:21, Bertrand Delacretaz wrote:
> On Thu, Aug 18, 2016 at 3:19 PM, Davide Giannella wrote:
>> ...Thanks for voting. I'll push the release out. ..
> huh, which {$version} is that?
ouch! it was 1.5.8.
D.
Re: RepositorySidegrade and commit hooks
Thanks Tomek for confirmation. Opened OAK-4684 to track that Chetan Mehrotra On Fri, Aug 19, 2016 at 3:52 PM, Tomek Rekawek wrote: > Hi Chetan, > > yes, it seems that this has been overlooked in the OAK-3239 (porting the > —include-paths support from RepositoryUpgrade). Feel free to create an issue > / commit a patch or let me know if you want me to do it. > > Best regards, > Tomek > > -- > Tomek Rękawek | Adobe Research | www.adobe.com > reka...@adobe.com > >> On 19 Aug 2016, at 10:38, Chetan Mehrotra wrote: >> >> For complete migration yes all bits are there. However people also use >> this for partial incremental migration from source system to target >> system. In that case include paths are provide for those paths whose >> content need to be updated. In such a case it can happen that derived >> content for those paths (property index, permission store entries) do >> not get updated and that would result in inconsistent state >> Chetan Mehrotra >> >> >> On Fri, Aug 19, 2016 at 1:59 PM, Alex Parvulescu >> wrote: >>> Hi, >>> >>> I don't think any extra hooks are needed here. Sidegrade is just a change >>> in persistence format, all the bits should be there already in the old >>> repository. >>> >>> best, >>> alex >>> >>> On Fri, Aug 19, 2016 at 6:45 AM, Chetan Mehrotra >>> wrote: >>> Hi, Does RepositorySidegrade runs all the commit hooks required for getting a consistent JCR level state like permission editor, property editor etc I can such hooks configured for RepositoryUpgrade but not seeing any such hook configured for RepositorySidegrade Probably we should also configure same set of hooks? Chetan Mehrotra >
Re: RepositorySidegrade and commit hooks
Hi Chetan, yes, it seems that this has been overlooked in the OAK-3239 (porting the —include-paths support from RepositoryUpgrade). Feel free to create an issue / commit a patch or let me know if you want me to do it. Best regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com reka...@adobe.com > On 19 Aug 2016, at 10:38, Chetan Mehrotra wrote: > > For complete migration yes all bits are there. However people also use > this for partial incremental migration from source system to target > system. In that case include paths are provide for those paths whose > content need to be updated. In such a case it can happen that derived > content for those paths (property index, permission store entries) do > not get updated and that would result in inconsistent state > Chetan Mehrotra > > > On Fri, Aug 19, 2016 at 1:59 PM, Alex Parvulescu > wrote: >> Hi, >> >> I don't think any extra hooks are needed here. Sidegrade is just a change >> in persistence format, all the bits should be there already in the old >> repository. >> >> best, >> alex >> >> On Fri, Aug 19, 2016 at 6:45 AM, Chetan Mehrotra >> wrote: >> >>> Hi, >>> >>> Does RepositorySidegrade runs all the commit hooks required for >>> getting a consistent JCR level state like permission editor, property >>> editor etc >>> >>> I can such hooks configured for RepositoryUpgrade but not seeing any >>> such hook configured for RepositorySidegrade >>> >>> Probably we should also configure same set of hooks? >>> >>> Chetan Mehrotra >>> smime.p7s Description: S/MIME cryptographic signature
[Oak origin/1.2] Apache Jackrabbit Oak matrix - Build # 1107 - Failure
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #1107) Status: Failure Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1107/ to view the results. Changes: [dj] OAK-4679 : Backport OAK-4119, OAK-4101, OAK-4087 and OAK-4344 - [dj] OAK-4679 : Backport OAK-4119, OAK-4101, OAK-4087 and OAK-4344 - Test results: 14 tests failed. FAILED: org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexHookIT.testPropertyAddition Error Message: expected:<[bar]> but was:<[]> Stack Trace: junit.framework.AssertionFailedError: expected:<[bar]> but was:<[]> at junit.framework.Assert.fail(Assert.java:57) at junit.framework.Assert.failNotEquals(Assert.java:329) at junit.framework.Assert.assertEquals(Assert.java:78) at junit.framework.Assert.assertEquals(Assert.java:86) at org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexHookIT.testPropertyAddition(SolrIndexHookIT.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) FAILED: org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.testRepSimilarXPathQuery Error Message: expected: but was: Stack Trace: junit.framework.ComparisonFailure: expected: but was: at junit.framework.Assert.assertEquals(Assert.java:100) at junit.framework.Assert.assertEquals(Assert.java:107) at org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.testRepSimilarXPathQuery(SolrIndexQueryTestIT.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.rules.TestWatc
Re: RepositorySidegrade and commit hooks
I stand corrected then :) I had no clue a partial sidegrade is even possible. On Fri, Aug 19, 2016 at 10:38 AM, Chetan Mehrotra wrote: > For complete migration yes all bits are there. However people also use > this for partial incremental migration from source system to target > system. In that case include paths are provide for those paths whose > content need to be updated. In such a case it can happen that derived > content for those paths (property index, permission store entries) do > not get updated and that would result in inconsistent state > Chetan Mehrotra > > > On Fri, Aug 19, 2016 at 1:59 PM, Alex Parvulescu > wrote: > > Hi, > > > > I don't think any extra hooks are needed here. Sidegrade is just a change > > in persistence format, all the bits should be there already in the old > > repository. > > > > best, > > alex > > > > On Fri, Aug 19, 2016 at 6:45 AM, Chetan Mehrotra < > chetan.mehro...@gmail.com> > > wrote: > > > >> Hi, > >> > >> Does RepositorySidegrade runs all the commit hooks required for > >> getting a consistent JCR level state like permission editor, property > >> editor etc > >> > >> I can such hooks configured for RepositoryUpgrade but not seeing any > >> such hook configured for RepositorySidegrade > >> > >> Probably we should also configure same set of hooks? > >> > >> Chetan Mehrotra > >> >
Re: RepositorySidegrade and commit hooks
For complete migration yes all bits are there. However people also use this for partial incremental migration from source system to target system. In that case include paths are provide for those paths whose content need to be updated. In such a case it can happen that derived content for those paths (property index, permission store entries) do not get updated and that would result in inconsistent state Chetan Mehrotra On Fri, Aug 19, 2016 at 1:59 PM, Alex Parvulescu wrote: > Hi, > > I don't think any extra hooks are needed here. Sidegrade is just a change > in persistence format, all the bits should be there already in the old > repository. > > best, > alex > > On Fri, Aug 19, 2016 at 6:45 AM, Chetan Mehrotra > wrote: > >> Hi, >> >> Does RepositorySidegrade runs all the commit hooks required for >> getting a consistent JCR level state like permission editor, property >> editor etc >> >> I can such hooks configured for RepositoryUpgrade but not seeing any >> such hook configured for RepositorySidegrade >> >> Probably we should also configure same set of hooks? >> >> Chetan Mehrotra >>
Re: RepositorySidegrade and commit hooks
Hi, I don't think any extra hooks are needed here. Sidegrade is just a change in persistence format, all the bits should be there already in the old repository. best, alex On Fri, Aug 19, 2016 at 6:45 AM, Chetan Mehrotra wrote: > Hi, > > Does RepositorySidegrade runs all the commit hooks required for > getting a consistent JCR level state like permission editor, property > editor etc > > I can such hooks configured for RepositoryUpgrade but not seeing any > such hook configured for RepositorySidegrade > > Probably we should also configure same set of hooks? > > Chetan Mehrotra >
