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

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[frm] OAK-4883 - Register a BlobGCMBean on standby instances

 

Test results:
1 tests failed.
FAILED:  
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiterTest.blockCommits

Error Message:
Unexpected exception, 
expected but 
was

Stack Trace:
java.lang.Exception: Unexpected exception, 
expected but 
was
at 
org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:28)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
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:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
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)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1281)
at java.lang.Thread.join(Thread.java:1355)
at 
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiterTest.blockCommits(CommitRateLimiterTest.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
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.ExpectException.evaluate(ExpectException.java:19)
... 22 more

Re: Possibility of making nt:resource unreferenceable

[Thomas Mueller]

Hi,
>
>Currently I am under the impression that we have no knowledge of what
>*might* break, with varying opinions on the matter. Maybe we should to
>find out what *does* break.

I don't think it's possible to easily find out. Customer code might expect
the current behavior, and might silently break (without exception, but
with wrong behavior).

>
>As a remedy for implementations that rely on the current referencable
>nature, we could provide tooling that automatically adds the
>"mix:referencable" mixin to existing nt:resource nodes and recommend
>adapting the code to add the mixin as well.

That might work, but in some cases it might also result in problems (if
the code expects this not to be the case).

Regards,
Thomas

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

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[amitj] OAK-4902: Blob GC completion time should be logged in millis

[mduerig] OAK-4467: Upgrade io-commons to 2.5 and remove ReversedLinesFileReader

[frm] OAK-4926 - Avoid throwing SNFEs when checking for locally available

 

Test results:
11 tests failed.
FAILED:  
org.apache.jackrabbit.oak.plugins.segment.standby.ExternalPrivateStoreIT.testProxyFlippedIntermediateByteChange2

Error Message:
expected:<{ root = { ... } }> but was:<{ root : { } }>

Stack Trace:
java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { } }>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:193)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxyFlippedIntermediateByteChange2(DataStoreTestBase.java:157)
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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
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.upgrade.LongNameTest.org.apache.jackrabbit.oak.upgrade.LongNameTest

Error Message:
Cannot instantiate persistence manager 
org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager

Stack Trace:
javax.jcr.RepositoryException: Cannot instantiate persistence manager 
org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager
at 
org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1379)
at 
org.apache.jackrabbit.core.RepositoryImpl.access$200(RepositoryImpl.java:126)
at 
org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doInitialize(RepositoryImpl.java:2052)
at 
org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:2035)
at 
org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:543)
at 

[Oak origin/1.2] Apache Jackrabbit Oak matrix - Build # 1203 - Failure

[Apache Jenkins Server]

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

Status: Failure

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

Changes:
[amitj] Oak 1.2.20 release notes

[amitj] [maven-release-plugin] prepare release jackrabbit-oak-1.2.20

[amitj] [maven-release-plugin] prepare for next development iteration

 

Test results:
7 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.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 

Re: Possibility of making nt:resource unreferenceable

[Julian Sedding]

On Wed, Oct 12, 2016 at 11:24 AM, Bertrand Delacretaz
 wrote:
> On Wed, Oct 12, 2016 at 11:18 AM, Julian Sedding  wrote:
>> ...As a remedy for implementations that rely on the current referencable
>> nature, we could provide tooling that automatically adds the
>> "mix:referencable" mixin to existing nt:resource nodes...
>
> Good idea, I suppose this can be done with a commit hook in a non-intrusive 
> way?

For JR2 content being upgraded to Oak (or during an Oak to Oak
"sidegrade"), i.e. in the oak-upgrade module, it would be easy to add
this functionality via a commit hook.

For an existing Oak repository the same functionality could be
implemented on the JCR API and a full repo traversal, I suppose. If we
can get past the node-type validation. Alternatively we could come up
with an extension SPI/API that allows plugging in an implementation
for specific non-trivial node-type updates. This would even allow for
two alternative implementations: one that adds mix:referencable and
another that removes the jcr:uuid property - so JCR users could choose
which strategy they prefer.

Regards
Julian


>
> -Bertrand

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.12

[Amit Jain]

On Tue, Oct 11, 2016 at 3:27 PM, Davide Giannella  wrote:

