[jira] [Updated] (JCR-4186) Use current Derby version

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4186:

Fix Version/s: 2.12.9

> Use current Derby version
> -
>
> Key: JCR-4186
> URL: https://issues.apache.org/jira/browse/JCR-4186
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_10, candidate_jcr_2_8
> Fix For: 2.16, 2.15.7, 2.14.4, 2.12.9
>
>
> Use a current version of Derby (as supported for the Java version we support).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCR-4186) Use current Derby version

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4186:

Labels: candidate_jcr_2_10 candidate_jcr_2_8  (was: candidate_jcr_2_10 
candidate_jcr_2_12 candidate_jcr_2_6 candidate_jcr_2_8)

> Use current Derby version
> -
>
> Key: JCR-4186
> URL: https://issues.apache.org/jira/browse/JCR-4186
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_10, candidate_jcr_2_8
> Fix For: 2.16, 2.15.7, 2.14.4, 2.12.9
>
>
> Use a current version of Derby (as supported for the Java version we support).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCR-4149) change to drop SHA-1 requires version change

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4149:

Labels: candidate_jcr_2_12  (was: )

> change to drop SHA-1 requires version change
> 
>
> Key: JCR-4149
> URL: https://issues.apache.org/jira/browse/JCR-4149
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-data
>Affects Versions: 2.15.3
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_12
> Fix For: 2.16, 2.14.2, 2.15.4
>
> Attachments: JCR_4149.patch
>
>
> The change for JCR-4115 for 2.14 causes a problem report by the bundle plugin:
> {noformat}
> [INFO] 
> ---
> [INFO] * org.apache.jackrabbit.core.data.db major  2.13.5 
> 2.13.5 3.0.0  Version increase required
> [INFO]  > class org.apache.jackrabbit.core.data.db.DbDataStore
> [INFO]  > field java.lang.String DIGEST
> [INFO]  - access final
> [INFO]  - access static
> [INFO]  - constant SHA-1
> [INFO]  > class org.apache.jackrabbit.core.data.db.DerbyDataStore
> [INFO]  > field java.lang.String DIGEST
> [INFO]  - access final
> [INFO]  - access static
> [INFO]  - constant SHA-1
> {noformat}
> Reverting [r1797148|http://svn.apache.org/r1797148] for now. but we also need 
> to solve this for trunk where the change wasn't noticed before a release.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (JCR-4001) When using Node.getProperties(String namePattern) also child nodes are processed

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on JCR-4001 at 4/23/18 3:34 PM:
--

trunk: [r1821597|http://svn.apache.org/r1821597]
2.16: [r1822968|http://svn.apache.org/r1822968]
2.14: [r1823660|http://svn.apache.org/r1823660]
2.12: [r1829896|http://svn.apache.org/r1829896]



was (Author: reschke):
trunk: [r1821597|http://svn.apache.org/r1821597]
2.16: [r1822968|http://svn.apache.org/r1822968]
2.14: [r1823660|http://svn.apache.org/r1823660]


> When using Node.getProperties(String namePattern) also child nodes are 
> processed
> 
>
> Key: JCR-4001
> URL: https://issues.apache.org/jira/browse/JCR-4001
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-commons
>Reporter: Luca Tagliani
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_10
> Fix For: 2.18, 2.12.9, 2.14.5, 2.16.1, 2.17.1
>
> Attachments: JCR-4001-2.diff, JCR-4001.patch
>
>
> Call to Node.getProperties(String namePattern) processed also child nodes and 
> not only properties.
> This can deteriorate performance when there are lots of children.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCR-4001) When using Node.getProperties(String namePattern) also child nodes are processed

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4001:

Labels: candidate_jcr_2_10  (was: candidate_jcr_2_12)

> When using Node.getProperties(String namePattern) also child nodes are 
> processed
> 
>
> Key: JCR-4001
> URL: https://issues.apache.org/jira/browse/JCR-4001
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-commons
>Reporter: Luca Tagliani
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_10
> Fix For: 2.18, 2.12.9, 2.14.5, 2.16.1, 2.17.1
>
> Attachments: JCR-4001-2.diff, JCR-4001.patch
>
>
> Call to Node.getProperties(String namePattern) processed also child nodes and 
> not only properties.
> This can deteriorate performance when there are lots of children.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCR-4001) When using Node.getProperties(String namePattern) also child nodes are processed

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4001:

Fix Version/s: 2.12.9

> When using Node.getProperties(String namePattern) also child nodes are 
> processed
> 
>
> Key: JCR-4001
> URL: https://issues.apache.org/jira/browse/JCR-4001
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-commons
>Reporter: Luca Tagliani
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_10
> Fix For: 2.18, 2.12.9, 2.14.5, 2.16.1, 2.17.1
>
> Attachments: JCR-4001-2.diff, JCR-4001.patch
>
>
> Call to Node.getProperties(String namePattern) processed also child nodes and 
> not only properties.
> This can deteriorate performance when there are lots of children.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.0

[Davide Giannella]

[X] +1 Release this package as Apache Jackrabbit Oak 1.9.0
D.

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.0

[Manfred Baedke]

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

where

[INFO] Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option 
MaxPermSize=1024m; support was removed in 8.0

[INFO] OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option 
MaxPermSize=1024m; support was removed in 8.0

[INFO] Java version: 1.8.0_162, vendor: Oracle Corporation

Best regards,
Manfred


On 4/23/2018 2:53 PM, Davide Giannella wrote:

A candidate for the Jackrabbit Oak 1.9.0 release is available at:

     https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.9.0/

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


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


The SHA1 checksum of the archive is
72a6d7f297e45f9f7282e96d22235766beef7b29.

A staged Maven repository is available for review at:

     https://repository.apache.org/

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

     # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
     $ sh check-release.sh oak 1.9.0 72a6d7f297e45f9f7282e96d22235766beef7b29

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

     [ ] +1 Release this package as Apache Jackrabbit Oak 1.9.0
     [ ] -1 Do not release this package because...

D.

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.0

[Michael Dürig]

On 23.04.18 14:53, Davide Giannella wrote:

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


Michael

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.0

[Marcel Reutegger]

On 23.04.18 14:53, Davide Giannella wrote:

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

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.0

[Alex Deparvu]

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


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


alex




On Mon, Apr 23, 2018 at 2:53 PM, Davide Giannella  wrote:

> A candidate for the Jackrabbit Oak 1.9.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.9.0/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.9.0/
>
> The SHA1 checksum of the archive is
> 72a6d7f297e45f9f7282e96d22235766beef7b29.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.9.0 72a6d7f297e45f9f7282e96d222357
> 66beef7b29
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.9.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.9.0
> [ ] -1 Do not release this package because...
>
> D.
>

[jira] [Comment Edited] (JCR-3929) ConsistencyCheck may fail on empty repository

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on JCR-3929 at 4/23/18 1:40 PM:
--

trunk: [r1810108|http://svn.apache.org/r1810108]
2.14: [r1813337|http://svn.apache.org/r1813337]
2.12: [r1829886|http://svn.apache.org/r1829886]



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


> ConsistencyCheck may fail on empty repository
> -
>
> Key: JCR-3929
> URL: https://issues.apache.org/jira/browse/JCR-3929
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.7.1
>Reporter: Kamil
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_10, candidate_jcr_2_8
> Fix For: 2.16, 2.15.7, 2.14.4, 2.12.9
>
> Attachments: JCR_3929.patch
>
>
> Creation of fresh repository doesn't work with versions >= 2.7.1
> When I use version 2.6.5 or 2.7.0, remove old repository folder 
> (D:\jackrabbitdocuments), drop/recreate journal database and start the server 
> - everything work correctly. 
> When I switch from 2.7.0 to 2.7.1, remove old repository folder 
> (D:\jackrabbitdocuments), drop/recreate journal database and start the server 
> I obtain following exception:
> {noformat}
> 2015-11-03 13:16:42.568 INFO  [localhost-startStop-1] RepositoryImpl.java:257 
> Starting repository...
> 2015-11-03 13:16:42.578 INFO  [localhost-startStop-1] 
> LocalFileSystem.java:164 LocalFileSystem initialized at path 
> D:\jackrabbitdocuments\repository
> 2015-11-03 13:16:42.696 INFO  [localhost-startStop-1] 
> NodeTypeRegistry.java:870 no custom node type definitions found
> 2015-11-03 13:16:42.974 INFO  [localhost-startStop-1] 
> DatabaseJournal.java:375 Initialized local revision to 0
> 2015-11-03 13:16:42.975 INFO  [localhost-startStop-1] 
> DatabaseJournal.java:384 Cluster revision janitor thread not started
> 2015-11-03 13:16:42.976 INFO  [localhost-startStop-1] 
> DatabaseJournal.java:280 DatabaseJournal initialized.
> 2015-11-03 13:16:42.979 INFO  [localhost-startStop-1] 
> LocalFileSystem.java:164 LocalFileSystem initialized at path 
> D:\jackrabbitdocuments\version
> 2015-11-03 13:16:43.122 ERROR [localhost-startStop-1] RepositoryImpl.java:367 
> failed to start Repository: Cannot instantiate persistence manager 
> org.apache.jackrabbit.core.persistence.pool.PostgreSQLPersistenceManager
> javax.jcr.RepositoryException: Cannot instantiate persistence manager 
> org.apache.jackrabbit.core.persistence.pool.PostgreSQLPersistenceManager
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1354)
>  [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:487)
>  [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:312) 
> [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:590) 
> [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCARepositoryManager.createNonTransientRepository(JCARepositoryManager.java:124)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCARepositoryManager.createRepository(JCARepositoryManager.java:79)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createRepository(JCAManagedConnectionFactory.java:216)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createConnectionFactory(JCAManagedConnectionFactory.java:153)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.springframework.jca.support.LocalConnectionFactoryBean.afterPropertiesSet(LocalConnectionFactoryBean.java:118)
>  [spring-tx-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>  

[jira] [Updated] (JCR-3929) ConsistencyCheck may fail on empty repository

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-3929:

Labels: candidate_jcr_2_10 candidate_jcr_2_8  (was: candidate_jcr_2_10 
candidate_jcr_2_12 candidate_jcr_2_6 candidate_jcr_2_8)

> ConsistencyCheck may fail on empty repository
> -
>
> Key: JCR-3929
> URL: https://issues.apache.org/jira/browse/JCR-3929
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.7.1
>Reporter: Kamil
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_10, candidate_jcr_2_8
> Fix For: 2.16, 2.15.7, 2.14.4, 2.12.9
>
> Attachments: JCR_3929.patch
>
>
> Creation of fresh repository doesn't work with versions >= 2.7.1
> When I use version 2.6.5 or 2.7.0, remove old repository folder 
> (D:\jackrabbitdocuments), drop/recreate journal database and start the server 
> - everything work correctly. 
> When I switch from 2.7.0 to 2.7.1, remove old repository folder 
> (D:\jackrabbitdocuments), drop/recreate journal database and start the server 
> I obtain following exception:
> {noformat}
> 2015-11-03 13:16:42.568 INFO  [localhost-startStop-1] RepositoryImpl.java:257 
> Starting repository...
> 2015-11-03 13:16:42.578 INFO  [localhost-startStop-1] 
> LocalFileSystem.java:164 LocalFileSystem initialized at path 
> D:\jackrabbitdocuments\repository
> 2015-11-03 13:16:42.696 INFO  [localhost-startStop-1] 
> NodeTypeRegistry.java:870 no custom node type definitions found
> 2015-11-03 13:16:42.974 INFO  [localhost-startStop-1] 
> DatabaseJournal.java:375 Initialized local revision to 0
> 2015-11-03 13:16:42.975 INFO  [localhost-startStop-1] 
> DatabaseJournal.java:384 Cluster revision janitor thread not started
> 2015-11-03 13:16:42.976 INFO  [localhost-startStop-1] 
> DatabaseJournal.java:280 DatabaseJournal initialized.
> 2015-11-03 13:16:42.979 INFO  [localhost-startStop-1] 
> LocalFileSystem.java:164 LocalFileSystem initialized at path 
> D:\jackrabbitdocuments\version
> 2015-11-03 13:16:43.122 ERROR [localhost-startStop-1] RepositoryImpl.java:367 
> failed to start Repository: Cannot instantiate persistence manager 
> org.apache.jackrabbit.core.persistence.pool.PostgreSQLPersistenceManager
> javax.jcr.RepositoryException: Cannot instantiate persistence manager 
> org.apache.jackrabbit.core.persistence.pool.PostgreSQLPersistenceManager
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1354)
>  [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:487)
>  [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:312) 
> [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:590) 
> [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCARepositoryManager.createNonTransientRepository(JCARepositoryManager.java:124)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCARepositoryManager.createRepository(JCARepositoryManager.java:79)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createRepository(JCAManagedConnectionFactory.java:216)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createConnectionFactory(JCAManagedConnectionFactory.java:153)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.springframework.jca.support.LocalConnectionFactoryBean.afterPropertiesSet(LocalConnectionFactoryBean.java:118)
>  [spring-tx-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:305)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> 

[jira] [Updated] (JCR-3929) ConsistencyCheck may fail on empty repository

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-3929:

Fix Version/s: 2.12.9

> ConsistencyCheck may fail on empty repository
> -
>
> Key: JCR-3929
> URL: https://issues.apache.org/jira/browse/JCR-3929
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.7.1
>Reporter: Kamil
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_10, candidate_jcr_2_8
> Fix For: 2.16, 2.15.7, 2.14.4, 2.12.9
>
> Attachments: JCR_3929.patch
>
>
> Creation of fresh repository doesn't work with versions >= 2.7.1
> When I use version 2.6.5 or 2.7.0, remove old repository folder 
> (D:\jackrabbitdocuments), drop/recreate journal database and start the server 
> - everything work correctly. 
> When I switch from 2.7.0 to 2.7.1, remove old repository folder 
> (D:\jackrabbitdocuments), drop/recreate journal database and start the server 
> I obtain following exception:
> {noformat}
> 2015-11-03 13:16:42.568 INFO  [localhost-startStop-1] RepositoryImpl.java:257 
> Starting repository...
> 2015-11-03 13:16:42.578 INFO  [localhost-startStop-1] 
> LocalFileSystem.java:164 LocalFileSystem initialized at path 
> D:\jackrabbitdocuments\repository
> 2015-11-03 13:16:42.696 INFO  [localhost-startStop-1] 
> NodeTypeRegistry.java:870 no custom node type definitions found
> 2015-11-03 13:16:42.974 INFO  [localhost-startStop-1] 
> DatabaseJournal.java:375 Initialized local revision to 0
> 2015-11-03 13:16:42.975 INFO  [localhost-startStop-1] 
> DatabaseJournal.java:384 Cluster revision janitor thread not started
> 2015-11-03 13:16:42.976 INFO  [localhost-startStop-1] 
> DatabaseJournal.java:280 DatabaseJournal initialized.
> 2015-11-03 13:16:42.979 INFO  [localhost-startStop-1] 
> LocalFileSystem.java:164 LocalFileSystem initialized at path 
> D:\jackrabbitdocuments\version
> 2015-11-03 13:16:43.122 ERROR [localhost-startStop-1] RepositoryImpl.java:367 
> failed to start Repository: Cannot instantiate persistence manager 
> org.apache.jackrabbit.core.persistence.pool.PostgreSQLPersistenceManager
> javax.jcr.RepositoryException: Cannot instantiate persistence manager 
> org.apache.jackrabbit.core.persistence.pool.PostgreSQLPersistenceManager
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1354)
>  [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:487)
>  [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:312) 
> [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:590) 
> [jackrabbit-core-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCARepositoryManager.createNonTransientRepository(JCARepositoryManager.java:124)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCARepositoryManager.createRepository(JCARepositoryManager.java:79)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createRepository(JCAManagedConnectionFactory.java:216)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createConnectionFactory(JCAManagedConnectionFactory.java:153)
>  [jackrabbit-jca-2.7.1.jar:2.7.1]
>   at 
> org.springframework.jca.support.LocalConnectionFactoryBean.afterPropertiesSet(LocalConnectionFactoryBean.java:118)
>  [spring-tx-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:305)
>  [spring-beans-4.2.0.RELEASE.jar:4.2.0.RELEASE]
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>  

[VOTE] Release Apache Jackrabbit Oak 1.9.0

[Davide Giannella]

A candidate for the Jackrabbit Oak 1.9.0 release is available at:

    https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.9.0/

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

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

The SHA1 checksum of the archive is
72a6d7f297e45f9f7282e96d22235766beef7b29.

A staged Maven repository is available for review at:

    https://repository.apache.org/

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

    # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
    $ sh check-release.sh oak 1.9.0 72a6d7f297e45f9f7282e96d22235766beef7b29

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

    [ ] +1 Release this package as Apache Jackrabbit Oak 1.9.0
    [ ] -1 Do not release this package because...

D.

[jira] [Comment Edited] (JCR-4188) avoid use of sun.security.acl.GroupImpl in PrincipalManagerTest

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on JCR-4188 at 4/23/18 12:27 PM:
---

trunk: [r1809329|http://svn.apache.org/r1809329]
2.14: [r1813270|http://svn.apache.org/r1813270]
2.12: [r1829861|http://svn.apache.org/r1829861]



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


> avoid use of sun.security.acl.GroupImpl in PrincipalManagerTest
> ---
>
> Key: JCR-4188
> URL: https://issues.apache.org/jira/browse/JCR-4188
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.15.6
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_10, candidate_jcr_2_8
> Fix For: 2.16, 2.15.7, 2.14.4, 2.12.9
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCR-4188) avoid use of sun.security.acl.GroupImpl in PrincipalManagerTest

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4188:

Fix Version/s: 2.12.9

> avoid use of sun.security.acl.GroupImpl in PrincipalManagerTest
> ---
>
> Key: JCR-4188
> URL: https://issues.apache.org/jira/browse/JCR-4188
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.15.6
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_10, candidate_jcr_2_8
> Fix For: 2.16, 2.15.7, 2.14.4, 2.12.9
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCR-4188) avoid use of sun.security.acl.GroupImpl in PrincipalManagerTest

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4188:

Labels: candidate_jcr_2_10 candidate_jcr_2_8  (was: candidate_jcr_2_10 
candidate_jcr_2_12 candidate_jcr_2_6 candidate_jcr_2_8)

> avoid use of sun.security.acl.GroupImpl in PrincipalManagerTest
> ---
>
> Key: JCR-4188
> URL: https://issues.apache.org/jira/browse/JCR-4188
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.15.6
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_10, candidate_jcr_2_8
> Fix For: 2.16, 2.15.7, 2.14.4, 2.12.9
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

BUILD FAILURE: Jackrabbit Oak - Build # 1391 - Failure

[Apache Jenkins Server]

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

Status: Failure

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

Changes:
[mreutegg] OAK-7401: Changes kept in memory when update limit is hit in commit 
hook

 

Test results:
All tests passed

Re: Environment-specific, non-role-based configurations

[Jörg Hoh]

Hi Georg

2018-04-04 23:55 GMT+02:00 Georg Henzler :



> Possible solutions:
>
> 1. Generate a package with the configurations for a particular environment
> on the fly using your favourite provisioning toolchain
> (AWS/Chef/Puppet/Jenkins etc.) - merging of SW-delivered configs with
> generated configs is error-prone, you reinvent the wheel depending on what
> toolchain you are using (or you have to use for a particular client)
>


I consider this option 1 the most feasible way. Because the infrastructure
for provisioning is already there and you just need to get the
configuration into the system. Of course this way could and should be
optimized. I could imagine to have maven tooling which creates a vlt
package from an INI-style configuration file (assuming that every toolchain
is able to dump the configuration into such a file quite easily).



>
> 2. Tweak the configurations directly on system via REST calls - fairly
> complex to implement and make changes to, troubleshooting of why a system
> is configured as is might be hard
>
> 3. Use an install hook to apply env specific values - IMHO currently the
> best available option, follows the approach [2], see [3] for an install
> hook that can be quickly introduced to a project and is provisioning tool
> independent. Downside: JVM restart required for OS env var changes and
> package installation to apply them ([3] has some configuration options for
> that though)
>
> 4. Introduce a filtering mechanism in FileVault (like JCRVLT-254
> suggested) - not available at the moment, could work similar to 3
>
> 5. Use a distributed configuration service like ZooKeeper - can be nice to
> keep the env-specific configuration of all systems of one environment in
> one place, but fairly complicated to integrate ([3] has POC-level support
> for it)
>
> 6. Use install folder to put *.config files - does not work well to
> overwrite existing configurations, does not work for replication agents
>
> 7. Introduce a lower level mechanism that works on OSGi level, this could
> e.g. provide certain values for PID/propertyName as system properties that
> would then take higher priority than anything else (like config sets coming
> from JCR). I'm not aware of such a mechanism in OSGi, but maybe something
> like that already exists?
>
>

8. Use Sling Context-Aware configuration and implement a custom override
mechanism (
http://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-override.html);
this will not cover OSGI-based configuration, but with the growing level of
maturity of CA-Config we could get away from storing ever "configuration"
in OSGI.




> What solution do you use today?
> What would be the best solution for the problem?
>


I don't think that there is a single best solution to this problem; but we
have now 8 approaches outlined, and that's too much. If we could narrow it
down to a few, we could implement them all and let the user choose which
one is the best for that special case. But we should give clear guidance
about the pro's and con's of each approach.


Jörg

-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh