Re: New Jackrabbit Committer: Andrei Dulceanu

[Chetan Mehrotra]

Welcome, Andrei!

Chetan Mehrotra

Re: Mandatory property jcr:predecessors not found in a new node

[Chetan Mehrotra]

Hi Mathias,

On Tue, Dec 20, 2016 at 1:31 AM, mathiasconradt
 wrote:
> However, the problem DOES NOT occur when I don't use the default repo
> configuration but get the session from my own repository configuration

Thanks for digging into this. I have opened OAK-5349 for this. Can you
try with current trunk and let us know if it works for you?

Chetan Mehrotra

Re: Mandatory property jcr:predecessors not found in a new node

[mathiasconradt]

(Sorry for the many mails on this.)

After I added the mix:versionable as described in my previous posting, with
saving the session in between, I am not able to retrieve the history of it,
as I am getting an error as follows:

org.springframework.web.util.NestedServletException: Request processing
failed; nested exception is java.lang.IllegalStateException: Base version
does not exist for /documents/versiontest17.jpg


This is what my node looks like after I created it and added the mixin:

{
  "jcr:created": "Mon Dec 19 2016 20:02:43 GMT+0100",
  "jcr:isCheckedOut": true,
  "jcr:mixinTypes": [
"mix:referenceable",
"mix:versionable"
  ],
  "jcr:createdBy": "admin",
  "jcr:uuid": "6481825f-09f0-4639-b166-7bd450cfa836",
  "jcr:primaryType": "nt:file",
  "jcr:content": {
"jcr:lastModifiedBy": "admin",
":jcr:data": 3,
"jcr:lastModified": "Mon Dec 19 2016 20:02:43 GMT+0100",
"jcr:uuid": "dd466d5c-0cf8-41da-a86a-c2e7bc3efadd",
"jcr:primaryType": "nt:resource"
  }
}


>From my understanding, the baseVersion should be automatically initialized
when the node is made versionable?!

https://docs.adobe.com/content/docs/en/spec/jcr/2.0/15_Versioning.html

"Additionally, under full versioning: The REFERENCE property jcr:baseVersion
of N is initialized to the identifier of V0. This constitutes a reference
from N to its current base version."




mathiasconradt wrote
> I just noticed, I can add the mix:versionable when I save the session in
> between creating the new node and adding the mixin.
> Not sure if this is supposed to work like this and mandatory to save the
> session first or not.
> 
> So this works:
> 
> Node fileNode = folderNode.addNode(filename, "nt:file");
> session.save();
> fileNode.addMixin("mix:versionable");
> session.save();
> 
> - Mathias
> 
> mathiasconradt wrote
>> I am getting the same error message with the current trunk as of today.
>> Created a new node and added the "mix:versionable" mixable. 
>> 
>> fileNode = folderNode.addNode(filename, "nt:file");
>> if (fileNode.canAddMixin("mix:referenceable"))
>> fileNode.addMixin("mix:referenceable");
>> if (fileNode.canAddMixin("mix:versionable"))
>> fileNode.addMixin("mix:versionable");
>> // if (fileNode.canAddMixin("mix:simpleVersionable"))
>> fileNode.addMixin("mix:simpleVersionable");
>> 
>> Error:
>> 
>> org.springframework.web.util.NestedServletException: Request processing
>> failed; nested exception is
>> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0021:
>> /documents/versiontest3.jpg[[nt:file, mix:referenceable,
>> mix:versionable]]: Mandatory property jcr:predecessors not found in a new
>> node
>> 
>> 
>> (However, I don't get the message if I add the "mix:simpleVersionable"
>> instead, which makes sense though since it does not seem to be
>> implemented according to https://issues.apache.org/jira/browse/OAK-4166:
>> "As a result, versioning-related methods invoked on such
>> [simpleVersionable] nodes doesn't work correctly.)
>> 
>> I looked up the definition:
>> 
>> https://docs.adobe.com/content/docs/en/spec/jcr/2.0/15_Versioning.html
>> 
>> "Under both simple and full versioning, on persist of a new versionable
>> node N that neither corresponds nor shares with an existing node:
>> 
>> Additionally, under full versioning:
>> 
>> The multi-value REFERENCE property jcr:predecessors of N is initialized
>> to contain a single identifier, that of V0 (the same as
>> jcr:baseVersion)."
>> 
>> Now I am wondering, should all this (initialization of the
>> jcr:predecessors property) not be handled by the repository automatically
>> in both cases, since it knows whether this is a new node etc.? Is it a
>> bug?
>> 
>> I found Jira tickets related to versioning, but they are already three
>> years old and set to resolved.
>> 
>> https://issues.apache.org/jira/browse/OAK-815
>> https://issues.apache.org/jira/browse/OAK-1118
>> 
>> Regards,
>> Mathias
>> 
>> smg11 wrote
>>> Hi While accessing Jackrabbit oak through deployed Jackrabbit oak
>>> web-app using rmi, I am getting following error while check in the node
>>> to repository.
>>> 
>>> Stack trace: 
>>> Exception in thread "main"
>>> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0021:
>>> /testNode_1462713844833[[nt:unstructured, mix:versionable]]: Mandatory
>>> property jcr:predecessors not found in a new node
>>> at
>>> org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:109)
>>> at
>>> org.apache.jackrabbit.rmi.server.ServerSession.save(ServerSession.java:265)
>>> 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
>>> at 

