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

2017-02-24 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1458)

Status: Still Failing

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

Changes:
[mduerig] OAK-5542: Test failure: security.authentication.ldap.LdapProviderTest

[mduerig] OAK-5832: Make the LDAP server used in testing resilient against ports

[adulceanu] OAK-5753 - Consistency check incorrectly fails for broken partial 
paths

[angela] OAK-5793 : Improve coverage for security code in oak-core (wip) 
OAK-5836

[adulceanu] OAK-5600 - Test coverage for CheckCommand Created a more complex 
invalid

[mduerig] OAK-5357: StringUtils conversion functions can throw

[mduerig] OAK-4893: Document conflict handling

[adulceanu] OAK-5837 - Consistency check should log more details when 
traversing a

[angela] OAK-5793 : Improve coverage for security code in oak-core

 

Test results:
All tests passed

[Oak origin/1.0] Apache Jackrabbit Oak matrix - Build # 1457 - Still Failing

2017-02-24 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1457)

Status: Still Failing

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

Changes:
[mduerig] OAK-5542: Test failure: security.authentication.ldap.LdapProviderTest

[reschke] OAK-5751: RDBDocumentStore: properly handle null values for system

 

Test results:
8 tests failed.
FAILED:  
org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest.testAuthenticateValidateFalseFalse

Error Message:
Ignoring this test as the server port is already in use (OAK-5542): 
java.net.BindException: Address already in use

Stack Trace:
org.junit.AssumptionViolatedException: Ignoring this test as the server port is 
already in use (OAK-5542): java.net.BindException: Address already in use
at org.junit.Assume.assumeTrue(Assume.java:59)
at org.junit.Assume.assumeFalse(Assume.java:66)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.startLdapServer(AbstractServer.java:247)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.setUp(AbstractServer.java:231)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:33)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest.before(LdapProviderTest.java:85)
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.RunBefores.evaluate(RunBefores.java:24)
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.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
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)


FAILED:  
org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest.testAuthenticateValidateFalseFalse

Error Message:
null

Stack Trace:
java.lang.NullPointerException
at 
org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest.after(LdapProviderTest.java:96)
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

[Oak origin/1.2] Apache Jackrabbit Oak matrix - Build # 1456 - Still Failing

2017-02-24 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1456)

Status: Still Failing

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

Changes:
[mduerig] OAK-5542: Test failure: security.authentication.ldap.LdapProviderTest

[reschke] OAK-5751: RDBDocumentStore: properly handle null values for system

 

Test results:
3 tests failed.
FAILED:  
org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources

Error Message:
Service of type interface org.apache.jackrabbit.oak.spi.state.NodeStore was 
found. Expression: (sr == null). Values: sr = 
[org.apache.jackrabbit.oak.spi.state.NodeStore]

Stack Trace:
java.lang.AssertionError: Service of type interface 
org.apache.jackrabbit.oak.spi.state.NodeStore was found. Expression: (sr == 
null). Values: sr = [org.apache.jackrabbit.oak.spi.state.NodeStore]
at 
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:400)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:646)
at 
org.apache.jackrabbit.oak.run.osgi.AbstractRepositoryFactoryTest.assertNoService(AbstractRepositoryFactoryTest.groovy:89)
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.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:207)
at 
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:56)
at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
at 
org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources(DocumentNodeStoreConfigTest.groovy:96)
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.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
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

[Oak origin/1.4] Apache Jackrabbit Oak matrix - Build # 1455 - Still Failing

2017-02-24 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1455)

Status: Still Failing

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

Changes:
[mduerig] OAK-5542: Test failure: security.authentication.ldap.LdapProviderTest

 

Test results:
1 tests failed.
FAILED:  
org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources

Error Message:
Service of type interface org.apache.jackrabbit.oak.spi.state.NodeStore was 
found. Expression: (sr == null). Values: sr = 
[org.apache.jackrabbit.oak.spi.state.NodeStore, 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore, 
org.apache.jackrabbit.oak.spi.state.Clusterable]

Stack Trace:
java.lang.AssertionError: Service of type interface 
org.apache.jackrabbit.oak.spi.state.NodeStore was found. Expression: (sr == 
null). Values: sr = [org.apache.jackrabbit.oak.spi.state.NodeStore, 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore, 
org.apache.jackrabbit.oak.spi.state.Clusterable]
at 
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:400)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:646)
at 
org.apache.jackrabbit.oak.run.osgi.AbstractRepositoryFactoryTest.assertNoService(AbstractRepositoryFactoryTest.groovy:82)
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.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:207)
at 
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:56)
at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
at 
org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources(DocumentNodeStoreConfigTest.groovy:108)
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.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
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)

Re: Merging OAK-5784 into 1.6.1

2017-02-24 Thread Angela Schreiber 
Hi Chetan

Created OAK-5838  to keep
track of the topics discussed here.

Kind regards
Angela

