[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 750 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#750)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/750/ to view 
the results.

Changes:
[davide] OAK-3996 - Update Jackrabbit version to 2.12.0

[reschke] OAK-4020: RDBExport: fix misleading warning about column names

[baedke] OAK-4018: Test failures after upgrading to JR 2.12.0

[stefanegli] OAK-4006 : clusterId created by ClusterRepositoryInfo is now 
getOrCreate

[stefanegli] OAK-4007 : adding resetclusterid tool to oak-run via which the 
clusterId

[davide] OAK-3996 - Update Jackrabbit version to 2.12.0

[angela] minor improvement: security doc (externalloginmodule)

[angela] OAK-4016 : Document composite authorization setup (WIP) minor

[reschke] OAK-4021: RDBDocumentStore: fix return value for create() on 
collections

 

Test results:
50 tests failed.
FAILED:  
org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest.testRenameEventHandling

Error Message:
Item is protected.

Stack Trace:
javax.jcr.nodetype.ConstraintViolationException: Item is protected.
at 
org.apache.jackrabbit.oak.jcr.session.ItemImpl$ItemWriteOperation.checkPreconditions(ItemImpl.java:98)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:271)
at 
org.apache.jackrabbit.oak.jcr.session.NodeImpl.rename(NodeImpl.java:1501)
at 
org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest.testRenameEventHandling(JackrabbitNodeTest.java:124)
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:483)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at 
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
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:483)
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.jcr.JackrabbitNodeTest.testRename

Error Message:
expected:<[a]> but was:<[rep:policy]>

Stack Trace:
junit.framework.ComparisonFailure: expected:<[a]> but was:<[rep:policy]>
at junit.framework.Assert.assertEquals(Assert.java:100)
at junit.framework.Assert.assertEquals(Assert.java:107)
at junit.framework.TestCase.assertEquals(TestCase.java:269)
at 
org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest.testRename(JackrabbitNodeTest.java:74)
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:483)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at 

Re: DocumentStore question.

[Marcel Reutegger]

Hi,

On 12/02/16 17:11, "ianbos...@gmail.com on behalf of Ian Boston" wrote:
>Is there an assumption that the revisions listed in _revisions are
>ordered ?

There is no requirement that entries in _revisions map
are ordered at the storage layer, but the DocumentStore
will order them when it reads the entries. The entries
are sorted according to the timestamp of the revision,
then revision counter and finally clusterId.

>If not, then how is the order of the revisions be determined, given that
>the clocks on each node in a cluster will have different offsets ?

Oak 1.0.x and 1.2.x maintain a revision table (in RevisionComparator)
for each cluster node, which allows it to compare revision across
cluster nodes even when there are clock differences. At least for
the 60 minutes timeframe covered by the RevisionComparator.

Oak 1.4 uses revision vectors and does not maintain a revision
table anymore. See OAK-3646. At the same time it also simplifies
how revisions are compared and how changes are pulled in from
other cluster nodes. The background read operation ensures that
external changes made visible all have a lower revision timestamp
than the local clock. This ensure that all local changes from that
point on will have a higher revision timestamp than externally
visible changes. This part was also backported to 1.0 and 1.2.
See OAK-3388.

Regards
 Marcel 

Re: oak-upgrade test failures (was Re: Oak 1.3.16 release plan)

[Manfred Baedke]

Hi Tomek,

Thx a lot. I'll patch the relevant branches now.

Best regards,
Manfred

On 2/15/2016 11:41 AM, Tomek Rekawek wrote:

Hello,

The already mentioned JCR-2633 puts jcr:mixinTypes property into 
NodePropBundle#getPropertyEntries(). As a result, the oak-upgrade code 
responsible for replacing mix:simpleVersionable with mix:versionable doesn’t 
work correctly (the results are replaced by the original properties). I 
explained this in OAK-4018 and attached a patch.

Best regards,
Tomek


On 15/02/16 11:17, "Julian Sedding"  wrote:


The test failures in the issue seem to suggest that this may be relates to
simple versionables. IIRC we recently added support for some broken JR2
constructs. Could they have been fixed in the last JR release? If that's
the case it may no longer be possible to populate the source repository for
the tests.

Just pure guesses, but I thought it might help.

Regards
Julian


On Monday, February 15, 2016, Davide Giannella  wrote:


On 12/02/2016 18:36, Manfred Baedke wrote:

Hi,

