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

2016-10-26 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1245)

Status: Still Failing

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

Changes:
[mreutegg] OAK-5012: SegmentDataStoreBlobGCIT times out on travis-ci

 

Test results:
13 tests failed.
FAILED:  org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop

Error Message:
expected: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { 
... }, root = { ... } }> but was: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }>

Stack Trace:
java.lang.AssertionError: expected: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }> but was: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ 
checkpoints = { ... }, root = { ... } }>
at 
org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)


FAILED:  
org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes

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

Stack Trace:
java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { } }>


FAILED:  
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at 
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
at 
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
at 
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit(SegmentDataStoreBlobGCIT.java:317)


FAILED:  
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckWithRenegadeDelete

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
at 
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
at 
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckWithRenegadeDelete(SegmentDataStoreBlobGCIT.java:340)


FAILED:  
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInlined

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:175)


FAILED:  
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.gcWithInlined

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space


FAILED:  org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.gc

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space


FAILED:  org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.noGc

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space


FAILED:  org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.checkMark

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space


FAILED:  
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.gcSpecialChar

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space


FAILED:  
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.gcLongRunningBlobCollection

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded


FAILED:  
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckWithGc

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded


FAILED:  org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop

Error Message:
expected: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { 
... }, root = { ... } }> but was: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }>

Stack Trace:
java.lang.AssertionError: expected: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }> but was: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ 
checkpoints = { ... }, root = { ... } }>
at 
org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)

Re: [ANNOUNCE] Plan for disruptive changes to Jackrabbit WebDAV library

2016-10-26 Thread Tobias Bocanegra 
Hi,

I also think we should expedite this, so we have a 3.x free version by the
end of this year. btw, are there any 3.x usages in Oak?

WDYT?

regards, toby

On Thu, Oct 27, 2016 at 3:08 AM, Julian Reschke 
wrote:

> On 2016-10-26 17:28, Roy T. Fielding wrote:
>
>> On Oct 26, 2016, at 6:13 AM, Julian Reschke  wrote:
>>>
>>> Hi there,
>>>
>>> context: 
>>>
>>> Summary: we want to get rid of our dependency of httpclient 3.* (<
>>> http://hc.apache.org/httpclient-3.x/>), which as been end-of-lifed
>>> quite some time ago.
>>>
>>> This will affect our public API, which extends classes from it.
>>>
>>> The current plan is to add a new set of APIs (probably based on
>>> HttpClient 4.5.x) in the next stable Jackrabbit release 2.14, planned to be
>>> released in Spring 2017. At that point, we'll also deprecate the old
>>> classes.
>>>
>>> Later on, we would *remove* the httpclient 3.x dependency and the old
>>> classes -- the plan would be to do that in the subsequent stable release:
>>> Jackrabbit 2.16, which could come out in Spring 2018.
>>>
>>> At that point, users of the old API can:
>>>
>>> - either continue using Jackrabbit 2.14.*, or
>>>
>>> - update their own code to work with Jackrabbit 2.16.*.
>>>
>>> Feedback appreciated -- either here, or in <
>>> https://issues.apache.org/jira/browse/JCR-2406>.
>>>
>>> Best regards, Julian
>>>
>>
>> That seems like an awful long time.  Assuming no one objects to the need
>> to update,
>> I suggest that the timeline should take care of itself.  IOW, if someone
>> commits an
>> updated API then it can be released "in the next release", after which
>> the old API
>> can be removed and 2.16.0 considered for the next release.
>>
>> That can all be done next week, if anyone gets excited. ;-)
>>
>> Roy
>>
>
> I'm all for speed.
>
> Just to be clear: 2.16 is the "next" release after 2.14 (we use odd
> numbers for the cuts from trunk as unstable releases).
>
> Best regards, Julian
>
>

Re: Pull request: multiplexing NodeStore

2016-10-26 Thread Robert Munteanu 
On Wed, 2016-10-05 at 12:13 +0300, Robert Munteanu wrote:
> 
> Created a sub-task for this
> 
>    OAK-4891 - Mount-time sanity checks for mounted NodeStore
> instances
>    https://issues.apache.org/jira/browse/OAK-4891