Re: Mandatory property jcr:predecessors not found in a new node

[mathiasconradt]

After doing some further debugging, I found something interesting. But since
I'm new to Oak and just getting started, I don't know what to make of it
yet.

The initial problem

org.springframework.web.util.NestedServletException: Request processing
failed; nested exception is javax.jcr.nodetype.ConstraintViolationException:
OakConstraint0021: /documents/versiontest41.jpg[[nt:file, mix:referenceable,
mix:versionable]]: Mandatory property jcr:predecessors not found in a new
node

ONLY occurs when I use the default repository as it is configured in the
oak-standalone app
(https://github.com/apache/jackrabbit-oak/tree/trunk/oak-examples/standalone).
This is interesting, because the OP of this thread also referred to the
oak-examples webapp (I'm using the standalone app, but still...).

However, the problem DOES NOT occur when I don't use the default repo
configuration but get the session from my own repository configuration (but
using the same code/method for creating the node and adding the mixin).


// 1. get the session from the default repository configured in
Oak-Standalone by default (but with --mongo) => versionable mixin does not
work
private Session getRepositorySession1() throws Exception {
Session session = repository.login(new SimpleCredentials("admin",
"admin".toCharArray()), "default");
return session;
}

// 2. get the session from my hardcoded configuration, which is as below
in the method. => versionable mixin works fine
private Session getRepositorySession2() throws Exception {
Repository repo;
DocumentNodeStore nodeStore;
DB db;
db = new MongoClient("localhost", 27017).getDB("test5");
nodeStore = new DocumentMK.Builder().setMongoDB(db).getNodeStore();
repo = new Jcr(nodeStore).withAsyncIndexing().createRepository();
Session session = repo.login(new SimpleCredentials("admin",
"admin".toCharArray()), "default");
return session;
}

Regards,
Mathias



--
View this message in context: 
http://jackrabbit.510166.n4.nabble.com/Mandatory-property-jcr-predecessors-not-found-in-a-new-node-tp4664014p4665905.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

Re: Mandatory property jcr:predecessors not found in a new node

[mathiasconradt]

I just noticed, I can add the mix:versionable when I save the session in
between creating the new node and adding the mixin.
Not sure if this is supposed to work like this and mandatory to save the
session first or not.

So this works:

Node fileNode = folderNode.addNode(filename, "nt:file");
session.save();
fileNode.addMixin("mix:versionable");
session.save();

- Mathias



mathiasconradt wrote
> I am getting the same error message with the current trunk as of today.
> Created a new node and added the "mix:versionable" mixable. 
> 
> fileNode = folderNode.addNode(filename, "nt:file");
> if (fileNode.canAddMixin("mix:referenceable"))
> fileNode.addMixin("mix:referenceable");
> if (fileNode.canAddMixin("mix:versionable"))
> fileNode.addMixin("mix:versionable");
> // if (fileNode.canAddMixin("mix:simpleVersionable"))
> fileNode.addMixin("mix:simpleVersionable");
> 
> Error:
> 
> org.springframework.web.util.NestedServletException: Request processing
> failed; nested exception is
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0021:
> /documents/versiontest3.jpg[[nt:file, mix:referenceable,
> mix:versionable]]: Mandatory property jcr:predecessors not found in a new
> node
> 
> 
> (However, I don't get the message if I add the "mix:simpleVersionable"
> instead, which makes sense though since it does not seem to be implemented
> according to https://issues.apache.org/jira/browse/OAK-4166: "As a result,
> versioning-related methods invoked on such [simpleVersionable] nodes
> doesn't work correctly.)
> 
> I looked up the definition:
> 
> https://docs.adobe.com/content/docs/en/spec/jcr/2.0/15_Versioning.html
> 
> "Under both simple and full versioning, on persist of a new versionable
> node N that neither corresponds nor shares with an existing node:
> 
> Additionally, under full versioning:
> 
> The multi-value REFERENCE property jcr:predecessors of N is initialized to
> contain a single identifier, that of V0 (the same as jcr:baseVersion)."
> 
> Now I am wondering, should all this (initialization of the
> jcr:predecessors property) not be handled by the repository automatically
> in both cases, since it knows whether this is a new node etc.? Is it a
> bug?
> 
> I found Jira tickets related to versioning, but they are already three
> years old and set to resolved.
> 
> https://issues.apache.org/jira/browse/OAK-815
> https://issues.apache.org/jira/browse/OAK-1118
> 
> Regards,
> Mathias
> 
> smg11 wrote
>> Hi While accessing Jackrabbit oak through deployed Jackrabbit oak web-app
>> using rmi, I am getting following error while check in the node to
>> repository.
>> 
>> Stack trace: 
>> Exception in thread "main"
>> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0021:
>> /testNode_1462713844833[[nt:unstructured, mix:versionable]]: Mandatory
>> property jcr:predecessors not found in a new node
>>  at
>> org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:109)
>>  at
>> org.apache.jackrabbit.rmi.server.ServerSession.save(ServerSession.java:265)
>>  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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
>>  at sun.rmi.transport.Transport$1.run(Transport.java:200)
>>  at sun.rmi.transport.Transport$1.run(Transport.java:197)
>>  at java.security.AccessController.doPrivileged(Native Method)
>>  at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>  at
>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
>>  at
>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
>>  at
>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
>>  at java.security.AccessController.doPrivileged(Native Method)
>>  at
>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
>>  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)
>>  at
>> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276)
>>  at
>> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:253)
>>  at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162)
>>  at org.apache.jackrabbit.rmi.server.ServerSession_Stub.save(Unknown
>> Source)
>>  at
>> org.apache.jackrabbit.rmi.client.ClientSession.save(ClientSession.java:272)
>>  at TestJCRVersionable.main(TestJCRVersionable.java:23)
>> 
>> 
>> 
>> Code snippet:
>> 
>> public class 