> Please vote on releasing this package as Apache Jackrabbit Oak 1.5.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.
>

+1 Release this package as Apache Jackrabbit Oak 1.5.12

Thanks
Amit

Re: Possibility of making nt:resource unreferenceable

[Bertrand Delacretaz]

On Wed, Oct 12, 2016 at 11:18 AM, Julian Sedding  wrote:
> ...As a remedy for implementations that rely on the current referencable
> nature, we could provide tooling that automatically adds the
> "mix:referencable" mixin to existing nt:resource nodes...

Good idea, I suppose this can be done with a commit hook in a non-intrusive way?

-Bertrand

Re: Possibility of making nt:resource unreferenceable

[Julian Sedding]

I'm with Julian R. on this (as I understand him). We should change the
node-type nt:resource to match the JCR 2.0 spec and deal with the
consequences.

Currently I am under the impression that we have no knowledge of what
*might* break, with varying opinions on the matter. Maybe we should to
find out what *does* break.

As a remedy for implementations that rely on the current referencable
nature, we could provide tooling that automatically adds the
"mix:referencable" mixin to existing nt:resource nodes and recommend
adapting the code to add the mixin as well.

Regards
Julian


On Wed, Oct 12, 2016 at 11:04 AM, Carsten Ziegeler  wrote:
> The latest proposal was not about making nt:resource unreferenceable,
> but silently changing the resource type for a nt:resource child node of
> a nt:file node to Oak:Resource.
>
> I just found three other places in Sling where nt:file nodes are created
> by hand. So with any other mechanism we have to change a lot of places
> in Sling alone. Not to mention all downstream users.
>
> Carsten
>
> Thomas Mueller wrote
>> Hi,
>>
>> I agree with Julian, I think making nt:resource unreferenceable would
>> (hardcoding some "magic" in Oak) would lead to hard-to-find bugs and
>> problems.
>>
>>> So whatever solution we pick, there is a risk that existing code fails.
>>
>> Yes. But I think if we create a new nodetype, at least it would be easier
>> for users to understand the problem.
>>
>> Also, the "upgrade path" with a new nodetype is smoother. This can be done
>> incrementally, even thought it might mean more total work. But making
>> nt:resource unreferenceable would be a hard break, and I think risk of
>> bigger problems is higher.
>>
>> Regards,
>> Thomas
>>
>>
>>
>> On 07/10/16 12:05, "Julian Reschke"  wrote:
>>
>>> On 2016-10-07 10:56, Carsten Ziegeler wrote:
 Julian Reschke wrote
> On 2016-10-07 08:04, Carsten Ziegeler wrote:
>> ...
>> The easiest solution that comes to my mind is:
>>
>> Whenever a nt:resource child node of a nt:file node is created, it is
>> silently changed to oak:resource.
>>
>> Carsten
>> ...
>
> Observation: that might break code that actually wants a referenceable
> node: it would create the node, check for the presence of
> mix:referenceable, and then decide not to add it because it's already
> there.
>

 Well, there might be code that assumes that a file uploaded through
 webdav is using a resource child node that is referenceable.
 Or a file posted through the Sling POST servlet has this. Now, you could
 argue if that code did not create the file, it should check node types,
 but how likely is that if the code has history?

 So whatever solution we pick, there is a risk that existing code fails.
 ...