On 24/02/17 11:56, "Chetan Mehrotra"  wrote:

>On Fri, Feb 24, 2017 at 4:10 PM, Angela Schreiber 
>wrote:
>> maybe this is
>> another indication that we should think about having an implementation
>> with plugins.memory and deal with the binary topic there.
>
>+1
>
>Then we can go with current fix (and also merge to 1.6) and later
>backport the change to 1.6 branch
>
>
>Chetan Mehrotra

Re: Merging OAK-5784 into 1.6.1

2017-02-24 Thread Chetan Mehrotra 
On Fri, Feb 24, 2017 at 4:10 PM, Angela Schreiber  wrote:
> maybe this is
> another indication that we should think about having an implementation
> with plugins.memory and deal with the binary topic there.

+1

Then we can go with current fix (and also merge to 1.6) and later
backport the change to 1.6 branch


Chetan Mehrotra

Re: Merging OAK-5784 into 1.6.1

2017-02-24 Thread Angela Schreiber 
Hi Chetan

Thanks a lot for your input!
In fact I looked at the PropertyStateValue implementation and spotted the
usage of the internal string representation. However, for the Restriction
case I could not come up with a use case that would involve a binary
value. The supported restrictions we are shipping are all of type STRING
or NAME. As far as custom implementations are concerned I doubt that
BINARY would make sense... but who knows... maybe it would be worth
explicitly stating in the documentation at
http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.ht
ml#pluggability that

a) performance must be taken into consideration when writing custom impls
b) the base impl of the Restriction interface relies on
PropertyStateValue.hashCode and custom implementations may need to adjust
that _if_ they contain binaries... ok... i don't think that would be
sensible... but who knows :-)

as far as PropertyState.hashCode is concerned: i vaguely remember that we
discussed that in the early days of Oak and decided that there is no need
for including the value because a given Tree object will never have
multiple properties with the same name and thus decided to just use the
name and type for performance reasons.

as far as PropertyStateValue is concerned: while working on the
improvement i struggled again with the fact that the implementation of
this oak-api interface is located in spi.query package that looks
pretty troublesome to me from a design point of view. maybe this is
another indication that we should think about having an implementation
with plugins.memory and deal with the binary topic there.

wdyt?
kind regards
angela

On 24/02/17 10:39, "Chetan Mehrotra"  wrote:

>Changes look fine however one aspect might cause issue
>
>RestrictionImpl#hashCode -> PropertyValues#hashCode ->
>PropertyStateValue#hashCode
>
>
>private String getInternalString() {
>StringBuilder sb = new StringBuilder();
>Iterator iterator = getValue(Type.STRINGS).iterator();
>while (iterator.hasNext()) {
>sb.append(iterator.next());
>if (iterator.hasNext()) {
>sb.append(",");
>}
>}
>return sb.toString();
>}
>
>@Override
>public int hashCode() {
>return getType().tag() ^ getInternalString().hashCode();
>}
>
>
>Here it tries to get value as STRINGS which leads to
>PropertyState#getValue(Type.STRINGS) which would lead to a Binary
>getting coerced to String in Conversions#convert(Blob) which would
>lead to load of whole binary. Now I am not sure if PropertyState in
>RestrictionImpl is applicable for Binary property also
>
>Probably PropertyStateValue#hashCode should take care of Binary
>properties and thats why PropertyState#hashCode does not take into
>account the value
>Chetan Mehrotra
>
>
>On Fri, Feb 24, 2017 at 2:34 PM, Angela Schreiber 
>wrote:
>> hi oak-devs
>>
>> i would like to merge another improvement into the 1.6.1 branch:
>> https://issues.apache.org/jira/browse/OAK-5784
>>
>> in addition to additional tests i run the AceCreationTest benchmark and
>> attached the results to the issue.
>> however, having some extra pair of eyes would be appreciated in order to
>> limit the risk of regressions.
>>
>> thanks
>> angela
>>
>>

Re: Supporting "resumable" operations on a large tree

2017-02-24 Thread Thomas Mueller 
Hi,

>So we can implement a "paginated tree traversal"

Yes, I thinks that's a first step, something for oak-core which can be
re-used in multiple places. It might make sense to also create a JCR
version, for other use cases.

Regards,
Thomas

Re: Merging OAK-5784 into 1.6.1

2017-02-24 Thread Chetan Mehrotra 
Changes look fine however one aspect might cause issue

RestrictionImpl#hashCode -> PropertyValues#hashCode ->
PropertyStateValue#hashCode


private String getInternalString() {
StringBuilder sb = new StringBuilder();
Iterator iterator = getValue(Type.STRINGS).iterator();
while (iterator.hasNext()) {
sb.append(iterator.next());
if (iterator.hasNext()) {
sb.append(",");
}
}
return sb.toString();
}

@Override
public int hashCode() {
return getType().tag() ^ getInternalString().hashCode();
}