Re: Mandatory property jcr:predecessors not found in a new node

[mathiasconradt]

I am getting the same error message with the current trunk as of today.
Created a new node and added the "mix:versionable" mixable. 

fileNode = folderNode.addNode(filename, "nt:file");
if (fileNode.canAddMixin("mix:referenceable"))
fileNode.addMixin("mix:referenceable");
if (fileNode.canAddMixin("mix:versionable"))
fileNode.addMixin("mix:versionable");
// if (fileNode.canAddMixin("mix:simpleVersionable"))
fileNode.addMixin("mix:simpleVersionable");

Error:

org.springframework.web.util.NestedServletException: Request processing
failed; nested exception is javax.jcr.nodetype.ConstraintViolationException:
OakConstraint0021: /documents/versiontest3.jpg[[nt:file, mix:referenceable,
mix:versionable]]: Mandatory property jcr:predecessors not found in a new
node


(However, I don't get the message if I add the "mix:simpleVersionable"
instead, which makes sense though since it does not seem to be implemented
according to https://issues.apache.org/jira/browse/OAK-4166: "As a result,
versioning-related methods invoked on such [simpleVersionable] nodes doesn't
work correctly.)

I looked up the definition:

https://docs.adobe.com/content/docs/en/spec/jcr/2.0/15_Versioning.html