I've thought about this a little more. When mounting a NodeStore we are
working (unsurprisingly) at the NodeStore level, so we don't have any
concept of node types, versions, etc. So I can't use any of the logic
from oak-jcr, like the VersionManagerImpl.

The only way that I see right now is to use the NodeStore API and
'manually' perform the needed checks, e.g. look for nodes with a
property named 'jcr:mixinTypes' which has a 'mix:referenceable' value.

Is this approach a viable one? Also, is this done somewhere else in the
Oak codebase? I'd like to avoid duplication.

Thanks,

Robert

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

2016-10-26 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1244)

Status: Still Failing

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

Changes:
No changes
 

Test results:
3 tests failed.
FAILED:  org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop

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

Stack Trace:
java.lang.AssertionError: expected:<{ checkpoints = { ... }, root = { ... } }> 
but was:<{ root : { } }>
at 
org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)


FAILED:  
org.apache.jackrabbit.oak.jcr.query.QueryTest.nodeType[DocumentNodeStore[RDB] 
on jdbc:h2:file:./target/oaktest]

Error Message:
Unexpected plan: [oak:Unstructured] as [a] /* traverse "//*" where 
([a].[xyz/jcr:primaryType] is not null) and (isdescendantnode([a], [/])) */

Stack Trace:
java.lang.AssertionError: Unexpected plan: [oak:Unstructured] as [a] /* 
traverse "//*" where ([a].[xyz/jcr:primaryType] is not null) and 
(isdescendantnode([a], [/])) */
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.jackrabbit.oak.jcr.query.QueryTest.assertPlan(QueryTest.java:845)
at 
org.apache.jackrabbit.oak.jcr.query.QueryTest.nodeType(QueryTest.java:839)
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.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.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop

Error Message:
expected: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { 
... }, root = { ... } }> but was: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }>

Stack Trace:
java.lang.AssertionError: expected: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }> but was: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ 
checkpoints = { ... }, root = { ... } }>
at 
org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)

Document valid chars in Oak JCR names

2016-10-26 Thread Alexander Klimetschek 
Could we document the allowed characters in Oak JCR names and provide a common 
escaping/unescaping utility? See my comment in [1] for a start. Happy to help, 
but I need some Oak experts to ensure this is sound.

(This is a follow up of the "Support space chars common in CJK inside node 
names" thread.)

[1] 
https://issues.apache.org/jira/browse/OAK-4857?focusedCommentId=15609437=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15609437

Cheers,
Alex

Re: segment-tar depending on oak-core

2016-10-26 Thread Alexander Klimetschek 
FWIW, I would prefer oak to have better modularization.

It also overlaps with Michael Marth's other recent thread "On adding new APIs" 
- the exported APIs in Oak are all ad hoc because of it's monolithic design 
(i.e. all in oak-core) and no clear API packages designed upfront. Someone had 
to figure out what packages need to exported after the fact, and a lot of 
things are exported that should really not be, and because of that, you have to 
update a lot more oak code when something changes in these, because it 
inadvertently depends on these exported classes, although it doesn't use them.

Building a patch for Oak to try something out as an outside is very difficult, 
as things aren't well modularized. I was recently involved with 
oak-auth-external, and you can only really work on it if you always rebuild and 
redeploy the whole of oak. It's pretty painful… builds are also slow, as 
because of the snapshot dependencies you have to build everything which takes a 
lot of time with all the tests. With released dependencies between the modules, 
one could work on a higher level module without worrying about the lower layer, 
as it stays in the same released version. I would argue you might get more 
contributions if things were easier on this front.

Releasing modularized stuff can be easier: if there is only a change in one 
module, you only have to release one, instead of all of them. Faster 
turnaround. A

Just my 2 cents,
Alex

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

2016-10-26 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1243)

Status: Still Failing

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

Changes:
[alexparvulescu] OAK-4956 SegmentGCOptions retainedGenerations setting not 
exposed via

[alexparvulescu] OAK-5008 SegmentRevisionGCMBean getLastRepositorySize wrong 
value

[frm] OAK-5007 - Put oak-segment-tar back in the main release cycle