Here it tries to get value as STRINGS which leads to
PropertyState#getValue(Type.STRINGS) which would lead to a Binary
getting coerced to String in Conversions#convert(Blob) which would
lead to load of whole binary. Now I am not sure if PropertyState in
RestrictionImpl is applicable for Binary property also

Probably PropertyStateValue#hashCode should take care of Binary
properties and thats why PropertyState#hashCode does not take into
account the value
Chetan Mehrotra


On Fri, Feb 24, 2017 at 2:34 PM, Angela Schreiber  wrote:
> hi oak-devs
>
> i would like to merge another improvement into the 1.6.1 branch:
> https://issues.apache.org/jira/browse/OAK-5784
>
> in addition to additional tests i run the AceCreationTest benchmark and
> attached the results to the issue.
> however, having some extra pair of eyes would be appreciated in order to
> limit the risk of regressions.
>
> thanks
> angela
>
>

Re: How can I start ?

2017-02-24 Thread Davide Giannella 
On 24/02/2017 09:23, Davide Giannella wrote:
> https://github.com/davidegiannella/adaptTo16 is what I presented at the
> last adaptTo conference.

Forgot to link the slides. They don't provide that much explanation as I
tend to present rather than write but they could help in focusing on
crucial part of the code.

https://adapt.to/2016/en/schedule/0-to-o-ak--in-30.html

Davide

Re: How can I start ?

2017-02-24 Thread Davide Giannella 
On 24/02/2017 03:04, Edward Pan wrote:
> Hello OAK development Team,
>
> I'm trying to use OAK to save document in local file system.
> I still get confused after read the all documents on
> https://jackrabbit.apache.org/oak/docs/index.html,
> Could you please give me some guide on it ?
>

Hello Edward,

I would say to read  the following for a quick start

http://jackrabbit.apache.org/oak/docs/use_getting_started.html
http://jackrabbit.apache.org/oak/docs/construct.html

That cover the repository construction and initialisation. For the usage
of CRUD operations you should leverage the JCR API

https://docs.adobe.com/docs/en/spec/javax.jcr/javadocs/jcr-2.0/index.html

Then we have some examples here and there.

https://github.com/davidegiannella/adaptTo16 is what I presented at the
last adaptTo conference. The aim was to have a very easy
set-up/repository construction for starting up Oak and save/read data.
If you find you need more in-line comments in the code just ask or even
better submit a PR.

Then we have more complete examples in
https://github.com/apache/jackrabbit-oak/tree/trunk/oak-examples.

HTH
Davide

Merging OAK-5784 into 1.6.1

2017-02-24 Thread Angela Schreiber 
hi oak-devs

i would like to merge another improvement into the 1.6.1 branch:
https://issues.apache.org/jira/browse/OAK-5784

in addition to additional tests i run the AceCreationTest benchmark and
attached the results to the issue.
however, having some extra pair of eyes would be appreciated in order to
limit the risk of regressions.

thanks
angela

Re: SHA-1 collision

2017-02-24 Thread Thomas Mueller 
Hi,

I created OAK-5827 to track this.

The problem is not just that there exist two files. I think it is a real
security vulnerability, because:

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.htm
l


"we will wait 90 days before releasing code that allows anyone to create a
pair of PDFs that hash to the same SHA-1 sum given two distinct images
with some pre-conditions."

Regards,
Thomas




On 24/02/17 08:12, "Thomas Mueller"  wrote:

>Hi,
>
>A SHA-1 collision has been published:
>https://www.schneier.com/blog/archives/2017/02/sha-1_collision.html
>https://security.googleblog.com/2017/02/announcing-first-sha1-collision.ht
>ml
>
>Our FileDataStore and S3DataStore use SHA-1. For new binaries, we should
>use (for example) SHA-256.
>
>Right now, a content management system that uses Oak as the repository
>can't serve those two files at the same time, if it uses the
>FileDataStore or the S3DataStore.
>
>(The FileBlobStore, MongoDB BlobStore,..., are not affected)
>
>Regards,
>Thomas
>
>
>

Re: Supporting "resumable" operations on a large tree

2017-02-24 Thread Chetan Mehrotra 
Hi Thomas,

On Fri, Feb 24, 2017 at 1:09 PM, Thomas Mueller  wrote:
> 9) Sorting of path is needed, so that the repository can be processed bit
> by bit by bit. For that, the following logic is used, recursively: read at
> most 1000 child nodes. If there are more than 1000, then this subtree is
> never split but processed in one step (so many child nodes can still lead
> to large transactions, unfortunately). If less than 1000 child nodes, then
> the names of all child nodes are read, and processed in sorted order
> (sorted by node name).

This should work! So we can implement a "paginated tree traversal" via
above approach and similar approach can be used for Lucene indexes.
Would be good to record this in OAK-2556 (or better a new issue) and
we can look into implementing it in those parts which do such large
transaction (reindex async index, reindex sync index, content
migration in sidegrade) etc

Chetan Mehrotra