This is due to change 1721196 (associated with JCR-2633), which
changes the persistent data model. Probably the test has just to be
tweaked accordingly, I'll look into it during WE.

Thank you very much Manfred.

I've filed https://issues.apache.org/jira/browse/OAK-4018 to keep track
and block 1.3.16.

 From here, once it's fixed in JR we have potentially 2 options:

1) unlock 1.3.16 by downgrading to JR 2.11.3
2) release JR 2.12.1, upgrade to Oak, release 1.3.16. Which will bring
the oak relase around 4-5 days late.

I'm for two as it will give us more coverage around the inclusion of the
new stable JR release.

Thoughts?

Davide

Re: OAK-4006 : Enable cloning of repo for shared data store and discovery-lite

[Stefan Egli]

Thanks for the various comments and review on OAK-4006. I've attached a
final version of the patch and will push that later this afternoon
(together with OAK-4007) unless I hear fresh concern.

Cheers,
Stefan

On 11/02/16 20:16, "Stefan Egli"  wrote:

>Hi all,
>
>The recent clusterId-discussions around OAK-3935 together with the cloning
>problem it shares with discovery.oak made me rethink the current
>two-clusterId-approach. After some offline discussions with Thomas and
>Marcel I've created OAK-4006 which suggests reusing the SharedDataStore
>way
>of a hidden :clusterId property, providing a dedicated 'after clone'
>offline
>reset tool in oak-run and using that same clusterId also in discovery-lite
>(thus discovery.oak). This should leave us with only 1 clusterId in the
>stack.
>
>Since 1.4 will be the first to support discovery.oak, and to allow for
>enough testing, it would be important to have this in 1.3.16. I will
>therefore work on a patch tomorrow and would highly appreciate comments on
>the approach and patch. If +1-ed It should delay 1.3.16 a few hours or a
>day.
>
>https://issues.apache.org/jira/browse/OAK-4006
>
>Cheers,
>Stefan
>
>

Re: oak-upgrade test failures (was Re: Oak 1.3.16 release plan)

[Davide Giannella]

On 15/02/2016 10:47, Julian Reschke wrote:
> ...in the meantime, I think we should change oak-trunk back to use
> 2.11.3, so we have a clean build until this new issue is understood
> and fixed.

Done! :)

Cheers
Davide

Re: oak-upgrade test failures (was Re: Oak 1.3.16 release plan)

[Julian Reschke]

On 2016-02-15 11:47, Julian Reschke wrote:

...in the meantime, I think we should change oak-trunk back to use
2.11.3, so we have a clean build until this new issue is understood and
fixed.

Best regards, Julian


Related to that...: OAK 1.2 currently uses Jackrabbit 2.10.0, although 
2.10.1 has been released a long time ago.


Shouldn't Oak always use the latest stable release from the matching 
Jackrabbit branch?


Best regards, Julian

Re: oak-upgrade test failures (was Re: Oak 1.3.16 release plan)

[Julian Reschke]

On 2016-02-15 10:31, Davide Giannella wrote:

On 12/02/2016 18:36, Manfred Baedke wrote:

Hi,

This is due to change 1721196 (associated with JCR-2633), which
changes the persistent data model. Probably the test has just to be
tweaked accordingly, I'll look into it during WE.

Thank you very much Manfred.

I've filed https://issues.apache.org/jira/browse/OAK-4018 to keep track
and block 1.3.16.


From here, once it's fixed in JR we have potentially 2 options:


1) unlock 1.3.16 by downgrading to JR 2.11.3
2) release JR 2.12.1, upgrade to Oak, release 1.3.16. Which will bring
the oak relase around 4-5 days late.

I'm for two as it will give us more coverage around the inclusion of the
new stable JR release.

Thoughts?

Davide


...in the meantime, I think we should change oak-trunk back to use 
2.11.3, so we have a clean build until this new issue is understood and 
fixed.


Best regards, Julian

Re: oak-upgrade test failures (was Re: Oak 1.3.16 release plan)

[Tomek Rekawek]

Hello,

The already mentioned JCR-2633 puts jcr:mixinTypes property into 
NodePropBundle#getPropertyEntries(). As a result, the oak-upgrade code 
responsible for replacing mix:simpleVersionable with mix:versionable doesn’t 
work correctly (the results are replaced by the original properties). I 
explained this in OAK-4018 and attached a patch.

Best regards,
Tomek


