[jira] [Comment Edited] (JCR-4221) Upgrade Apache HttpComponents to 4.5.4

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on JCR-4221 at 12/22/17 5:36 AM:
---

trunk: [r1817094|http://svn.apache.org/r1817094]
2.16: [r1818998|http://svn.apache.org/r1818998]



was (Author: reschke):
trunk: [r1817094|http://svn.apache.org/r1817094]


> Upgrade Apache HttpComponents to 4.5.4
> --
>
> Key: JCR-4221
> URL: https://issues.apache.org/jira/browse/JCR-4221
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav, jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_jcr_2_14
> Fix For: 2.18, 2.17.0, 2.16.1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4221) Upgrade Apache HttpComponents to 4.5.4

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4221:

Labels: candidate_jcr_2_14  (was: candidate_jcr_2_16)

> Upgrade Apache HttpComponents to 4.5.4
> --
>
> Key: JCR-4221
> URL: https://issues.apache.org/jira/browse/JCR-4221
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav, jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_jcr_2_14
> Fix For: 2.18, 2.17.0, 2.16.1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4221) Upgrade Apache HttpComponents to 4.5.4

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4221:

Fix Version/s: 2.16.1

> Upgrade Apache HttpComponents to 4.5.4
> --
>
> Key: JCR-4221
> URL: https://issues.apache.org/jira/browse/JCR-4221
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav, jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_jcr_2_14
> Fix For: 2.18, 2.17.0, 2.16.1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-3260) "Unknown value type 10" when reading values of a weakreference property via RMI

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-3260:

Priority: Minor  (was: Major)

> "Unknown value type 10" when reading values of a weakreference property via 
> RMI
> ---
>
> Key: JCR-3260
> URL: https://issues.apache.org/jira/browse/JCR-3260
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-rmi
>Affects Versions: 2.0.5, 2.1.6, 2.2.11, 2.3.7, 2.4
>Reporter: Torsten Witte
>Priority: Minor
> Attachments: jackrabbit-jcr-rmi-weak-references-2.4.patch
>
>
> When calling
> javax.jcr.Property jcrProperty = ...
> Value[] values = jcrProperty.getValues();
> on a weakreference property the following error occurs:
> javax.jcr.ValueFormatException: Unknown value type 10
> at 
> org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:139)
> at 
> org.apache.jackrabbit.rmi.server.ServerProperty.getValues(ServerProperty.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> at 
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
> at org.apache.jackrabbit.rmi.server.ServerProperty_Stub.getValues(Unknown 
> Source)
> at 
> org.apache.jackrabbit.rmi.client.ClientProperty.getValues(ClientProperty.java:173)
> I think the reason is that 
> org.apache.jackrabbit.rmi.value.SerialValueFactory.createValue(Value value, 
> int type) does not support the property type "weakreference".
> See 
> http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-rmi/src/main/java/org/apache/jackrabbit/rmi/value/SerialValueFactory.java?view=markup
>  in line 159.
> Just adding the case for PropertyType.WEAKREFERENCE should fix the problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-1723) Both the JNDIDatabaseFileSystem and JNDIDatabasePersistenceManager need to create InitialContext with jndi.properties

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-1723.
-
Resolution: Not A Problem

> Both the JNDIDatabaseFileSystem and JNDIDatabasePersistenceManager need to 
> create InitialContext with jndi.properties
> -
>
> Key: JCR-1723
> URL: https://issues.apache.org/jira/browse/JCR-1723
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Affects Versions: core 1.4.5
>Reporter: Kevin McKee
>Priority: Critical
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Both the JNDIDatabaseFileSystem and JNDIDatabasePersistenceManager create an 
> initial context by doing the following:
> InitialContext ic = new InitialContext();
> They should both allow the initial context to be created with specified 
> jndi.properties or to be able to look up jndi.properties by default on the 
> classpath.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-2136) ORA-01461: can bind a LONG value only for insert into a LONG column

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-2136.
-
Resolution: Cannot Reproduce