>>>
>>> That is true..
>>>
>>> However, my preference would be to only break code which is
>>> non-conforming right now. Code should not rely on nt:resource being
>>> referenceable (see
>>> >> ml#3.7.11.5%20nt:resource>).
>>>
>>> So my preference would be to make that change and see what breaks (and
>>> get that fixed).
>>>
 ...
>>>
>>>
>>> Best regards, Julian
>>
>>
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: Possibility of making nt:resource unreferenceable

[Carsten Ziegeler]

The latest proposal was not about making nt:resource unreferenceable,
but silently changing the resource type for a nt:resource child node of
a nt:file node to Oak:Resource.

I just found three other places in Sling where nt:file nodes are created
by hand. So with any other mechanism we have to change a lot of places
in Sling alone. Not to mention all downstream users.

Carsten

Thomas Mueller wrote
> Hi,
> 
> I agree with Julian, I think making nt:resource unreferenceable would
> (hardcoding some "magic" in Oak) would lead to hard-to-find bugs and
> problems.
> 
>> So whatever solution we pick, there is a risk that existing code fails.
> 
> Yes. But I think if we create a new nodetype, at least it would be easier
> for users to understand the problem.
> 
> Also, the "upgrade path" with a new nodetype is smoother. This can be done
> incrementally, even thought it might mean more total work. But making
> nt:resource unreferenceable would be a hard break, and I think risk of
> bigger problems is higher.
> 
> Regards,
> Thomas
> 
> 
> 
> On 07/10/16 12:05, "Julian Reschke"  wrote:
> 
>> On 2016-10-07 10:56, Carsten Ziegeler wrote:
>>> Julian Reschke wrote
 On 2016-10-07 08:04, Carsten Ziegeler wrote:
> ...
> The easiest solution that comes to my mind is:
>
> Whenever a nt:resource child node of a nt:file node is created, it is
> silently changed to oak:resource.
>
> Carsten
> ...

 Observation: that might break code that actually wants a referenceable
 node: it would create the node, check for the presence of
 mix:referenceable, and then decide not to add it because it's already
 there.

>>>
>>> Well, there might be code that assumes that a file uploaded through
>>> webdav is using a resource child node that is referenceable.
>>> Or a file posted through the Sling POST servlet has this. Now, you could
>>> argue if that code did not create the file, it should check node types,
>>> but how likely is that if the code has history?
>>>
>>> So whatever solution we pick, there is a risk that existing code fails.
>>> ...
>>
>> That is true..
>>
>> However, my preference would be to only break code which is
>> non-conforming right now. Code should not rely on nt:resource being
>> referenceable (see
>> > ml#3.7.11.5%20nt:resource>).
>>
>> So my preference would be to make that change and see what breaks (and
>> get that fixed).
>>
>>> ...
>>
>>
>> Best regards, Julian
> 
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Possibility of making nt:resource unreferenceable

[Thomas Mueller]

Hi,

I agree with Julian, I think making nt:resource unreferenceable would
(hardcoding some "magic" in Oak) would lead to hard-to-find bugs and
problems.

> So whatever solution we pick, there is a risk that existing code fails.

Yes. But I think if we create a new nodetype, at least it would be easier
for users to understand the problem.

Also, the "upgrade path" with a new nodetype is smoother. This can be done
incrementally, even thought it might mean more total work. But making
nt:resource unreferenceable would be a hard break, and I think risk of
bigger problems is higher.

Regards,
Thomas



On 07/10/16 12:05, "Julian Reschke"  wrote:

>On 2016-10-07 10:56, Carsten Ziegeler wrote:
>> Julian Reschke wrote
>>> On 2016-10-07 08:04, Carsten Ziegeler wrote:
 ...
 The easiest solution that comes to my mind is:

 Whenever a nt:resource child node of a nt:file node is created, it is
 silently changed to oak:resource.

 Carsten
 ...
>>>
>>> Observation: that might break code that actually wants a referenceable
>>> node: it would create the node, check for the presence of
>>> mix:referenceable, and then decide not to add it because it's already
>>> there.
>>>
>>
>> Well, there might be code that assumes that a file uploaded through
>> webdav is using a resource child node that is referenceable.
>> Or a file posted through the Sling POST servlet has this. Now, you could
>> argue if that code did not create the file, it should check node types,
>> but how likely is that if the code has history?
>>
>> So whatever solution we pick, there is a risk that existing code fails.
>> ...
>
>That is true..
>
>However, my preference would be to only break code which is
>non-conforming right now. Code should not rely on nt:resource being
>referenceable (see
>ml#3.7.11.5%20nt:resource>).
>
>So my preference would be to make that change and see what breaks (and
>get that fixed).
>
> > ...
>
>
>Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.20

[Thomas Mueller]

[X] +1 Release this package as Apache Jackrabbit Oak 1.2.20

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.20

[Julian Reschke]

On 2016-10-12 07:36, Amit Jain wrote:

 ...


[X] +1 Release this package as Apache Jackrabbit Oak 1.2.20

Best regards, Julian