[frm] OAK-5007 - Adjust dependencies on Oak and on external modules

[alexparvulescu] OAK-4944 Enable RefreshOnGCTest segment-tar fixture

[reschke] OAK-5009: ignore failing tests

[mduerig] OAK-5004: Offline compaction explodes checkpoints Switch offline

[mduerig] OAK-4941: Provide status for gc process

[mreutegg] OAK-5010: Document split with binary properties too eager

 

Test results:
1 tests failed.
FAILED:  
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded

[jira] [Commented] (JCR-4044) Support glob patterns through JackrabbitEventFilter

2016-10-26 Thread Stefan Egli (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCR-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15609062#comment-15609062
 ] 

Stefan Egli commented on JCR-4044:
--

Note that the API suggested in this patch is outdated and we should rather do 
it based on OAK-5013

> Support glob patterns through JackrabbitEventFilter
> ---
>
> Key: JCR-4044
> URL: https://issues.apache.org/jira/browse/JCR-4044
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: core
>Reporter: Carsten Ziegeler
> Attachments: JCR-4044.patch, JCR-4044.v2.patch
>
>
> In the Sling project, we would like to register JCR listeners based on glob 
> patterns as defined in
> https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html
> So basically instead (or in addition) to specifying an absolute path, 
> defining patterns.
> [Discussion 
> thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4046) Improve observation of files

2016-10-26 Thread Stefan Egli (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCR-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15609063#comment-15609063
 ] 

Stefan Egli commented on JCR-4046:
--

Note that the API suggested in this patch is outdated and we should rather do 
it based on OAK-5013

> Improve observation of files
> 
>
> Key: JCR-4046
> URL: https://issues.apache.org/jira/browse/JCR-4046
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: core
>Reporter: Carsten Ziegeler
> Attachments: JCR-4046.patch, JCR-4046.v2.patch
>
>
> A file in JCR is represented by at least two nodes, the nt:file node and a 
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change 
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as 
> you can't use the file name to filter  - especially with glob patterns (see 
> JCR-4044) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to 
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable 
> smarter reporting just for nt:files: if a property on jcr:content is changed, 
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [REVIEW][API] Additions to JackrabbitEventFilter

2016-10-26 Thread Michael Dürig 



On 26.10.16 4:13 , Stefan Egli wrote:

In JCR-4046 I've now added another example for doing a new event feature
in oak-jcr (this time for subtree aggregation).


Explicitly not commenting on this (also not implying anything). Just 
limited bandwidth on my side.




Wdyt? Should we move forward with suggested EventFilterBuilder approach
and skip adding these 5 features to the JackrabbitEventFilter?


+1, I like that approach. Just ensure we expose the required 
functionality on the Oak side as a proper API. That is, interface and 
utility only and proper package versioning.


Michael

[jira] [Commented] (JCR-4037) add includeSubtreeOnDelete flag to JackrabbitEventFilter

2016-10-26 Thread Julian Reschke (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCR-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608624#comment-15608624
 ] 

Julian Reschke commented on JCR-4037:
-

Right.

> add includeSubtreeOnDelete flag to JackrabbitEventFilter
> 
>
> Key: JCR-4037
> URL: https://issues.apache.org/jira/browse/JCR-4037
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: observation
>Affects Versions: 2.13.3
>Reporter: Stefan Egli
> Attachments: JCR-4037.patch
>
>
> In some cases of observation it would be useful to receive events of child 
> node or properties of a parent/grandparent that was deleted. Currently (in 
> Oak at least) one only receives a deleted event for the node that was deleted 
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the 
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnDelete;
> {code}
> (Open for any better name of course)
> /cc [~mduerig], [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCRVLT-111) Add support for o.a.j.api.security.authorization.PrincipalSetPolicy

2016-10-26 Thread Tobias Bocanegra (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCRVLT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608567#comment-15608567
 ] 

Tobias Bocanegra commented on JCRVLT-111:
-

basically create a test package that contains the new content and put it here:
   
https://github.com/apache/jackrabbit-filevault/tree/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages

and then add a test that installs the package, and maybe checks if the imported 
content is correct here:
  