"Under both simple and full versioning, on persist of a new versionable node
N that neither corresponds nor shares with an existing node:

Additionally, under full versioning:

The multi-value REFERENCE property jcr:predecessors of N is initialized to
contain a single identifier, that of V0 (the same as jcr:baseVersion)."

Now I am wondering, should all this (initialization of the jcr:predecessors
property) not be handled by the repository automatically in both cases,
since it knows whether this is a new node etc.? Is it a bug?

I found Jira tickets related to versioning, but they are already three years
old and set to resolved.

https://issues.apache.org/jira/browse/OAK-815
https://issues.apache.org/jira/browse/OAK-1118

Regards,
Mathias



smg11 wrote
> Hi While accessing Jackrabbit oak through deployed Jackrabbit oak web-app
> using rmi, I am getting following error while check in the node to
> repository.
> 
> Stack trace: 
> Exception in thread "main"
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0021:
> /testNode_1462713844833[[nt:unstructured, mix:versionable]]: Mandatory
> property jcr:predecessors not found in a new node
>   at
> org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:109)
>   at
> org.apache.jackrabbit.rmi.server.ServerSession.save(ServerSession.java:265)
>   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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
>   at sun.rmi.transport.Transport$1.run(Transport.java:200)
>   at sun.rmi.transport.Transport$1.run(Transport.java:197)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>   at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
>   at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
>   at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
>   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)
>   at
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276)
>   at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:253)
>   at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162)
>   at org.apache.jackrabbit.rmi.server.ServerSession_Stub.save(Unknown
> Source)
>   at
> org.apache.jackrabbit.rmi.client.ClientSession.save(ClientSession.java:272)
>   at TestJCRVersionable.main(TestJCRVersionable.java:23)
> 
> 
> 
> Code snippet:
> 
> public class TestJCRVersionable {
> 
>   public static void main(String[] args) throws Exception {
>   Repository repository = new
> URLRemoteRepository("http://localhost:8080/oak/rmi;);
>   Session session = repository.login(new 
> SimpleCredentials("admin",
> "admin".toCharArray()));
>   
>   Node root = session.getRootNode(); 
>   long id=System.currentTimeMillis();
> 
>//create versionable node
> Node n = root.addNode("testNode_" + id, "nt:unstructured");
> 

Re: svn commit: r1775152 - in /jackrabbit/oak/trunk/oak-auth-ldap: pom.xml src/main/java/org/apache/jackrabbit/oak/security/authentication/ldap/impl/LdapIdentityProvider.java

[Amit Jain]

There are lot of test failures because of this commit (reproducible on
local as well)
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1337/

On Mon, Dec 19, 2016 at 11:57 PM,  wrote:

> Author: baedke
> Date: Mon Dec 19 18:27:45 2016
> New Revision: 1775152
>
> URL: http://svn.apache.org/viewvc?rev=1775152=rev
> Log:
> OAK-5336: Update milestone dependency to org.apache.directory.api.api-all
>
> Updated to apache.directory.api.api-all-1.0.0-RC2.
>
> Modified:
> jackrabbit/oak/trunk/oak-auth-ldap/pom.xml
> jackrabbit/oak/trunk/oak-auth-ldap/src/main/java/org/apache/
> jackrabbit/oak/security/authentication/ldap/impl/LdapIdentityProvider.java
>
> Modified: jackrabbit/oak/trunk/oak-auth-ldap/pom.xml
> URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-auth-
> ldap/pom.xml?rev=1775152=1775151=1775152=diff
> 
> ==
> --- jackrabbit/oak/trunk/oak-auth-ldap/pom.xml (original)
> +++ jackrabbit/oak/trunk/oak-auth-ldap/pom.xml Mon Dec 19 18:27:45 2016
> @@ -137,7 +137,7 @@
>  
>  org.apache.directory.api
>  api-all
> -1.0.0-M30
> +1.0.0-RC2
>  provided
>  
>  
>
> Modified: jackrabbit/oak/trunk/oak-auth-ldap/src/main/java/org/apache/
> jackrabbit/oak/security/authentication/ldap/impl/LdapIdentityProvider.java
> URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-auth-
> ldap/src/main/java/org/apache/jackrabbit/oak/security/
> authentication/ldap/impl/LdapIdentityProvider.java?rev=
> 1775152=1775151=1775152=diff
> 
> ==
> --- jackrabbit/oak/trunk/oak-auth-ldap/src/main/java/org/apache/
> jackrabbit/oak/security/authentication/ldap/impl/LdapIdentityProvider.java
> (original)
> +++ jackrabbit/oak/trunk/oak-auth-ldap/src/main/java/org/apache/
> jackrabbit/oak/security/authentication/ldap/impl/LdapIdentityProvider.java
> Mon Dec 19 18:27:45 2016
> @@ -16,6 +16,7 @@
>   */
>  package org.apache.jackrabbit.oak.security.authentication.ldap.impl;
>
> +import java.io.IOException;
>  import java.security.NoSuchAlgorithmException;
>  import java.util.ArrayList;
>  import java.util.Arrays;
> @@ -439,7 +440,11 @@ public class LdapIdentityProvider implem
>  throw new ExternalIdentityException("Error during ldap
> membership search.", e);
>  } finally {
>  if (searchCursor != null) {
> -searchCursor.close();
> +try {
> +searchCursor.close();
> +} catch (IOException e) {
> +log.warn("Failed to close search cursor.", e);
> +}
>  }
>  disconnect(connection);
>  }
> @@ -606,7 +611,11 @@ public class LdapIdentityProvider implem
>  }
>  } finally {
>  if (searchCursor != null) {
> -searchCursor.close();
> +try {
> +searchCursor.close();
> +} catch (IOException e) {
> +log.warn("Failed to close search cursor.", e);
> +}
>  }
>  }
>  if (log.isDebugEnabled()) {
> @@ -755,7 +764,11 @@ public class LdapIdentityProvider implem
>  return !page.isEmpty();
>  } finally {
>  if (searchCursor != null) {
> -searchCursor.close();
> +try {
> +searchCursor.close();
> +} catch (IOException e) {
> +log.warn("Failed to close search cursor.", e);
> +}
>  }
>  disconnect(connection);
>  }
>
>
>

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

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[tomekr] @trivial updated javadoc syntax in oak-upgrade

 

Test results:
7 tests failed.
FAILED:  
org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes

Error Message:
proxy not started

Stack Trace:
java.lang.Exception: proxy not started
at 
org.apache.jackrabbit.oak.plugins.segment.NetworkErrorProxy.reset(NetworkErrorProxy.java:87)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:216)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxySkippedBytes(DataStoreTestBase.java:159)
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.plugins.segment.standby.ExternalSharedStoreIT.testProxyFlippedIntermediateByteChange2