> ORA-01461: can bind a LONG value only for insert into a LONG column
> ---
>
> Key: JCR-2136
> URL: https://issues.apache.org/jira/browse/JCR-2136
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5
> Environment: OS: Window XP
> OS default character set: 936 (ANSI/OEM- simplified Chinese GBK)
> Database: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
> Database default character set: SIMPLIFIED CHINESE_CHINA.ZHS16GBK
>Reporter: Joe Tang
>Priority: Critical
>
> This issue happens occasionally. Not only happened at node.lock(false, true) 
> but also at other APIs like node.save(), node.checkin, etc...
> 009-06-10 18:23:23,715 ERROR 
> [org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager]
>  could not execute statement, reason: ORA-01461: can bind a LONG value only 
> for insert into a LONG column
> , state/code: 72000/1461
> 2009-06-10 18:23:23,715 DEBUG 
> [org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager]
> dump:
> java.sql.SQLException: ORA-01461: can bind a LONG value only for insert into 
> a LONG column
>   at 
> oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
>   at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
>   at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
>   at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
>   at 
> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219)
>   at 
> oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:970)
>   at 
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1190)
>   at 
> oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3370)
>   at 
> oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3476)
>   at 
> org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmtInternal(ConnectionRecoveryManager.java:371)
>   at 
> org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmtInternal(ConnectionRecoveryManager.java:298)
>   at 
> org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmt(ConnectionRecoveryManager.java:261)
>   at 
> org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmt(ConnectionRecoveryManager.java:239)
>   at 
> org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.storeBundle(BundleDbPersistenceManager.java:1197)
>   at 
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.putBundle(AbstractBundlePersistenceManager.java:701)
>   at 
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.store(AbstractBundlePersistenceManager.java:641)
>   at 
> org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.store(BundleDbPersistenceManager.java:524)
>   at 
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:712)
>   at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1084)
>   at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:337)
>   at 
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:340)
>   at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:312)
>   at 
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:313)
>   at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1105)
>   at org.apache.jackrabbit.core.NodeImpl.lock(NodeImpl.java:4464)
>   at 
> com.vitria.modeling.repository.sapi.service.jcr.JcrInternalLocked.acquireLock(JcrInternalLocked.java:60)
>   at 
> com.vitria.modeling.repository.sapi.service.jcr.JcrInternalLocked.with(JcrInternalLocked.java:26)
>   at 
> com.vitria.modeling.repository.sapi.service.jcr.JcrLockedObjectUtil.checkout(JcrLockedObjectUtil.java:422)
>   at 
> com.vitria.modeling.repository.sapi.service.jcr.JcrLeaveNodeImpl.checkout(JcrLeaveNodeImpl.java:94)
>   at 
> com.vitria.modeling.repository.sapi.service.core.CoreModel.checkout(CoreModel.java:145)
>   at 
> com.vitria.modeling.repository.sapi.service.proxy.local.LocalModel.checkout(LocalModel.java:67)
>   at 
> 

[jira] [Resolved] (JCR-2225) ORA-01460 ClusterNode: Unable to commit log entry

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-2225.
-
Resolution: Not A Bug