https://github.com/apache/jackrabbit-filevault/tree/trunk/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration


> Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
> ---
>
> Key: JCRVLT-111
> URL: https://issues.apache.org/jira/browse/JCRVLT-111
> Project: Jackrabbit FileVault
>  Issue Type: New Feature
>Reporter: angela
>Assignee: Tobias Bocanegra
> Fix For: 3.1.30
>
> Attachments: JCRVLT-111.patch
>
>
> jackrabbit API has been extended by an additional type of access control 
> policy, which isn't an ACL. fvault should be adjusted to be able to properly 
> import that type of access control policy.
> as discussed: ac-handling {{MERGE}} and {{MERGE_PRESERVE}} should be 
> implemented the same way and just add extra principal names that are not yet 
> present in the set.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [REVIEW][API] Additions to JackrabbitEventFilter

2016-10-26 Thread Stefan Egli 
(+gentle bump ;)

In JCR-4046 I've now added another example for doing a new event feature
in oak-jcr (this time for subtree aggregation).

Wdyt? Should we move forward with suggested EventFilterBuilder approach
and skip adding these 5 features to the JackrabbitEventFilter?

Cheers,
Stefan

On 25/10/16 16:15, "Stefan Egli"  wrote:

>On 24/10/16 22:27, "Michael Dürig"  wrote:
>
>>A related question is how we retrofit this to Jackrabbit 2. How do users
>>know (and find out) which of these features is supported or not.
>
>We discussed this offline: what we could do instead of extending the
>JackrabbitEventFilter is to introduce a oak-core utility eg
>EventFilterBuilder that would take a JackrabbitEventFilter and return a
>'modified' filter that contains the extended filter functionality. That
>way it would be clear that it's only supported by oak-core. And it would
>remove the necessity to extend JackrabbitEventFilter in the first place.
>
>Added a sketch of how this could look to [0].
>
>Wdyt?
>
>Cheers,
>Stefan
>--
>[0] - 
>https://issues.apache.org/jira/browse/JCR-4044?focusedCommentId=15605418
>a
>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
>t
>-15605418
>
>

[jira] [Updated] (JCR-4046) Improve observation of files

2016-10-26 Thread Stefan Egli (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCR-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated JCR-4046:
-
Attachment: JCR-4046.v2.patch

bq. What's perhaps less straight-forward is to have an event be reported on 
another path than where it happend - aka 'moving an event'. That would have to 
be explicit, additional code that the filters can't handle.
I've spawned this 'move' aka 'aggregation' part into OAK-5011 and added a patch 
suggesting how this could be achieved.

Based on OAK-5011 we could then, similarly as suggested in JCR-4044, implement 
this aggregation feature request in the oak-jcr level, independent of 
jackrabbit: attached [^JCR-4046.v2.patch] which illustrates this (this is based 
on the patch attached to OAK-5011)

> Improve observation of files
> 
>
> Key: JCR-4046
> URL: https://issues.apache.org/jira/browse/JCR-4046
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: core
>Reporter: Carsten Ziegeler
> Attachments: JCR-4046.patch, JCR-4046.v2.patch
>
>
> A file in JCR is represented by at least two nodes, the nt:file node and a 
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change 
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as 
> you can't use the file name to filter  - especially with glob patterns (see 
> JCR-4044) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to 
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable 
> smarter reporting just for nt:files: if a property on jcr:content is changed, 
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4037) add includeSubtreeOnDelete flag to JackrabbitEventFilter

2016-10-26 Thread Stefan Egli (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCR-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608560#comment-15608560
 ] 

Stefan Egli commented on JCR-4037:
--