Error Message:
proxy not started

Stack Trace:
java.lang.Exception: proxy not started
at 
org.apache.jackrabbit.oak.plugins.segment.NetworkErrorProxy.reset(NetworkErrorProxy.java:87)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:216)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxyFlippedIntermediateByteChange2(DataStoreTestBase.java:189)
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 

Jackrabbit-trunk - Build # 2436 - Unstable

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit-trunk (build #2436)

Status: Unstable

Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2436/ to 
view the results.

[jira] [Updated] (JCR-4090) Fix Javadoc for JDK 1.8 doctool compliance

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4090:

Attachment: errors.txt

1525 errors after fixing invalid self-closing tags

> Fix Javadoc for JDK 1.8 doctool compliance
> --
>
> Key: JCR-4090
> URL: https://issues.apache.org/jira/browse/JCR-4090
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: errors.txt, errors.txt, errors.txt
>
>




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

[jira] [Updated] (JCR-4090) Fix Javadoc for JDK 1.8 doctool compliance

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4090:

Attachment: errors.txt

1611 errors after fixing unclosed tags

> Fix Javadoc for JDK 1.8 doctool compliance
> --
>
> Key: JCR-4090
> URL: https://issues.apache.org/jira/browse/JCR-4090
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: errors.txt, errors.txt
>
>




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

Re: [VOTE] Release Apache Jackrabbit 2.13.7

[Marcel Reutegger]

On 19/12/16 13:31, Julian Reschke wrote:

Please vote on releasing this package as Apache Jackrabbit 2.13.7.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.


All checks OK.

+1 Release this package as Apache Jackrabbit 2.13.7

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit 2.13.7

[Vikas Saurabh]

[X] +1 Release this package as Apache Jackrabbit 2.13.7

Thanks,
Vikas

Re: New Jackrabbit Committer: Andrei Dulceanu

[Francesco Mari]

Welcome, Andrei!

2016-12-19 9:35 GMT+01:00 Michael Dürig :
> Hi,
>
> Please welcome Andrei as a new committer and PMC member of the Apache
> Jackrabbit project. The Jackrabbit PMC recently decided to offer Andrei
> committership based on his contributions. I'm happy to announce that he
> accepted the offer and that all the related administrative work has now been
> taken care of.
>
> Welcome to the team, Andrei!
>
> Michael

Re: New Jackrabbit Committer: Andrei Dulceanu

[Julian Sedding]

Congratulations Andrei & welcome to the team!

Regards
Julian

On Mon, Dec 19, 2016 at 9:35 AM, Michael Dürig  wrote:
> Hi,
>
> Please welcome Andrei as a new committer and PMC member of the Apache
> Jackrabbit project. The Jackrabbit PMC recently decided to offer Andrei
> committership based on his contributions. I'm happy to announce that he
> accepted the offer and that all the related administrative work has now been
> taken care of.
>
> Welcome to the team, Andrei!
>
> Michael

[jira] [Commented] (JCR-4090) Fix Javadoc for JDK 1.8 doctool compliance

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4090:
-

By default, only 100 errors are reported by doclint. This can be changed using:

{noformat}
Index: jackrabbit-parent/pom.xml
===
--- jackrabbit-parent/pom.xml   (revision 1775066)
+++ jackrabbit-parent/pom.xml   (working copy)
@@ -175,6 +175,7 @@
 
   ${java.version}
   true
+  -Xmaxwarns 1 -Xmaxerrs 
1
   
 http://docs.oracle.com/javase/7/docs/api/
 http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/
{noformat}

> Fix Javadoc for JDK 1.8 doctool compliance
> --
>
> Key: JCR-4090
> URL: https://issues.apache.org/jira/browse/JCR-4090
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: errors.txt
>
>




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

[jira] [Updated] (JCR-4090) Fix Javadoc for JDK 1.8 doctool compliance

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4090:

Attachment: errors.txt

current javadoc errors (1689!)

> Fix Javadoc for JDK 1.8 doctool compliance
> --
>
> Key: JCR-4090
> URL: https://issues.apache.org/jira/browse/JCR-4090
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: errors.txt
>
>




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

AW: [VOTE] Release Apache Jackrabbit 2.13.7

[KÖLL Claus]

+1

greets
claus

Re: [VOTE] Release Apache Jackrabbit 2.13.7

[Julian Reschke]

On 2016-12-19 13:31, Julian Reschke wrote:

...


[X] +1 Release this package as Apache Jackrabbit 2.13.7

Best regards, Julian

[VOTE] Release Apache Jackrabbit 2.13.7

[Julian Reschke]

A candidate for the Jackrabbit 2.13.7 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/2.13.7/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.13.7/

The SHA1 checksum of the archive is 
61f4b3266461e998e878ef146193a6a13eb3c6b6.


A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

$ sh check-release.sh 2.13.7 61f4b3266461e998e878ef146193a6a13eb3c6b6

Please vote on releasing this package as Apache Jackrabbit 2.13.7.
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 2.13.7
[ ] -1 Do not release this package because...


Best regards, Julian

[jira] [Commented] (JCRVLT-144) Unable to perform checkouts with vlt > 3.1.26

[angela (JIRA)]

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

angela commented on JCRVLT-144:
---

maybe just a regression that slipped in when applying the patches for JCR-2113?

> Unable to perform checkouts with vlt > 3.1.26
> -
>
> Key: JCRVLT-144
> URL: https://issues.apache.org/jira/browse/JCRVLT-144
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.1.28, 3.1.30
>Reporter: Radu Cotescu
>Assignee: Tobias Bocanegra
>
> When trying to perform a {{vlt co}} with {{vlt}} > 3.1.26 I get the following 
> error message:
> {noformat}
> vlt co --force http://localhost:4502
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; 
> support was removed in 8.0
> Checkout http://localhost:4502/crx/server/-/jcr:root/ with local files using 
> root at [...]/content/src/content/jcr_root
> Connecting via JCR remoting to http://localhost:4502/crx/server
> [ERROR] checkout: org.apache.jackrabbit.vault.vlt.VltException: Unable to 
> mount filesystem
> caused by: javax.jcr.lock.LockException: Precondition Failed
>   caused by: org.apache.jackrabbit.webdav.DavException: Precondition Failed
> {noformat}



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

[jira] [Assigned] (JCR-3954) Searches with backslash \ cause expection

[Vikas Saurabh (JIRA)]

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

Vikas Saurabh reassigned JCR-3954:
--

Assignee: Vikas Saurabh

> Searches with backslash \ cause expection
> -
>
> Key: JCR-3954
> URL: https://issues.apache.org/jira/browse/JCR-3954
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Affects Versions: 2.12.1
>Reporter: Ankit Agarwal
>Assignee: Vikas Saurabh
>
> while creating a query with '/' it creates an exception. 



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

[jira] [Commented] (JCR-3954) Searches with backslash \ cause expection

[Vikas Saurabh (JIRA)]

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

Vikas Saurabh commented on JCR-3954:


[~reschke], this seems like something that we can include, wdyt? Btw, I'm not 
sure what 
[_ESCAPE_CHAR|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Text.java#L539]
 is referring to.

Btw, [~anagarwa] we probably should update 
{{jackrabbit-jcr-tests/.../Text#escapeIllegalXpathSearchChars}} as well.

> Searches with backslash \ cause expection
> -
>
> Key: JCR-3954
> URL: https://issues.apache.org/jira/browse/JCR-3954
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Affects Versions: 2.12.1
>Reporter: Ankit Agarwal
>
> while creating a query with '/' it creates an exception. 



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

[jira] [Commented] (JCR-2113) JSR 283 Access Control Management

[angela (JIRA)]

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

angela commented on JCR-2113:
-

no, sorry, i don't

> JSR 283 Access Control Management
> -
>
> Key: JCR-2113
> URL: https://issues.apache.org/jira/browse/JCR-2113
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-jcr-server, jackrabbit-jcr2spi, 
> jackrabbit-spi, jackrabbit-spi-commons, jackrabbit-spi2dav, 
> jackrabbit-spi2jcr, JCR 2.0
>Reporter: angela
>Assignee: angela
> Fix For: 2.9.1
>
>




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

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.16

[Vikas Saurabh]

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

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.16

[Julian Reschke]

On 2016-12-19 07:31, Amit Jain wrote:

...


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

Best regards, Julian