On 15/02/16 11:17, "Julian Sedding"  wrote:

>The test failures in the issue seem to suggest that this may be relates to
>simple versionables. IIRC we recently added support for some broken JR2
>constructs. Could they have been fixed in the last JR release? If that's
>the case it may no longer be possible to populate the source repository for
>the tests.
>
>Just pure guesses, but I thought it might help.
>
>Regards
>Julian
>
>
>On Monday, February 15, 2016, Davide Giannella  wrote:
>
>> On 12/02/2016 18:36, Manfred Baedke wrote:
>> > Hi,
>> >
>> > This is due to change 1721196 (associated with JCR-2633), which
>> > changes the persistent data model. Probably the test has just to be
>> > tweaked accordingly, I'll look into it during WE.
>> Thank you very much Manfred.
>>
>> I've filed https://issues.apache.org/jira/browse/OAK-4018 to keep track
>> and block 1.3.16.
>>
>> From here, once it's fixed in JR we have potentially 2 options:
>>
>> 1) unlock 1.3.16 by downgrading to JR 2.11.3
>> 2) release JR 2.12.1, upgrade to Oak, release 1.3.16. Which will bring
>> the oak relase around 4-5 days late.
>>
>> I'm for two as it will give us more coverage around the inclusion of the
>> new stable JR release.
>>
>> Thoughts?
>>
>> Davide
>>
>>
>>

Re: oak-upgrade test failures (was Re: Oak 1.3.16 release plan)

[Julian Sedding]

The test failures in the issue seem to suggest that this may be relates to
simple versionables. IIRC we recently added support for some broken JR2
constructs. Could they have been fixed in the last JR release? If that's
the case it may no longer be possible to populate the source repository for
the tests.

Just pure guesses, but I thought it might help.

Regards
Julian


On Monday, February 15, 2016, Davide Giannella  wrote:

> On 12/02/2016 18:36, Manfred Baedke wrote:
> > Hi,
> >
> > This is due to change 1721196 (associated with JCR-2633), which
> > changes the persistent data model. Probably the test has just to be
> > tweaked accordingly, I'll look into it during WE.
> Thank you very much Manfred.
>
> I've filed https://issues.apache.org/jira/browse/OAK-4018 to keep track
> and block 1.3.16.
>
> From here, once it's fixed in JR we have potentially 2 options:
>
> 1) unlock 1.3.16 by downgrading to JR 2.11.3
> 2) release JR 2.12.1, upgrade to Oak, release 1.3.16. Which will bring
> the oak relase around 4-5 days late.
>
> I'm for two as it will give us more coverage around the inclusion of the
> new stable JR release.
>
> Thoughts?
>
> Davide
>
>
>

Re: Anchor tags on doc pages get positioned wrongly under top menu

[Davide Giannella]

On 14/02/2016 17:42, Julian Sedding wrote:
> Hi Vikas
>
> I agree that having the anchor text hidden is a usability hazard. I
> tried your suggested approach in Firefox (via FireBug) and didn't have
> any success. However, a slight variation of the scheme, still relying
> on the ":target" pseudo selector, did the trick for me.
>
> h2 > a:target {
> position: relative;
> top: -40px;
> }
>
> I scoped the rule to the "h2" element, which is defined to have a
> height of 40px. I think it's then ok to repeat this value.
>
Another point I remember from my past in HTML+CSS is that instead of
using `px`, use `pt`. Rather than being a fixed amount of pixels which
will vary in rendition from device to device, it will vary according to
the user selected text size (points). Or was something around such
explanation. :)

HTH
Davide

Re: oak-upgrade test failures (was Re: Oak 1.3.16 release plan)

[Davide Giannella]

On 12/02/2016 18:36, Manfred Baedke wrote:
> Hi,
>
> This is due to change 1721196 (associated with JCR-2633), which
> changes the persistent data model. Probably the test has just to be
> tweaked accordingly, I'll look into it during WE.
Thank you very much Manfred.

I've filed https://issues.apache.org/jira/browse/OAK-4018 to keep track
and block 1.3.16.

>From here, once it's fixed in JR we have potentially 2 options:

1) unlock 1.3.16 by downgrading to JR 2.11.3
2) release JR 2.12.1, upgrade to Oak, release 1.3.16. Which will bring
the oak relase around 4-5 days late.

I'm for two as it will give us more coverage around the inclusion of the
new stable JR release.

Thoughts?

Davide