As [suggested on the list|http://markmail.org/message/cp6rgejxqtnmqldv] I'd 
propose to not do this feature in jackrabbit but in oak-jcr. At which point I 
assume your concern is no longer relevant. Wdyt?

> add includeSubtreeOnDelete flag to JackrabbitEventFilter
> 
>
> Key: JCR-4037
> URL: https://issues.apache.org/jira/browse/JCR-4037
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: observation
>Affects Versions: 2.13.3
>Reporter: Stefan Egli
> Attachments: JCR-4037.patch
>
>
> In some cases of observation it would be useful to receive events of child 
> node or properties of a parent/grandparent that was deleted. Currently (in 
> Oak at least) one only receives a deleted event for the node that was deleted 
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the 
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnDelete;
> {code}
> (Open for any better name of course)
> /cc [~mduerig], [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCRVLT-111) Add support for o.a.j.api.security.authorization.PrincipalSetPolicy

2016-10-26 Thread angela (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCRVLT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608278#comment-15608278
 ] 

angela commented on JCRVLT-111:
---

sure... to be honest, I originally planned to provide tests with decent 
coverage but I found myself struggling with the tests present and feared that i 
would spend way to much time on this. if you can provide me with some 
instructions or explanation on how test-coverage in jackrabbit filevault is 
organized I will be happy to provide tests.

> Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
> ---
>
> Key: JCRVLT-111
> URL: https://issues.apache.org/jira/browse/JCRVLT-111
> Project: Jackrabbit FileVault
>  Issue Type: New Feature
>Reporter: angela
>Assignee: Tobias Bocanegra
> Fix For: 3.1.30
>
> Attachments: JCRVLT-111.patch
>
>
> jackrabbit API has been extended by an additional type of access control 
> policy, which isn't an ACL. fvault should be adjusted to be able to properly 
> import that type of access control policy.
> as discussed: ac-handling {{MERGE}} and {{MERGE_PRESERVE}} should be 
> implemented the same way and just add extra principal names that are not yet 
> present in the set.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1242 - Failure

2016-10-26 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1242)

Status: Failure

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

Changes:
[chetanm] OAK-4862 - Provide a MemoryNodeStoreService

[mreutegg] OAK-4993: Report plan when QueryTest.nodeType() fails

[mreutegg] OAK-4984: Server time unavailable with authenticated connection to

[mreutegg] OAK-4870: Implement caching for S3DataStore

[mreutegg] OAK-4995: DocumentS3DataStoreStatsTest.testNoS3BlobStore() does not

[amitj] OAK-4996: Open up getBlobStore() to protected access in

[amitj] OAK-4868: Update SegmentS3DataStoreBlobGCTest in oak-it once

[reschke] OAK-4997: RevisionGCTest.teardown() may fail with NPE when store == 
null

[tomekr] OAK-4983: Add --verify mode to the RepositorySidegrade

[reschke] OAK-4980: remove JournalGCIT - not needed anymore

[mduerig] OAK-4998: NPE when starting Oak Console OAK-4999: ISE when starting 
Oak

[mduerig] OAK-4999: ISE when starting Oak Console

[reschke] OAK-4870: removed surplus semicolon causing Eclipse compilation 
failure

[mduerig] OAK-5002: NPE when creating read only store @Ignored test case

[chetanm] OAK-4710 - AsyncIndexUpdate delay time should show clock time left

[chetanm] OAK-4992 - Use the role name as prefix for directory used by

[mduerig] OAK-5002: NPE when creating read only store Introduce a segment writer

[mduerig] OAK-4998: NPE when starting Oak Console Align test expectations with 
fix

[reschke] OAK-4986: RDBDocumentStore: potential NPE in document read

[mduerig] OAK-5003: no output from oak-run check Add missing logger 
configuration

[amitj] OAK-4627: [BlobGC] Reduce logging during delete

[amitj] OAK-5005: S3 async upload fails to catch and log exceptions other than

 

Test results:
2 tests failed.
FAILED:  org.apache.jackrabbit.j2ee.TomcatIT.testTomcat

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 junit.framework.TestCase.assertEquals(TestCase.java:269)
at org.apache.jackrabbit.j2ee.TomcatIT.testTomcat(TomcatIT.java:103)
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 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 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: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.plugins.segment.standby.ExternalPrivateStoreIT.testProxyFlippedIntermediateByteChange

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

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

2016-10-26 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1240)

Status: Still Failing

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

Changes:
[reschke] OAK-4997: RevisionGCTest.teardown() may fail with NPE when store == 
null

[reschke] OAK-4986: RDBDocumentStore: potential NPE in document read (ported to

 

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: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.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)


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