> ORA-01460 ClusterNode: Unable to commit log entry
> -
>
> Key: JCR-2225
> URL: https://issues.apache.org/jira/browse/JCR-2225
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5.6
> Environment: Oracle DB 10 -  linux - jackrabbit 1.5.6
>Reporter: Lorenzo Pavesi
>Priority: Critical
>
> Clustering over Oracle doesn't work the LOCAL_VERSION tables go out of sinc 
> with the global revision, jcr element (ie nt:file...and all) added into the 
> first cluster node aren't available from the second cluster nodes
> 23.07.2009 14:50:29 *ERROR* ClusterNode: Unable to commit log entry. 
> (ClusterNode.java, line 655)
> org.apache.jackrabbit.core.journal.JournalException: Unable to append 
> revision 27384.
> at 
> org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:558)
> at 
> org.apache.jackrabbit.core.journal.AppendRecord.update(AppendRecord.java:251)
> at 
> org.apache.jackrabbit.core.cluster.ClusterNode$WorkspaceUpdateChannel.updateCommitted(ClusterNode.java:650)
> at 
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:754)
> at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1092)
> at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:337)
> at 
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:347)
> at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:312)
> at 
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:313)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1103)
> at 
> com.vodafone.superstore.utils.CommunityPlaceUtils.createComunityPlace(CommunityPlaceUtils.java:376)
> at 
> com.vodafone.superstore.populate.lbs.AddCommunityPlace.createCommunityPlace(AddCommunityPlace.java:223)
> at 
> com.vodafone.superstore.populate.lbs.AddCommunityPlace.doPost(AddCommunityPlace.java:159)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.sql.SQLException: ORA-01460: unimplemented or unreasonable 
> conversion requested
> at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
> at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
> at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:582)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1986)
> at 
> oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:1144)
> at 
> oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2152)
> at 
> oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:2035)
> at 
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2876)
> at 
> oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:609)
> at 
> oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:685)
> at 
> org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:552)
> ... 26 more
>  /**
>  * {@inheritDoc}
>  * 
>  * We have already saved away the revision 

[jira] [Resolved] (JCR-2292) attempt to access a deleted document

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-2292.
-
Resolution: Cannot Reproduce

> attempt to access a deleted document
> 
>
> Key: JCR-2292
> URL: https://issues.apache.org/jira/browse/JCR-2292
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: query
>Affects Versions: 1.6
> Environment: Windows XP, Java 1.6.0_13-b03
>Reporter: Imran
>Priority: Critical
>
> When I run the query : items//*[(jcr:contains(@MYATTRIB, 'MYATTRIB-VALUE') I 
> get results back.
> But if I add a "not" condition: items//*[not(jcr:contains(@MYATTRIB, 
> 'MYATTRIB-VALUE') , I get "java.lang.IllegalArgumentException: attempt to 
> access a deleted document" exception
> After I renamed the index directory [effectively forcing a re-index], and ran 
> the application again, the "not" condition query works. If I restore the 
> previous index I get the error again.
> The workaround of deleting index is fine in the development environment. But 
> once we go to production, we will not have the option to delete the index 
> directories.
> Btw, I found that a similar defect [JCR-1573] was reported and marked as 
> fixed. Apparently it keeps re-surfacing under different conditions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-3260) "Unknown value type 10" when reading values of a weakreference property via RMI

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-3260:

Issue Type: Improvement  (was: Bug)

> "Unknown value type 10" when reading values of a weakreference property via 
> RMI
> ---
>
> Key: JCR-3260
> URL: https://issues.apache.org/jira/browse/JCR-3260
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-rmi
>Affects Versions: 2.0.5, 2.1.6, 2.2.11, 2.3.7, 2.4
>Reporter: Torsten Witte
> Attachments: jackrabbit-jcr-rmi-weak-references-2.4.patch
>
>
> When calling
> javax.jcr.Property jcrProperty = ...
> Value[] values = jcrProperty.getValues();
> on a weakreference property the following error occurs:
> javax.jcr.ValueFormatException: Unknown value type 10
> at 
> org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:139)
> at 
> org.apache.jackrabbit.rmi.server.ServerProperty.getValues(ServerProperty.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> at 
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
> at org.apache.jackrabbit.rmi.server.ServerProperty_Stub.getValues(Unknown 
> Source)
> at 
> org.apache.jackrabbit.rmi.client.ClientProperty.getValues(ClientProperty.java:173)
> I think the reason is that 
> org.apache.jackrabbit.rmi.value.SerialValueFactory.createValue(Value value, 
> int type) does not support the property type "weakreference".
> See 
> http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-rmi/src/main/java/org/apache/jackrabbit/rmi/value/SerialValueFactory.java?view=markup
>  in line 159.
> Just adding the case for PropertyType.WEAKREFERENCE should fix the problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-3260) "Unknown value type 10" when reading values of a weakreference property via RMI

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-3260:

Priority: Major  (was: Critical)

> "Unknown value type 10" when reading values of a weakreference property via 
> RMI
> ---
>
> Key: JCR-3260
> URL: https://issues.apache.org/jira/browse/JCR-3260
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-rmi
>Affects Versions: 2.0.5, 2.1.6, 2.2.11, 2.3.7, 2.4
>Reporter: Torsten Witte
> Attachments: jackrabbit-jcr-rmi-weak-references-2.4.patch
>
>
> When calling
> javax.jcr.Property jcrProperty = ...
> Value[] values = jcrProperty.getValues();
> on a weakreference property the following error occurs:
> javax.jcr.ValueFormatException: Unknown value type 10
> at 
> org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:139)
> at 
> org.apache.jackrabbit.rmi.server.ServerProperty.getValues(ServerProperty.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> at 
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
> at org.apache.jackrabbit.rmi.server.ServerProperty_Stub.getValues(Unknown 
> Source)
> at 
> org.apache.jackrabbit.rmi.client.ClientProperty.getValues(ClientProperty.java:173)
> I think the reason is that 
> org.apache.jackrabbit.rmi.value.SerialValueFactory.createValue(Value value, 
> int type) does not support the property type "weakreference".
> See 
> http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-rmi/src/main/java/org/apache/jackrabbit/rmi/value/SerialValueFactory.java?view=markup
>  in line 159.
> Just adding the case for PropertyType.WEAKREFERENCE should fix the problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-3288) ConnectionFactory.getDriverClass() should use Thread.currentThread().getContextClassLoader(); instead of Class.forName()

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-3288.
-
Resolution: Not A Bug

> ConnectionFactory.getDriverClass() should use 
> Thread.currentThread().getContextClassLoader(); instead of Class.forName()
> 
>
> Key: JCR-3288
> URL: https://issues.apache.org/jira/browse/JCR-3288
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.3.3
> Environment: WXP Sun JDK 1.6.0_30 Derby database
>Reporter: Francis ANDRE
>Priority: Critical
>
> Hi
> The ConnectionFactory.getDriverClass() should use 
> Thread.currentThread().getContextClassLoader(); instead of Class.forName() 
> otherwise dynamically added jdbc drivers to the classpath are not found;
>   ClassLoader cl = Thread.currentThread().getContextClassLoader();
>   return cl.loadClass(driver);
> //return Class.forName(driver);



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-3567) SQL2 query doesn't respect resultFetchSize value specified in workspace.xml

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-3567.
-
Resolution: Cannot Reproduce

> SQL2 query doesn't respect resultFetchSize value specified in workspace.xml
> ---
>
> Key: JCR-3567
> URL: https://issues.apache.org/jira/browse/JCR-3567
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: query
>Affects Versions: 2.6
> Environment: Linux Mint 14 64bit 8Gb Ram
>Reporter: Luca Tagliani
>Priority: Critical
>
> Using SQL2 query language, in a repository with nearly 120 node of the 
> same type, even if it's specified a resultFetchSize of 1000 in workspace.xml, 
> a query to retrieve all the nodes, tries to recover from the DB all the 
> results.
> Using an XPATH query all works as expected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-3738) CLONE - Deadlock on LOCAL_REVISION table in clustering environment

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-3738.
-
Resolution: Cannot Reproduce

> CLONE - Deadlock on LOCAL_REVISION table in clustering environment
> --
>
> Key: JCR-3738
> URL: https://issues.apache.org/jira/browse/JCR-3738
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: clustering
>Affects Versions: 2.6.2
> Environment: CQ5.6.1 with jackrabbit-core 2.6.2 backed off ibm db2 
> v10.5
>Reporter: Ankush Malhotra
>Priority: Critical
> Attachments: before-lock.zip, db-deadlock-info.txt, 
> extended-log-with-dumps.txt, stat-cache.log, threaddumps.zip
>
>
> Original, cloned description:
> > When inserting a lot of nodes concurrently (100/200 threads) the system 
> > hangs generating a deadlock on the LOCAL_REVISION table.
> > There is a thread that starts a transaction but the transaction remains 
> > open, while another thread tries to acquire the lock on the table.
> > This actually happen even if there is only a server up but configured in 
> > cluster mode.
> > I found that in AbstractJournal, we try to write the LOCAL_REVISION even if 
> > we don't sync any record because they're generated by the same journal of 
> > the thread running.
> >
> > Removing this unnecessary (to me :-) ) write to the LOCAL_REVISION table, 
> > remove the deadlock.
> This might not be the exact same case with this issue. See the attached 
> thread dumps etc. for full details.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-2913) Shared nodes disappear suddenly - Database corruption : Cannot delete nodes anymore : Node with id 'X" does not have shared parent with id: 'Y'

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-2913.
-
Resolution: Cannot Reproduce

> Shared nodes disappear suddenly - Database corruption : Cannot delete nodes 
> anymore : Node with id 'X" does not have shared parent with id: 'Y'
> ---
>
> Key: JCR-2913
> URL: https://issues.apache.org/jira/browse/JCR-2913
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: julien revel
>Priority: Critical
>
> This problem occurs on a following configuration
> - JCR 2.3 Snapshot
> - Tomcat 6
> - Postgresql 9.0
> Jackrabbit is embedded within a Spring application, that communicates with 
> clients in AMF format (Flex client)
> The symptom is that some shared Nodes have disappeared from the repository, 
> without having deleted by our application (and we checked a lot already).
> Then, repository seems to be corrupted, because it becomes impossible to 
> delete any ancestor node of those having disappear.
> The error is not reproducible, it may happen at any time, it is random.
> Sometimes, with a fresh base, after creating some nodes, sometimes it happens 
> after a while, when playing with the application.
> It never happened on Jetty/Derby development server, but always happened on 
> servers with Postgres, even with a single user.
> I guess it is not a bug in JCR, but that we provoked the problem in some way. 
> Maybe by multi-threading  ? 
> However, for each remote call that send data to write, we create a new 
> JCRSession, then save it multiple times, then close it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-3969) java.io.IOException: Directory was previously created with a different LockFactory instance

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-3969.
-
Resolution: Cannot Reproduce

> java.io.IOException: Directory was previously created with a different 
> LockFactory instance
> ---
>
> Key: JCR-3969
> URL: https://issues.apache.org/jira/browse/JCR-3969
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
> Environment: windows 12, Weblogic 11g
>Reporter: span
>Priority: Critical
>
> Hi,
> I am getting this error while starting the Doorls-guvnor application...can 
> anyone hellp on this.
>    
>   <[ACTIVE] ExecuteThread: '0' for queue: 
> 'weblogic.kernel.Default (self-tuning)'> <> <> 
> <5c38ae7fb0b203ee:2111cdb4:1542d76fbe2:-8000-11b6> 
> <1461051902024>   com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public 
> abstract org.drools.guvnor.client.rpc.Module[] 
> org.drools.guvnor.client.rpc.ModuleService.listModules()' threw an unexpected 
> exception: org.jboss.weld.exceptions.WeldException: WELD-49 Unable to 
> invoke [method] @PostConstruct public 
> org.drools.guvnor.server.repository.RepositoryStartupService.create() on 
> org.drools.guvnor.server.repository.ProductionRepositoryStartupService@699352fe
>   at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:385)
>   at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:588)
>   at 
> com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
>   at 
> com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
>   at 
> com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>   at 
> weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
>   at 
> weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
>   at 
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)
>   at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
>   at 
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)
>   at 
> org.jboss.solder.servlet.event.ServletEventBridgeFilter.doFilter(ServletEventBridgeFilter.java:74)
>   at 
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)
>   at 
> org.jboss.solder.servlet.exception.CatchExceptionFilter.doFilter(CatchExceptionFilter.java:65)
>   at 
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)
>   at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:324)
>   at 
> oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:460)
>   at 
> oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
>   at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
>   at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
>   at 
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)
>   at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:163)
>   at 
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)
>   at 
> weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
>   at 
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:60)
>   at 
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3748)
>   at 
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3714)
>   at 
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>   at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
>   at 
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2283)
>   at 
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2182)
>   at 
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1491)
>   at weblogic.work.ExecuteThread.execute(ExecuteThread.java:263)
>   at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
> Caused By: org.jboss.weld.exceptions.WeldException: WELD-49 Unable to 
> invoke [method] @PostConstruct public 
> 

[jira] [Resolved] (JCR-4123) No log file found containing revision: 0

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4123.
-
Resolution: Cannot Reproduce

> No log file found containing revision: 0
> 
>
> Key: JCR-4123
> URL: https://issues.apache.org/jira/browse/JCR-4123
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: clustering, jackrabbit-core
>Affects Versions: 2.12.6
> Environment: Linux version 2.6.32.12-0.7-default (geeko@buildhost) 
> (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP 
> 2010-05-20 11:14:20 +0200
> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4)
>Reporter: Morenko Roman
>Priority: Blocker
>
> After update version jackrabbit from 2.2.10 to 2.12.6
> we caught exeption
> [3/24/17 7:35:27:706 GMT+03:00] 006e ClusterNode   E 
> org.apache.jackrabbit.core.cluster.ClusterNode run Periodic sync of journal 
> failed: Unable to open record log with revision: 0
>  
> org.apache.jackrabbit.core.cluster.ClusterException: Unable to open record 
> log with revision: 0
>   at 
> org.apache.jackrabbit.core.cluster.ClusterNode.internalSync(ClusterNode.java:343)
>   at 
> org.apache.jackrabbit.core.cluster.ClusterNode.sync(ClusterNode.java:356)
>   at 
> org.apache.jackrabbit.core.cluster.ClusterNode.run(ClusterNode.java:303)
>   at java.lang.Thread.run(Thread.java:738)
> Caused by: java.io.IOException: No log file found containing revision: 0
>   at 
> org.apache.jackrabbit.core.journal.FileRecordIterator.getRecordLog(FileRecordIterator.java:161)
>   at 
> org.apache.jackrabbit.core.journal.FileRecordIterator.nextRecord(FileRecordIterator.java:119)
>   at 
> org.apache.jackrabbit.core.journal.AbstractJournal.doSync(AbstractJournal.java:248)
>   at 
> org.apache.jackrabbit.core.journal.AbstractJournal.doSync(AbstractJournal.java:232)
>   at 
> org.apache.jackrabbit.core.journal.AbstractJournal.internalSync(AbstractJournal.java:222)
>   at 
> org.apache.jackrabbit.core.journal.AbstractJournal.sync(AbstractJournal.java:190)
>   at 
> org.apache.jackrabbit.core.cluster.ClusterNode.internalSync(ClusterNode.java:340)
>   ... 3 more



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [windows] Jenkins test failure - o.a.j.o.index.indexer.document.flatfile.FlatFileStoreTest.basicTest

[Vikas Saurabh]

Hi Robert,

> I am not able to qualify whether this is a valid failure or not,
> therefore I'm bringing it to the mailing list.
>
That should be independent of OS... for me, following failed:
MAVEN_OPTS='-Xmx512m -Xms512m' mvn test -pl :oak-run
-Dtest=FlatFileStoreTest#basicTest

Opened OAK-7108 and fixed in r1818991.

Thanks,
Vikas

[windows] Jenkins test failure - o.a.j.o.index.indexer.document.flatfile.FlatFileStoreTest.basicTest

[Robert Munteanu]

Hi,

The
org.apache.jackrabbit.oak.index.indexer.document.flatfile.FlatFileStore
Test.basicTest has failed for the past 2 runs on the Windows build job:

https://builds.apache.org/job/Jackrabbit-Oak-Windows/lastBuild/org.apac
he.jackrabbit$oak-
run/testReport/org.apache.jackrabbit.oak.index.indexer.document.flatfil
e/FlatFileStoreTest/basicTest/

The error message is: java.lang.IllegalArgumentException: Invalid
threshold: 2147483648 > max (358088704).

I am not able to qualify whether this is a valid failure or not,
therefore I'm bringing it to the mailing list.

Thanks,

Robert

Jackrabbit 2.8.7 Release Plan

[Julian Reschke]

Hi,

I'd like to cut Jackrabbit 2.8.7 on January, 2nd.

The list of open issues scheduled for 2.8.7 is empty:

https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.8.7%20AND%20project%20%3D%20JCR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

The candidate release notes are here:

https://svn.apache.org/repos/asf/jackrabbit/branches/2.8/RELEASE-NOTES.txt

If there are any objections please let me know.

Best regards, Julian

Re: Experimental build for Oak on Windows

[Robert Munteanu]

On Wed, 2017-12-06 at 13:48 +0200, Robert Munteanu wrote:
> I'll keep it alive for a couple of weeks to assess its stability, and
> then we can discuss whether we want to promote it to a 'proper' job
> that we actually pay attention to and that sends notifications.

The builds have started failing due to Jenkins issues, so it seems the
stability is not how we need it.

I've reported it at [1], hopefully we can eliminate the root cause of
such problems.

Robert

[1]: https://lists.apache.org/thread.html/3c614a08275ff7484c51bfe025d8b
b983aaf58a407dde53f7bf354e7@%3Cbuilds.apache.org%3E

[jira] [Updated] (JCRVLT-256) Package Maven Plugin: NPE when dependency has no manifest

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated JCRVLT-256:
--
Status: Patch Available  (was: Open)

patch attached that adds a test case to reproduce the problem in the IT and fix 
the NPE.

> Package Maven Plugin: NPE when dependency has no manifest
> -
>
> Key: JCRVLT-256
> URL: https://issues.apache.org/jira/browse/JCRVLT-256
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Stefan Seifert
>Priority: Minor
> Fix For: package-maven-plugin-1.0.2
>
> Attachments: JCRVLT-256.patch
>
>
> when the package project contains a dependency that has not manifest at all 
> (e.g. javax.inject) the code throws an NPE.
> of course it does not make much sense to have such an dependency, but it 
> should not lead to an err.r



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCRVLT-256) Package Maven Plugin: NPE when dependency has no manifest

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated JCRVLT-256:
--
Attachment: JCRVLT-256.patch

> Package Maven Plugin: NPE when dependency has no manifest
> -
>
> Key: JCRVLT-256
> URL: https://issues.apache.org/jira/browse/JCRVLT-256
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Stefan Seifert
>Priority: Minor
> Fix For: package-maven-plugin-1.0.2
>
> Attachments: JCRVLT-256.patch
>
>
> when the package project contains a dependency that has not manifest at all 
> (e.g. javax.inject) the code throws an NPE.
> of course it does not make much sense to have such an dependency, but it 
> should not lead to an err.r



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-256) Package Maven Plugin: NPE when dependency has no manifest

[Stefan Seifert (JIRA)]

Stefan Seifert created JCRVLT-256:
-

 Summary: Package Maven Plugin: NPE when dependency has no manifest
 Key: JCRVLT-256
 URL: https://issues.apache.org/jira/browse/JCRVLT-256
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.1
Reporter: Stefan Seifert
Priority: Minor
 Fix For: package-maven-plugin-1.0.2


when the package project contains a dependency that has not manifest at all 
(e.g. javax.inject) the code throws an NPE.
of course it does not make much sense to have such an dependency, but it should 
not lead to an err.r



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Intent to backport OAK-5317

[Chetan Mehrotra]

+1
Chetan Mehrotra


On Thu, Dec 21, 2017 at 4:57 PM, Marcel Reutegger
 wrote:
> Hi,
>
> I'd like to backport OAK-5317 to the maintenance branches. It is an 
> improvement, but would allow users to run a DocumentNodeStore on more recent 
> MongoDB version. I consider the change low risk, because the index is there 
> anyway.
>
> Regards
>  Marcel
>

Intent to backport OAK-5317

[Marcel Reutegger]

Hi,

I'd like to backport OAK-5317 to the maintenance branches. It is an 
improvement, but would allow users to run a DocumentNodeStore on more recent 
MongoDB version. I consider the change low risk, because the index is there 
anyway.

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.14

[Andrei Dulceanu]

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

where

INFO]

[INFO] Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T10:58:13+03:00)
[INFO] OS name: "mac os x", version: "10.13.2", arch: "x86_64", family:
"mac"
[INFO] Java version: 1.8.0_65, vendor: Oracle Corporation
[INFO]


Andrei

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.14

[Marcel Reutegger]

On 20/12/17 18:46, Davide Giannella wrote:

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

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.14

[Davide Giannella]

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

D.

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.14

[Michael Dürig]

On 20.12.17 18:46, Davide Giannella wrote:

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


Michael

[jira] [Resolved] (JCR-4217) Release Jackrabbit 2.17.0

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4217.
-
Resolution: Fixed

> Release Jackrabbit 2.17.0
> -
>
> Key: JCR-4217
> URL: https://issues.apache.org/jira/browse/JCR-4217
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[ANNOUNCE] Apache Jackrabbit 2.17.0 released

[Julian Reschke]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit 2.17.0 The release is available for download at:

http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:

Release Notes -- Apache Jackrabbit -- Version 2.17.0

Introduction


This is Apache Jackrabbit(TM) 2.17.0, a fully compliant implementation 
of the

Content Repository for Java(TM) Technology API, version 2.0 (JCR 2.0) as
specified in the Java Specification Request 283 (JSR 283).

Apache Jackrabbit 2.17.0 is an unstable release cut directly from
Jackrabbit trunk, with a focus on new features and other
improvements. For production use we recommend the latest stable 2.16.x
release.

Changes in Jackrabbit 2.17.0


Task

[JCR-4218] - switch bundle comparisonVersion
[JCR-4221] - Upgrade Apache HttpComponents to 4.5.4
[JCR-4222] - Document reduced RMI interop with older servers after 
java-9 related changes

[JCR-4223] - Upgrade commons-fileupload dependency to 1.3.3
[JCR-4224] - Upgrade tomcat-servlet dependency to 7.0.82
[JCR-4225] - Upgrade commons-chains dependency to 1.2
[JCR-4226] - Upgrade tika-parsers dependency to 2.16
[JCR-4228] - Update Oak dependency to latest 1.0 stable release
[JCR-4231] - Upgrade aws-java-sdk-s3 dependency to 1.11.241
[JCR-4233] - Update H2DB test dependency

In addition to the above-mentioned changes, this release contains
all the changes included up to the Apache Jackrabbit 2.16.x release.

For more detailed information about all the changes in this and other
Jackrabbit releases, please see the Jackrabbit issue tracker at

https://issues.apache.org/jira/browse/JCR

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.txt file for instructions on how to build this release.

The source archive is accompanied by SHA1 and MD5 checksums and a PGP
signature that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at
https://svn.apache.org/repos/asf/jackrabbit/dist/KEYS.

About Apache Jackrabbit
---

Apache Jackrabbit is a fully conforming implementation of the Content
Repository for Java Technology API (JCR). A content repository is a
hierarchical content store with support for structured and unstructured
content, full text search, versioning, transactions, observation, and
more.

For more information, visit http://jackrabbit.apache.org/

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

Trademarks
--

Apache Jackrabbit, Jackrabbit, Apache, the Apache feather logo, and the 
Apache

Jackrabbit project logo are trademarks of The Apache Software Foundation.

[ANNOUNCE] Apache Jackrabbit 2.17.0 released

[Julian Reschke]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit 2.17.0 The release is available for download at:

http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:

Release Notes -- Apache Jackrabbit -- Version 2.17.0

Introduction


This is Apache Jackrabbit(TM) 2.17.0, a fully compliant implementation 
of the

Content Repository for Java(TM) Technology API, version 2.0 (JCR 2.0) as
specified in the Java Specification Request 283 (JSR 283).

Apache Jackrabbit 2.17.0 is an unstable release cut directly from
Jackrabbit trunk, with a focus on new features and other
improvements. For production use we recommend the latest stable 2.16.x
release.

Changes in Jackrabbit 2.17.0


Task

[JCR-4218] - switch bundle comparisonVersion
[JCR-4221] - Upgrade Apache HttpComponents to 4.5.4
[JCR-4222] - Document reduced RMI interop with older servers after 
java-9 related changes

[JCR-4223] - Upgrade commons-fileupload dependency to 1.3.3
[JCR-4224] - Upgrade tomcat-servlet dependency to 7.0.82
[JCR-4225] - Upgrade commons-chains dependency to 1.2
[JCR-4226] - Upgrade tika-parsers dependency to 2.16
[JCR-4228] - Update Oak dependency to latest 1.0 stable release
[JCR-4231] - Upgrade aws-java-sdk-s3 dependency to 1.11.241
[JCR-4233] - Update H2DB test dependency

In addition to the above-mentioned changes, this release contains
all the changes included up to the Apache Jackrabbit 2.16.x release.

For more detailed information about all the changes in this and other
Jackrabbit releases, please see the Jackrabbit issue tracker at

https://issues.apache.org/jira/browse/JCR

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.txt file for instructions on how to build this release.

The source archive is accompanied by SHA1 and MD5 checksums and a PGP
signature that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at
https://svn.apache.org/repos/asf/jackrabbit/dist/KEYS.

About Apache Jackrabbit
---

Apache Jackrabbit is a fully conforming implementation of the Content
Repository for Java Technology API (JCR). A content repository is a
hierarchical content store with support for structured and unstructured
content, full text search, versioning, transactions, observation, and
more.

For more information, visit http://jackrabbit.apache.org/

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

Trademarks
--

Apache Jackrabbit, Jackrabbit, Apache, the Apache feather logo, and the 
Apache

Jackrabbit project logo are trademarks of The Apache Software Foundation.

[jira] [Closed] (JCR-4228) Update Oak dependency to latest 1.0 stable release

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4228.
---

> Update Oak dependency to latest 1.0 stable release
> --
>
> Key: JCR-4228
> URL: https://issues.apache.org/jira/browse/JCR-4228
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-webapp
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_16, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.18, 2.17.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JCR-4231) Upgrade aws-java-sdk-s3 dependency to 1.11.241

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4231.
---

> Upgrade aws-java-sdk-s3 dependency to 1.11.241
> --
>
> Key: JCR-4231
> URL: https://issues.apache.org/jira/browse/JCR-4231
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-aws-ext
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.18, 2.17.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JCR-4224) Upgrade tomcat-servlet dependency to 7.0.82

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4224.
---

> Upgrade tomcat-servlet dependency to 7.0.82
> ---
>
> Key: JCR-4224
> URL: https://issues.apache.org/jira/browse/JCR-4224
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-webapp
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_16, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.18, 2.17.0
>
>
> See CVE-2017-12617



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JCR-4226) Upgrade tika-parsers dependency to 2.16

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4226.
---

> Upgrade tika-parsers dependency to 2.16
> ---
>
> Key: JCR-4226
> URL: https://issues.apache.org/jira/browse/JCR-4226
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.18, 2.17.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JCR-4218) switch bundle comparisonVersion

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4218.
---

> switch bundle comparisonVersion
> ---
>
> Key: JCR-4218
> URL: https://issues.apache.org/jira/browse/JCR-4218
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.18, 2.17.0, 2.16.1
>
>
> both in trunk and 2.16: 2.14.0 -> 2.16.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JCR-4222) Document reduced RMI interop with older servers after java-9 related changes

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4222.
---

> Document reduced RMI interop with older servers after java-9 related changes
> 
>
> Key: JCR-4222
> URL: https://issues.apache.org/jira/browse/JCR-4222
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr-rmi
>Affects Versions: 2.16.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.18, 2.17.0, 2.16.1
>
> Attachments: JCR-4222.diff
>
>
> Due to the change for JCR-4195, the RMI client side does not work with 
> pre-2.16.0 servers. (and vice versa?).
> We should document this restriction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JCR-4221) Upgrade Apache HttpComponents to 4.5.4

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4221.
---

> Upgrade Apache HttpComponents to 4.5.4
> --
>
> Key: JCR-4221
> URL: https://issues.apache.org/jira/browse/JCR-4221
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav, jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_jcr_2_16
> Fix For: 2.18, 2.17.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JCR-4223) Upgrade commons-fileupload dependency to 1.3.3

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4223.
---

> Upgrade commons-fileupload dependency to 1.3.3
> --
>
> Key: JCR-4223
> URL: https://issues.apache.org/jira/browse/JCR-4223
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.10.7, 2.6.10, 2.8.7, 2.18, 2.12.9, 2.14.5, 2.17.0, 
> 2.16.1
>
>
> See CVE-2017-12617



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JCR-4233) Update H2DB test dependency

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4233.
---

> Update H2DB test dependency
> ---
>
> Key: JCR-4233
> URL: https://issues.apache.org/jira/browse/JCR-4233
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_jcr_2_16
> Fix For: 2.18, 2.17.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JCR-4225) Upgrade commons-chains dependency to 1.2

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4225.
---

> Upgrade commons-chains dependency to 1.2
> 
>
> Key: JCR-4225
> URL: https://issues.apache.org/jira/browse/JCR-4225
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-standalone
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.18, 2.17.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[RESULT] [VOTE] Release Apache Jackrabbit 2.17.0

[Julian Reschke]

On 2017-12-18 06:04, Julian Reschke wrote:

...


Hi there,

the vote passes as follows:

+1 Amit Jain 
+1 Claus Köll 
+1 Davide Giannella 
+1 Julian Reschke 
+1 Robert Munteanu 

Thanks for voting. I'll push the release out.

Best regards, Julian