[jira] [Updated] (JCR-4946) Cleanup lock discovery and add test cases for the case sensitivity of lock tokens
[ https://issues.apache.org/jira/browse/JCR-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4946: Description: The method ActiveLock#isLockedByToken(String lockToken) is implemented at several places, but only needs one implementation in AbstractActiveLock. (was: The method ActiveLock#isLockedByToken(String lockToken) is implemented ) > Cleanup lock discovery and add test cases for the case sensitivity of lock > tokens > - > > Key: JCR-4946 > URL: https://issues.apache.org/jira/browse/JCR-4946 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4946) Cleanup lock discovery and add test cases for the case sensitivity of lock tokens
[ https://issues.apache.org/jira/browse/JCR-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4946: Description: The method ActiveLock#isLockedByToken(String lockToken) is implemented > Cleanup lock discovery and add test cases for the case sensitivity of lock > tokens > - > > Key: JCR-4946 > URL: https://issues.apache.org/jira/browse/JCR-4946 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > The method ActiveLock#isLockedByToken(String lockToken) is implemented -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4946) Cleanup lock discovery and add test cases for the case sensitivity of lock tokens
[ https://issues.apache.org/jira/browse/JCR-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4946: Summary: Cleanup lock discovery and add test cases for the case sensitivity of lock tokens (was: Cleanup Lock Discovery and add test cases for the case sensitivity of lock tokens) > Cleanup lock discovery and add test cases for the case sensitivity of lock > tokens > - > > Key: JCR-4946 > URL: https://issues.apache.org/jira/browse/JCR-4946 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-4946) Cleanup Lock Discovery and add test cases for the case sensitivity of lock tokens
Manfred Baedke created JCR-4946: --- Summary: Cleanup Lock Discovery and add test cases for the case sensitivity of lock tokens Key: JCR-4946 URL: https://issues.apache.org/jira/browse/JCR-4946 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-webdav Reporter: Manfred Baedke Assignee: Manfred Baedke -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4943) Update Tika dependency to 2.5.0 (or newer)
[ https://issues.apache.org/jira/browse/JCR-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739094#comment-17739094 ] Manfred Baedke commented on JCR-4943: - At least, JCR-4945 will make Jackrabbit run with slf4j4j [1.7.36, 2.0.7], Tika [2.4.1, 2.8.0] and hopefully also upcoming minor versions of both. > Update Tika dependency to 2.5.0 (or newer) > -- > > Key: JCR-4943 > URL: https://issues.apache.org/jira/browse/JCR-4943 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Fix For: 2.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4352) Update lucene-core dependency to 3.6.2
[ https://issues.apache.org/jira/browse/JCR-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739091#comment-17739091 ] Manfred Baedke commented on JCR-4352: - Updating to Lucene 4 seems actually to be not trivial at all. Find attached a patch that at least updates to Lucene 3.6.2. > Update lucene-core dependency to 3.6.2 > -- > > Key: JCR-4352 > URL: https://issues.apache.org/jira/browse/JCR-4352 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: core >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4352.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4352) Update lucene-core dependency to 3.6.2
[ https://issues.apache.org/jira/browse/JCR-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4352: Attachment: jcr-4352.patch Status: Patch Available (was: Open) > Update lucene-core dependency to 3.6.2 > -- > > Key: JCR-4352 > URL: https://issues.apache.org/jira/browse/JCR-4352 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: core >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4352.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCR-4352) Update lucene-core dependency to 3.6.2
[ https://issues.apache.org/jira/browse/JCR-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-4352: --- Assignee: Manfred Baedke > Update lucene-core dependency to 3.6.2 > -- > > Key: JCR-4352 > URL: https://issues.apache.org/jira/browse/JCR-4352 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: core >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Attachment: jcr-4945.patch Status: Patch Available (was: Open) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Attachment: (was: jcr-4945.patch) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Status: Open (was: Patch Available) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Attachment: (was: jcr-4945.patch) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Attachment: jcr-4945.patch Status: Patch Available (was: Open) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Status: Open (was: Patch Available) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Attachment: (was: jcr-4945-1.patch) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Attachment: jcr-4945-1.patch Status: Patch Available (was: In Progress) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Attachment: jcr-4945.patch Status: Patch Available (was: Open) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Attachment: (was: jcr-4945.patch) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Status: Open (was: Patch Available) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4945) Ensure jackrabbit-server and jackrabbit-webdav deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738052#comment-17738052 ] Manfred Baedke edited comment on JCR-4945 at 6/28/23 11:11 AM: --- Attached proposal is a bit clumsy, since the three test classes only vary in the method #configure(). It might be possible to use just one parametrized test class, but I don't know how to do that with pax-exam. was (Author: baedke): Attached proposal is a bit clumsy, since the three test classes only vary in the method #configure(). It aight be possible to use just one parametrized test class, but I don't know how to do that with pax-exam. > Ensure jackrabbit-server and jackrabbit-webdav deploy in environments > featuring only Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Summary: Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only Slf4j v2 or even Tika v2.8 (was: Ensure jackrabbit-server and jackrabbit-webdav deploy in environments featuring only Slf4j v2 or even Tika v2.8) > Ensure OSGi-enabled Jackrabbit bundles deploy in environments featuring only > Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4945) Ensure jackrabbit-server and jackrabbit-webdav deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738052#comment-17738052 ] Manfred Baedke commented on JCR-4945: - Attached proposal is a bit clumsy, since the three test classes only vary in the method #configure(). It aight be possible to use just one parametrized test class, but I don't know how to do that with pax-exam. > Ensure jackrabbit-server and jackrabbit-webdav deploy in environments > featuring only Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4945) Ensure jackrabbit-server and jackrabbit-webdav deploy in environments featuring only Slf4j v2 or even Tika v2.8
[ https://issues.apache.org/jira/browse/JCR-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4945: Attachment: jcr-4945.patch > Ensure jackrabbit-server and jackrabbit-webdav deploy in environments > featuring only Slf4j v2 or even Tika v2.8 > --- > > Key: JCR-4945 > URL: https://issues.apache.org/jira/browse/JCR-4945 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-it-osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4945.patch > > > While Jackrabbit only requires slf4j-1.7, it should also run with slf4j > >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-4945) Ensure jackrabbit-server and jackrabbit-webdav deploy in environments featuring only Slf4j v2 or even Tika v2.8
Manfred Baedke created JCR-4945: --- Summary: Ensure jackrabbit-server and jackrabbit-webdav deploy in environments featuring only Slf4j v2 or even Tika v2.8 Key: JCR-4945 URL: https://issues.apache.org/jira/browse/JCR-4945 Project: Jackrabbit Content Repository Issue Type: Test Components: jackrabbit-it-osgi Reporter: Manfred Baedke Assignee: Manfred Baedke While Jackrabbit only requires slf4j-1.7, it should also run with slf4j >=2.0.0 and even tika-core >=2.5 (which requires slf4j-api-2.0.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4627) jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central
[ https://issues.apache.org/jira/browse/JCR-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737029#comment-17737029 ] Manfred Baedke edited comment on JCR-4627 at 6/26/23 7:50 AM: -- I tried [exam-4.13.2.diff|https://issues.apache.org/jira/secure/attachment/13041676/exam-4.13.2.diff] and had no issues with hanging tests. It indeed solved the http/https problem. was (Author: baedke): I tried [^exam-4.13.2.diff] and had no issues with hanging tests. It indeed solved the http/https problem. > jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central > --- > > Key: JCR-4627 > URL: https://issues.apache.org/jira/browse/JCR-4627 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-it-osgi >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > > As seen in: > [ERROR] org.apache.jackrabbit.oak.osgi.OSGiIT Time elapsed: 6.219 s <<< > ERROR! > org.ops4j.pax.exam.TestContainerException: > [link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link] could not be > downloaded > Caused by: java.io.IOException: Error resolving artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0: Could not transfer artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0 from/to central > (http://repo1.maven.org/maven2/): Error transferring file: Server returned > HTTP response code: 501 for URL: > http://repo1.maven.org/maven2/org/ops4j/pax/exam/pax-exam-inject/3.4.0/pax-exam-inject-3.4.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4627) jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central
[ https://issues.apache.org/jira/browse/JCR-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737029#comment-17737029 ] Manfred Baedke edited comment on JCR-4627 at 6/26/23 7:48 AM: -- I tried [^exam-4.13.2.diff] and had no issues with hanging tests. It indeed solved the http/https problem. was (Author: baedke): I tried [exam-4.13.2.diff|https://issues.apache.org/jira/secure/attachment/13041676/exam-4.13.2.diff] and had no issues with hanging tests. > jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central > --- > > Key: JCR-4627 > URL: https://issues.apache.org/jira/browse/JCR-4627 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-it-osgi >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > > As seen in: > [ERROR] org.apache.jackrabbit.oak.osgi.OSGiIT Time elapsed: 6.219 s <<< > ERROR! > org.ops4j.pax.exam.TestContainerException: > [link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link] could not be > downloaded > Caused by: java.io.IOException: Error resolving artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0: Could not transfer artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0 from/to central > (http://repo1.maven.org/maven2/): Error transferring file: Server returned > HTTP response code: 501 for URL: > http://repo1.maven.org/maven2/org/ops4j/pax/exam/pax-exam-inject/3.4.0/pax-exam-inject-3.4.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4627) jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central
[ https://issues.apache.org/jira/browse/JCR-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737029#comment-17737029 ] Manfred Baedke edited comment on JCR-4627 at 6/26/23 7:47 AM: -- I tried [exam-4.13.2.diff|https://issues.apache.org/jira/secure/attachment/13041676/exam-4.13.2.diff] and had no issues with hanging tests. was (Author: baedke): I tried the [^exam-4.13.2.diff] and had no issues with hanging tests. > jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central > --- > > Key: JCR-4627 > URL: https://issues.apache.org/jira/browse/JCR-4627 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-it-osgi >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > > As seen in: > [ERROR] org.apache.jackrabbit.oak.osgi.OSGiIT Time elapsed: 6.219 s <<< > ERROR! > org.ops4j.pax.exam.TestContainerException: > [link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link] could not be > downloaded > Caused by: java.io.IOException: Error resolving artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0: Could not transfer artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0 from/to central > (http://repo1.maven.org/maven2/): Error transferring file: Server returned > HTTP response code: 501 for URL: > http://repo1.maven.org/maven2/org/ops4j/pax/exam/pax-exam-inject/3.4.0/pax-exam-inject-3.4.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4627) jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central
[ https://issues.apache.org/jira/browse/JCR-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737029#comment-17737029 ] Manfred Baedke edited comment on JCR-4627 at 6/26/23 7:46 AM: -- I tried the [^exam-4.13.2.diff] and had no issues with hanging tests. was (Author: baedke): I tried the [^exam-4.13.2.diff] and had no issues with hanging tests. > jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central > --- > > Key: JCR-4627 > URL: https://issues.apache.org/jira/browse/JCR-4627 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-it-osgi >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > > As seen in: > [ERROR] org.apache.jackrabbit.oak.osgi.OSGiIT Time elapsed: 6.219 s <<< > ERROR! > org.ops4j.pax.exam.TestContainerException: > [link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link] could not be > downloaded > Caused by: java.io.IOException: Error resolving artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0: Could not transfer artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0 from/to central > (http://repo1.maven.org/maven2/): Error transferring file: Server returned > HTTP response code: 501 for URL: > http://repo1.maven.org/maven2/org/ops4j/pax/exam/pax-exam-inject/3.4.0/pax-exam-inject-3.4.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4627) jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central
[ https://issues.apache.org/jira/browse/JCR-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737029#comment-17737029 ] Manfred Baedke commented on JCR-4627: - I tried the [^exam-4.13.2.diff] and had no issues with hanging tests. > jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central > --- > > Key: JCR-4627 > URL: https://issues.apache.org/jira/browse/JCR-4627 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-it-osgi >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > > As seen in: > [ERROR] org.apache.jackrabbit.oak.osgi.OSGiIT Time elapsed: 6.219 s <<< > ERROR! > org.ops4j.pax.exam.TestContainerException: > [link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link] could not be > downloaded > Caused by: java.io.IOException: Error resolving artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0: Could not transfer artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0 from/to central > (http://repo1.maven.org/maven2/): Error transferring file: Server returned > HTTP response code: 501 for URL: > http://repo1.maven.org/maven2/org/ops4j/pax/exam/pax-exam-inject/3.4.0/pax-exam-inject-3.4.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCR-4627) jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central
[ https://issues.apache.org/jira/browse/JCR-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-4627: --- Assignee: Manfred Baedke (was: Julian Reschke) > jackrabbit-it-osgi: pax-exam fails to load artefacts from maven central > --- > > Key: JCR-4627 > URL: https://issues.apache.org/jira/browse/JCR-4627 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-it-osgi >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > > As seen in: > [ERROR] org.apache.jackrabbit.oak.osgi.OSGiIT Time elapsed: 6.219 s <<< > ERROR! > org.ops4j.pax.exam.TestContainerException: > [link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link] could not be > downloaded > Caused by: java.io.IOException: Error resolving artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0: Could not transfer artifact > org.ops4j.pax.exam:pax-exam-inject:jar:3.4.0 from/to central > (http://repo1.maven.org/maven2/): Error transferring file: Server returned > HTTP response code: 501 for URL: > http://repo1.maven.org/maven2/org/ops4j/pax/exam/pax-exam-inject/3.4.0/pax-exam-inject-3.4.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCR-4773) upgrade pax-exam test dependency
[ https://issues.apache.org/jira/browse/JCR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-4773: --- Assignee: Manfred Baedke (was: Julian Reschke) > upgrade pax-exam test dependency > > > Key: JCR-4773 > URL: https://issues.apache.org/jira/browse/JCR-4773 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: test >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: exam-4.13.2.diff, patch-for-185.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4606) standalone: logback log files created in wrong place
[ https://issues.apache.org/jira/browse/JCR-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735231#comment-17735231 ] Manfred Baedke edited comment on JCR-4606 at 6/20/23 10:35 AM: --- Doesn't work because we are trying to set the relevant system properties only after the logging framework is initialized. [PR#136|https://github.com/apache/jackrabbit/pull/136] will set the system properties in the static main method, immediately after parsing the command line. Also it will only touch them if they haven't already been set, which was not the case before. was (Author: baedke): Doesn't work because we are trying to set the relevant system properties only after the logging framework is initialized. [PR#136|https://github.com/apache/jackrabbit/pull/136] will set the system properties in the static main method, immediately after parsing the command line. Also it will only touch them if they haven't been already set, which was not the case before. > standalone: logback log files created in wrong place > > > Key: JCR-4606 > URL: https://issues.apache.org/jira/browse/JCR-4606 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-standalone >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > > Main.java sets system properties for the log files, but apparently they are > not seen when logback.xml is evaluated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4606) standalone: logback log files created in wrong place
[ https://issues.apache.org/jira/browse/JCR-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735231#comment-17735231 ] Manfred Baedke commented on JCR-4606: - Doesn't work because we are trying to set the relevant system properties only after the logging framework is initialized. [PR#136|https://github.com/apache/jackrabbit/pull/136] will set the system properties in the static main method, immediately after parsing the command line. Also it will only touch them if they haven't been already set, which was not the case before. > standalone: logback log files created in wrong place > > > Key: JCR-4606 > URL: https://issues.apache.org/jira/browse/JCR-4606 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-standalone >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > > Main.java sets system properties for the log files, but apparently they are > not seend when logback.xml is evaluated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-4305) jackrabbit-standalone JSP does not work with Java 10
[
https://issues.apache.org/jira/browse/JCR-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke resolved JCR-4305.
-
Resolution: Fixed
> jackrabbit-standalone JSP does not work with Java 10
>
>
> Key: JCR-4305
> URL: https://issues.apache.org/jira/browse/JCR-4305
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-standalone
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Major
>
> I get:
> {noformat}
> HTTP ERROR 500
> Problem accessing /. Reason:
> Server Error
> Caused by:
> org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP
> at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:634)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
> at
> org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:595)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:191)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:72)
> at
> org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:588)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.base/java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at java.compiler@10/javax.tools.ToolProvider.lambda$matches$0(Unknown
> Source)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.compiler@10/javax.tools.ToolProvider.matches(Unknown Source)
> at java.compiler@10/javax.tools.ToolProvider.getSystemTool(Unknown
> Source)
> at
> java.compiler@10/javax.tools.ToolProvider.getSystemJavaCompiler(Unknown
> Source)
> at
>
[jira] [Commented] (JCR-4305) jackrabbit-standalone JSP does not work with Java 10
[
https://issues.apache.org/jira/browse/JCR-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17734049#comment-17734049
]
Manfred Baedke commented on JCR-4305:
-
GitHub
[37ede49|https://github.com/apache/jackrabbit/commit/37ede49f7161bf627c5ed3b50202184d7111f38c]
svn [r1910469|http://svn.apache.org/viewvc?view=revision=1910469]
> jackrabbit-standalone JSP does not work with Java 10
>
>
> Key: JCR-4305
> URL: https://issues.apache.org/jira/browse/JCR-4305
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-standalone
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Major
>
> I get:
> {noformat}
> HTTP ERROR 500
> Problem accessing /. Reason:
> Server Error
> Caused by:
> org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP
> at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:634)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
> at
> org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:595)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:191)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:72)
> at
> org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:588)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.base/java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at java.compiler@10/javax.tools.ToolProvider.lambda$matches$0(Unknown
> Source)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.compiler@10/javax.tools.ToolProvider.matches(Unknown Source)
> at java.compiler@10/javax.tools.ToolProvider.getSystemTool(Unknown
>
[jira] [Comment Edited] (JCR-4305) jackrabbit-standalone JSP does not work with Java 10
[
https://issues.apache.org/jira/browse/JCR-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733489#comment-17733489
]
Manfred Baedke edited comment on JCR-4305 at 6/19/23 7:49 AM:
--
Will be resolved with
[PR135|https://github.com/apache/jackrabbit/pull/135],which was created for
JCR-4308.
was (Author: baedke):
Will be resolved with [https://github.com/apache/jackrabbit/pull/135
|https://github.com/apache/jackrabbit/pull/135,] ,which was created for
JCR-4308.
> jackrabbit-standalone JSP does not work with Java 10
>
>
> Key: JCR-4305
> URL: https://issues.apache.org/jira/browse/JCR-4305
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-standalone
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Major
>
> I get:
> {noformat}
> HTTP ERROR 500
> Problem accessing /. Reason:
> Server Error
> Caused by:
> org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP
> at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:634)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
> at
> org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:595)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:191)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:72)
> at
> org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:588)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.base/java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at java.compiler@10/javax.tools.ToolProvider.lambda$matches$0(Unknown
> Source)
> at java.base/java.security.AccessController.doPrivileged(Native
[jira] [Comment Edited] (JCR-4305) jackrabbit-standalone JSP does not work with Java 10
[
https://issues.apache.org/jira/browse/JCR-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733489#comment-17733489
]
Manfred Baedke edited comment on JCR-4305 at 6/19/23 7:47 AM:
--
Will be resolved with [https://github.com/apache/jackrabbit/pull/135
|https://github.com/apache/jackrabbit/pull/135,] ,which was created for
JCR-4308.
was (Author: baedke):
Will be resolved with [https://github.com/apache/jackrabbit/pull/135,] which
was created for JCR-4308.
> jackrabbit-standalone JSP does not work with Java 10
>
>
> Key: JCR-4305
> URL: https://issues.apache.org/jira/browse/JCR-4305
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-standalone
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Major
>
> I get:
> {noformat}
> HTTP ERROR 500
> Problem accessing /. Reason:
> Server Error
> Caused by:
> org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP
> at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:634)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
> at
> org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:595)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:191)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:72)
> at
> org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:588)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.base/java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at java.compiler@10/javax.tools.ToolProvider.lambda$matches$0(Unknown
> Source)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
[jira] [Commented] (JCR-4305) jackrabbit-standalone JSP does not work with Java 10
[
https://issues.apache.org/jira/browse/JCR-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733489#comment-17733489
]
Manfred Baedke commented on JCR-4305:
-
Will be resolved with [https://github.com/apache/jackrabbit/pull/135,] which
was created for JCR-4308.
> jackrabbit-standalone JSP does not work with Java 10
>
>
> Key: JCR-4305
> URL: https://issues.apache.org/jira/browse/JCR-4305
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-standalone
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Major
>
> I get:
> {noformat}
> HTTP ERROR 500
> Problem accessing /. Reason:
> Server Error
> Caused by:
> org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP
> at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:634)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
> at
> org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:595)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:191)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:72)
> at
> org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:588)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.base/java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at java.compiler@10/javax.tools.ToolProvider.lambda$matches$0(Unknown
> Source)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.compiler@10/javax.tools.ToolProvider.matches(Unknown Source)
> at java.compiler@10/javax.tools.ToolProvider.getSystemTool(Unknown
> Source)
> at
>
[jira] [Assigned] (JCR-4305) jackrabbit-standalone JSP does not work with Java 10
[
https://issues.apache.org/jira/browse/JCR-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke reassigned JCR-4305:
---
Assignee: Manfred Baedke
> jackrabbit-standalone JSP does not work with Java 10
>
>
> Key: JCR-4305
> URL: https://issues.apache.org/jira/browse/JCR-4305
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-standalone
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Major
>
> I get:
> {noformat}
> HTTP ERROR 500
> Problem accessing /. Reason:
> Server Error
> Caused by:
> org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP
> at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:634)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
> at
> org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:595)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:191)
> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:72)
> at
> org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:588)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.base/java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at java.compiler@10/javax.tools.ToolProvider.lambda$matches$0(Unknown
> Source)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.compiler@10/javax.tools.ToolProvider.matches(Unknown Source)
> at java.compiler@10/javax.tools.ToolProvider.getSystemTool(Unknown
> Source)
> at
> java.compiler@10/javax.tools.ToolProvider.getSystemJavaCompiler(Unknown
> Source)
> at
>
[jira] [Commented] (JCR-4308) update Jetty to 9.4.*
[ https://issues.apache.org/jira/browse/JCR-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733483#comment-17733483 ] Manfred Baedke commented on JCR-4308: - See https://github.com/apache/jackrabbit/pull/135. > update Jetty to 9.4.* > - > > Key: JCR-4308 > URL: https://issues.apache.org/jira/browse/JCR-4308 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Attachments: JCR-4308-2.diff, JCR-4308-3.diff, JCR-4308.diff, > jetty.log > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-447) Add AbstractExporter implementation to export a single node
[ https://issues.apache.org/jira/browse/JCRVLT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150520#comment-17150520 ] Manfred Baedke commented on JCRVLT-447: --- [~tripod], The point of the change is to speed up or simplify Vault sync operations (in this case getting a single modified node to the local file system), so it's meant to be platform code, not project code. Of course we could extract the package and pick the .content.xml, but it seems unnecessarily cumbersome. > Add AbstractExporter implementation to export a single node > --- > > Key: JCRVLT-447 > URL: https://issues.apache.org/jira/browse/JCRVLT-447 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Reporter: Manfred Baedke >Priority: Minor > > Sometimes it may be convenient to not export a full package, but only the > system view of the requested node. I propose adding a suitable > AbstractExporter implementation as linked below. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-447) Add AbstractExporter implementation to export a single node
[ https://issues.apache.org/jira/browse/JCRVLT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147827#comment-17147827 ] Manfred Baedke commented on JCRVLT-447: --- [~tripod], I don't quite get it, that's the PackageManagerImpl code from the repo and from the patch united. Are you saying that the patch makes sense? > Add AbstractExporter implementation to export a single node > --- > > Key: JCRVLT-447 > URL: https://issues.apache.org/jira/browse/JCRVLT-447 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Reporter: Manfred Baedke >Priority: Minor > > Sometimes it may be convenient to not export a full package, but only the > system view of the requested node. I propose adding a suitable > AbstractExporter implementation as linked below. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-447) Add AbstractExporter implementation to export a single node
[
https://issues.apache.org/jira/browse/JCRVLT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17145061#comment-17145061
]
Manfred Baedke commented on JCRVLT-447:
---
[~tripod], [~kwin],
I tried using
{code}
DefaultWorkspaceFilter defaultWorkspaceFilter = new
DefaultWorkspaceFilter();
PathFilterSet pathFilterSet = new PathFilterSet("/");
try {
pathFilterSet.addExclude(new DefaultPathFilter("/.*"));
} catch (ConfigurationException e) {
//should never happen
throw new IOException("Could not create path filter for
pattern '/.*'", e);
}
defaultWorkspaceFilter.add(pathFilterSet);
{code}
which works for folders, but for leaves I don't get the content, just meta-inf.
Any idea why? Also, of course, we'd need exactly the .content.xml, so we'd have
to extract it from the assembled package without this patch.
> Add AbstractExporter implementation to export a single node
> ---
>
> Key: JCRVLT-447
> URL: https://issues.apache.org/jira/browse/JCRVLT-447
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Misc
>Reporter: Manfred Baedke
>Priority: Minor
>
> Sometimes it may be convenient to not export a full package, but only the
> system view of the requested node. I propose adding a suitable
> AbstractExporter implementation as linked below.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCR-4570) WebdavRequestImpl does not check ETags if there is no resource or no exclusive write lock
[ https://issues.apache.org/jira/browse/JCR-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4570: Description: Also other lock types are completely ignored. > WebdavRequestImpl does not check ETags if there is no resource or no > exclusive write lock > - > > Key: JCR-4570 > URL: https://issues.apache.org/jira/browse/JCR-4570 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-webdav >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4570.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4570) WebdavRequestImpl does not check ETags if there is no resource or no exclusive write lock
[ https://issues.apache.org/jira/browse/JCR-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4570: Attachment: JCR-4570.patch > WebdavRequestImpl does not check ETags if there is no resource or no > exclusive write lock > - > > Key: JCR-4570 > URL: https://issues.apache.org/jira/browse/JCR-4570 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-webdav >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4570.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4571) WebdavRequestImpl stores If-Header values using either absolute URIs or absolute paths, but both may be used for lookup
[ https://issues.apache.org/jira/browse/JCR-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4571: Attachment: (was: JCR-4571.patch) > WebdavRequestImpl stores If-Header values using either absolute URIs or > absolute paths, but both may be used for lookup > --- > > Key: JCR-4571 > URL: https://issues.apache.org/jira/browse/JCR-4571 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-webdav >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4571) WebdavRequestImpl stores If-Header values using either absolute URIs or absolute paths, but both may be used for lookup
[ https://issues.apache.org/jira/browse/JCR-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4571: Attachment: JCR-4571.patch > WebdavRequestImpl stores If-Header values using either absolute URIs or > absolute paths, but both may be used for lookup > --- > > Key: JCR-4571 > URL: https://issues.apache.org/jira/browse/JCR-4571 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-webdav >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4571.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4571) WebdavRequestImpl stores If-Header values using either absolute URIs or absolute paths, but both may be used for lookup
[ https://issues.apache.org/jira/browse/JCR-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4571: Attachment: JCR-4571.patch > WebdavRequestImpl stores If-Header values using either absolute URIs or > absolute paths, but both may be used for lookup > --- > > Key: JCR-4571 > URL: https://issues.apache.org/jira/browse/JCR-4571 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-webdav >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4571.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved JCR-4169. - Resolution: Done > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch, JCR-4169.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117034#comment-17117034 ] Manfred Baedke edited comment on JCR-4169 at 5/26/20, 9:10 PM: --- Done: http://svn.apache.org/viewvc?diff_format=h=revision=1878136 Added issue refs for failing tests: http://svn.apache.org/viewvc?diff_format=h=revision=1878137 was (Author: baedke): Done: http://svn.apache.org/viewvc?diff_format=h=revision=1878136 > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch, JCR-4169.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4571) WebdavRequestImpl stores If-Header values using either absolute URIs or absolute paths, but both may be used for lookup
[ https://issues.apache.org/jira/browse/JCR-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4571: Summary: WebdavRequestImpl stores If-Header values using either absolute URIs or absolute paths, but both may be used for lookup (was: WebdavRequestImpl stores If-Header values using either absolute URIs or absolute paths, but both may be used for lookup.) > WebdavRequestImpl stores If-Header values using either absolute URIs or > absolute paths, but both may be used for lookup > --- > > Key: JCR-4571 > URL: https://issues.apache.org/jira/browse/JCR-4571 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-webdav >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JCR-4571) WebdavRequestImpl stores If-Header values using either absolute URIs or absolute paths, but both may be used for lookup.
Manfred Baedke created JCR-4571: --- Summary: WebdavRequestImpl stores If-Header values using either absolute URIs or absolute paths, but both may be used for lookup. Key: JCR-4571 URL: https://issues.apache.org/jira/browse/JCR-4571 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-webdav Reporter: Manfred Baedke Assignee: Manfred Baedke -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JCR-4570) WebdavRequestImpl does not check ETags if there is no resource or no exclusive write lock
Manfred Baedke created JCR-4570: --- Summary: WebdavRequestImpl does not check ETags if there is no resource or no exclusive write lock Key: JCR-4570 URL: https://issues.apache.org/jira/browse/JCR-4570 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-webdav Reporter: Manfred Baedke Assignee: Manfred Baedke -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117034#comment-17117034 ] Manfred Baedke commented on JCR-4169: - Done: http://svn.apache.org/viewvc?diff_format=h=revision=1878136 > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch, JCR-4169.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116754#comment-17116754 ] Manfred Baedke commented on JCR-4169: - Updated JCR-4169.patch, getting rid of unused imports and the obsolete JavaDoc. My working copy is using moves. > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch, JCR-4169.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4169: Attachment: JCR-4169.patch > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch, JCR-4169.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4169: Attachment: (was: JCR-4169.patch) > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116217#comment-17116217 ] Manfred Baedke edited comment on JCR-4169 at 5/25/20, 7:54 PM: --- [~reschke], see JCR-4169.patch. Added RFC4918IfHeaderTest as known issue, I'll open separate issues for that. Patch contains: * Trivial changes to existing WebDAV tests. * Moved server tests from jackrabbit-webdav to jackrabbit jcr-server to avoid a cyclic dependency. * Made server tests start their own WebDAV server. * Added connection handling * Marked RFC4918IfHeaderTest as known failure because actually there are issues with the If -Header treatment of the WebDAV servlets. was (Author: baedke): [~reschke], see JCR-4169.patch. Added RFC4918IfHeaderTest as known issue, I'll open separate issues for that. > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch, JCR-4169.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116217#comment-17116217 ] Manfred Baedke commented on JCR-4169: - [~reschke], see JCR-4169.patch. Added RFC4918IfHeaderTest as known issue, I'll open separate issues for that. > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch, JCR-4169.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4169: Attachment: JCR-4169.patch > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch, JCR-4169.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114381#comment-17114381 ] Manfred Baedke commented on JCR-4169: - Updated JCR-4158-prelimary.patch. > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4169: Attachment: JCR-4158-prelimary.patch > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4169: Attachment: (was: JCR-4158-prelimary.patch) > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112574#comment-17112574 ] Manfred Baedke commented on JCR-4169: - [~reschke], please take a look at JCR-4158-prelimary.patch. It contains proposed changes to jackrabbit-webdav necessary to make RFC4918IfHeaderTest pass. If these make sense I'll open a new issue for them. Please review. > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4169: Attachment: JCR-4158-prelimary.patch > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > Attachments: JCR-4158-prelimary.patch > > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (JCR-4169) make WebdavServerTests run automatically
[ https://issues.apache.org/jira/browse/JCR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-4169: --- Assignee: Manfred Baedke > make WebdavServerTests run automatically > > > Key: JCR-4169 > URL: https://issues.apache.org/jira/browse/JCR-4169 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Minor > > These tests aren't currently run automatically, as they require a separate > jackrabbit-standalone instance running. > Consider starting this up as part of the test fixture. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JCR-4535) Test the automatic deletion of version history nodes when all versions are gone.
[ https://issues.apache.org/jira/browse/JCR-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052261#comment-17052261 ] Manfred Baedke edited comment on JCR-4535 at 3/5/20, 3:32 PM: -- This test already exists: http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/test/java/org/apache/jackrabbit/core/version/RemoveOrphanVersionHistoryTest.java?revision=791180=markup. Resolving as invalid. was (Author: baedke): This test already exists: org.apache.jackrabbit.core.version.RemoveOrphanVersionHistoryTest. Resolving as invalid. > Test the automatic deletion of version history nodes when all versions are > gone. > > > Key: JCR-4535 > URL: https://issues.apache.org/jira/browse/JCR-4535 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > This behavior is not specified by JCR, but should be kept stable across > Jackrabbit/Oak versions for compatibility (see OAK-8048). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCR-4535) Test the automatic deletion of version history nodes when all versions are gone.
[ https://issues.apache.org/jira/browse/JCR-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke closed JCR-4535. --- > Test the automatic deletion of version history nodes when all versions are > gone. > > > Key: JCR-4535 > URL: https://issues.apache.org/jira/browse/JCR-4535 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > This behavior is not specified by JCR, but should be kept stable across > Jackrabbit/Oak versions for compatibility (see OAK-8048). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCR-4535) Test the automatic deletion of version history nodes when all versions are gone.
[ https://issues.apache.org/jira/browse/JCR-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved JCR-4535. - Resolution: Invalid > Test the automatic deletion of version history nodes when all versions are > gone. > > > Key: JCR-4535 > URL: https://issues.apache.org/jira/browse/JCR-4535 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > This behavior is not specified by JCR, but should be kept stable across > Jackrabbit/Oak versions for compatibility (see OAK-8048). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCR-4535) Test the automatic deletion of version history nodes when all versions are gone.
[ https://issues.apache.org/jira/browse/JCR-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052261#comment-17052261 ] Manfred Baedke commented on JCR-4535: - This test already exists: org.apache.jackrabbit.core.version.RemoveOrphanVersionHistoryTest. Resolving as invalid. > Test the automatic deletion of version history nodes when all versions are > gone. > > > Key: JCR-4535 > URL: https://issues.apache.org/jira/browse/JCR-4535 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > This behavior is not specified by JCR, but should be kept stable across > Jackrabbit/Oak versions for compatibility (see OAK-8048). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCR-4535) Test the automatic deletion of version history nodes when all versions are gone.
[ https://issues.apache.org/jira/browse/JCR-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4535: Description: This behavior is not specified by JCR, but should be kept stable across Jackrabbit/Oak versions for compatibility (see OAK-8048). (was: This behavior is not specified by JCR, but should be kept stable across Jackrabbit/Oak for compatibility (see OAK-8048).) > Test the automatic deletion of version history nodes when all versions are > gone. > > > Key: JCR-4535 > URL: https://issues.apache.org/jira/browse/JCR-4535 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: jackrabbit-core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > This behavior is not specified by JCR, but should be kept stable across > Jackrabbit/Oak versions for compatibility (see OAK-8048). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JCR-4535) Test the automatic deletion of version history nodes when all versions are gone.
Manfred Baedke created JCR-4535: --- Summary: Test the automatic deletion of version history nodes when all versions are gone. Key: JCR-4535 URL: https://issues.apache.org/jira/browse/JCR-4535 Project: Jackrabbit Content Repository Issue Type: Test Components: jackrabbit-core Reporter: Manfred Baedke Assignee: Manfred Baedke This behavior is not specified by JCR, but should be kept stable across Jackrabbit/Oak for compatibility (see OAK-8048). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCR-4125) Not able to upload a large file (2 GB) via Jackrabbit to an MS SQL Server 2014 Database.
[
https://issues.apache.org/jira/browse/JCR-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958706#comment-15958706
]
Manfred Baedke commented on JCR-4125:
-
See org.apache.jackrabbit.core.data.db.mssql.properties in jackrabbit-data. The
data type used for binaries is IMAGE. The maximum size is 2GB.
> Not able to upload a large file (2 GB) via Jackrabbit to an MS SQL Server
> 2014 Database.
>
>
> Key: JCR-4125
> URL: https://issues.apache.org/jira/browse/JCR-4125
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 2.12.4
> Environment: Ubuntu 4.4.0-63-generic
>Reporter: Shashank
> Labels: microsoft, ms-sql
>
> I have configured my Jackrabbit to store repository on an MS SQL Server 2014
> Database. When I upload a large file (2+ GB), I receive below error.
> {quote}
> 2017-04-06 06:11:02.536 [qtp23218037-18] {username=admin} ERROR
> o.a.j.core.util.db.ConnectionHelper - Failed to execute SQL (stacktrace on
> DEBUG log level): com.microsoft.sqlserver.jdbc.SQLServerException: The length
> -2,090,401,792 is not valid.
> 2017-04-06 06:11:02.640 [qtp23218037-18] {username=admin} ERROR
> o.a.j.core.util.db.ConnectionHelper - Failed to execute SQL (stacktrace on
> DEBUG log level): com.microsoft.sqlserver.jdbc.SQLServerException: The length
> -2,090,401,792 is not valid.
> 2017-04-06 06:11:03.292 [qtp23218037-18] {username=admin} WARN
> o.a.j.core.data.db.DbDataStore - Can not insert new record
> com.microsoft.sqlserver.jdbc.SQLServerException: The length -2,090,401,792 is
> not valid.
> at
> com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:191)
> {quote}
> Is there any limitation on the size of uploaded binary artifact?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (JCR-3892) Selective invalidation of MembershipCache
[ https://issues.apache.org/jira/browse/JCR-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-3892: Assignee: (was: Manfred Baedke) > Selective invalidation of MembershipCache > - > > Key: JCR-3892 > URL: https://issues.apache.org/jira/browse/JCR-3892 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 2.6, 2.8 >Reporter: Tobias Bocanegra > > The MembershipCache is invalidated whenever any group membership changes. > this was a simple way to avoid complex transitive invalidation strategies. > In a system with a large user, group and member based, the lookup of group > memberships can be especially slow, due to the reverse lookup of the > weak-references of the members - in those systems, a good cache is essential. > If additionally the group memberships change ofter, maybe due to changing > entitlements of groups, or when synchronizing with an external IDP, the cache > is constantly flushed, thus causing performance problems for each membership > lookup. > there can be other remedies to speed up lookup, for example to properly > enable the group-split-size; or to implement a custom principal provider for > highly dynamic memberships. > nevertheless, if the membership cache would only invalidate what has changed, > it would help the performance for those authorizables that weren't affected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3704) AbstractPrincipalProvider cachesize is not configurable
[
https://issues.apache.org/jira/browse/JCR-3704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-3704:
Assignee: (was: Manfred Baedke)
> AbstractPrincipalProvider cachesize is not configurable
> ---
>
> Key: JCR-3704
> URL: https://issues.apache.org/jira/browse/JCR-3704
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: security
>Affects Versions: 2.7.2
>Reporter: Geoffroy Schneck
>
> The AbstractPrincipalProvider contains a cache, which stores the the mapping
> of Principal-String to Principal object; this cache is limited in size by
> default to 1000 entries.
> By default, the init() method where the cache is initialized is called from
> *org.apache.jackrabbit.core.UserPerWorkspaceSecurityManager* , always with an
> empty Properties object :
> {code}private PrincipalProviderRegistry
> getPrincipalProviderRegistry(SessionImpl s) throws RepositoryException {
> String wspName = s.getWorkspace().getName();
> synchronized (monitor) {
> PrincipalProviderRegistry p = ppRegistries.get(wspName);
>...
> PrincipalProvider defaultPP = new
> DefaultPrincipalProvider(systemSession, (UserManagerImpl)
> getUserManager(systemSession));
> defaultPP.init(new Properties());
> .
> }
> }{code}
> There should be a way to easily define this property.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138944#comment-15138944
]
Manfred Baedke edited comment on JCR-3948 at 2/9/16 3:33 PM:
-
The test case setup wasn't prepared for concurrency.
Fixed in trunk: r1729392.
Fixed in 2.10: r1729401.
was (Author: baedke):
The test case setup wasn't prepared for concurrency.
Fixed in trunk in r1729392.
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.13.0, 2.12.0
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138944#comment-15138944
]
Manfred Baedke edited comment on JCR-3948 at 2/9/16 2:29 PM:
-
The test case setup wasn't prepared for concurrency.
Fixed in trunk in r1729392.
was (Author: baedke):
The test case setup wasn't prepared for concurrency.
Fixed in trunk in r1729377.
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.11.4
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke resolved JCR-3948.
-
Resolution: Fixed
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.11.4
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138827#comment-15138827
]
Manfred Baedke commented on JCR-3948:
-
Looking into it.
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.11.4
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138944#comment-15138944
]
Manfred Baedke commented on JCR-3948:
-
The test case setup wasn't prepared for concurrency.
Fixed in trunk in r1729377.
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.11.4
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-3948:
Affects Version/s: (was: 2.10.1)
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.13.0, 2.12.0
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-3948:
Fix Version/s: (was: 2.10.2)
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.13.0, 2.12.0
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-3948:
Fix Version/s: 2.10.2
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.10.2, 2.13.0, 2.12.0
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-3948:
Affects Version/s: 2.10.1
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.10.1, 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.10.2, 2.13.0, 2.12.0
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138944#comment-15138944
]
Manfred Baedke edited comment on JCR-3948 at 2/9/16 4:33 PM:
-
The test case setup wasn't prepared for concurrency.
Fixed in trunk: r1729392.
Fixed in 2.10: r1729401.
Fixed in 2.8: r1729407.
was (Author: baedke):
The test case setup wasn't prepared for concurrency.
Fixed in trunk: r1729392.
Fixed in 2.10: r1729401.
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.13.0, 2.12.0
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-3948) LostFromCacheIssueTest failure
[
https://issues.apache.org/jira/browse/JCR-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138944#comment-15138944
]
Manfred Baedke edited comment on JCR-3948 at 2/9/16 4:46 PM:
-
The test case setup wasn't prepared for concurrency.
Fixed in trunk: r1729392.
Fixed in 2.10: r1729401.
Fixed in 2.8: r1729407.
Fixed in 2.6: r1729409.
was (Author: baedke):
The test case setup wasn't prepared for concurrency.
Fixed in trunk: r1729392.
Fixed in 2.10: r1729401.
Fixed in 2.8: r1729407.
> LostFromCacheIssueTest failure
> --
>
> Key: JCR-3948
> URL: https://issues.apache.org/jira/browse/JCR-3948
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Affects Versions: 2.11.3
>Reporter: Davide Giannella
>Assignee: Manfred Baedke
>Priority: Blocker
> Fix For: 2.13.0, 2.12.0
>
> Attachments: JCR-3948-1.patch, build-1454943942.log.gz
>
>
> The builds fails blocking therefore the branch and release of 2.12.0
> {noformat}
> Tests run: 143, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.053 sec
> <<< FAILURE! - in org.apache.jackrabbit.core.TestAll
> testIssue(org.apache.jackrabbit.core.LostFromCacheIssueTest) Time elapsed:
> 0.055 sec <<< ERROR!
> javax.jcr.PathNotFoundException: test/node
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2167)
> at org.apache.jackrabbit.core.NodeImpl$8.perform(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2161)
> at
> org.apache.jackrabbit.core.LostFromCacheIssueTest.testIssue(LostFromCacheIssueTest.java:136)
> ...
> Tests in error:
> LostFromCacheIssueTest>AbstractJCRTest.run:464->testIssue:136 »
> PathNotFound t...
> {noformat}
> [Full build logs|^build-1454943942.log.gz]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (JCR-3892) Selective invalidation of MembershipCache
[ https://issues.apache.org/jira/browse/JCR-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-3892: --- Assignee: Manfred Baedke (was: Tobias Bocanegra) > Selective invalidation of MembershipCache > - > > Key: JCR-3892 > URL: https://issues.apache.org/jira/browse/JCR-3892 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 2.6, 2.8 >Reporter: Tobias Bocanegra >Assignee: Manfred Baedke > > The MembershipCache is invalidated whenever any group membership changes. > this was a simple way to avoid complex transitive invalidation strategies. > In a system with a large user, group and member based, the lookup of group > memberships can be especially slow, due to the reverse lookup of the > weak-references of the members - in those systems, a good cache is essential. > If additionally the group memberships change ofter, maybe due to changing > entitlements of groups, or when synchronizing with an external IDP, the cache > is constantly flushed, thus causing performance problems for each membership > lookup. > there can be other remedies to speed up lookup, for example to properly > enable the group-split-size; or to implement a custom principal provider for > highly dynamic memberships. > nevertheless, if the membership cache would only invalidate what has changed, > it would help the performance for those authorizables that weren't affected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
]
Manfred Baedke edited comment on JCR-2633 at 12/22/15 10:41 AM:
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.
Fixed in 2.6 with r1721233 (internal release: 2.6.5-r1721237).
was (Author: baedke):
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.
Fixed in 2.6 with r1721233.
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.6.7, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
]
Manfred Baedke edited comment on JCR-2633 at 12/22/15 10:41 AM:
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.
Fixed in 2.6 with r1721233.
was (Author: baedke):
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.
Fixed in 2.6 with r1721233 (internal release: 2.6.5-r1721237).
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.6.7, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
]
Manfred Baedke edited comment on JCR-2633 at 12/21/15 6:34 PM:
---
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205
Fixed in 2.8 with r1721216
was (Author: baedke):
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
]
Manfred Baedke edited comment on JCR-2633 at 12/21/15 6:35 PM:
---
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.
was (Author: baedke):
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205
Fixed in 2.8 with r1721216
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
]
Manfred Baedke edited comment on JCR-2633 at 12/21/15 6:49 PM:
---
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.
Fixed in 2.6 with r1721233.
was (Author: baedke):
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-2633:
Fix Version/s: 2.6.7
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.6.7, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
]
Manfred Baedke commented on JCR-2633:
-
Fixed in trunk with r1721196.
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke resolved JCR-2633.
-
Resolution: Fixed
Fix Version/s: 2.10.2
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
]
Manfred Baedke edited comment on JCR-2633 at 12/21/15 4:16 PM:
---
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205
was (Author: baedke):
Fixed in trunk with r1721196.
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-2633:
Fix Version/s: 2.11.4
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke reassigned JCR-2633:
---
Assignee: Manfred Baedke
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (JCR-3909) CSRF bug in Jackrabbit-Webdav
[ https://issues.apache.org/jira/browse/JCR-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-3909: --- Assignee: Manfred Baedke > CSRF bug in Jackrabbit-Webdav > - > > Key: JCR-3909 > URL: https://issues.apache.org/jira/browse/JCR-3909 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-webdav >Affects Versions: 2.11.0 >Reporter: Mikhail Egorov >Assignee: Manfred Baedke > Labels: csrf, security, webdav > Fix For: 2.11.1 > > > Following issues lead to CSRF: > 1.Jackrabbit-webdav processes POST requests as PUT requests. Handler doPost > invokes doPut in code of > org.apache.jackrabbit.webdav.server.AbstractWebdavServlet class. > 2.There is CSRF protection based on Referer header - > https://issues.apache.org/jira/browse/JCR-3036. This protection could be > bypassed, because it allows requests with omitted Referer header. It is > possible to strip referer by creating an iframe with Javascript in src > attribute. It works beacuse javascript is executed in context of about:blank > page. > Attack scenario: > 1. Attacker creates following HTML page: > CSRF PoC > http://127.0.0.1:8080/jackrabbit-webapp-custom/repository/default/evil\'> type=\'hidden\' > name=\'EvilContent\'/>');document.forms[0].submit();"> > 2. If victim previously used browser to access jackrabbit-webdav and opens > attacker's page than node "evil" with content "EvilContent=" will be created > on victim's behalf. > Proposed fix: > Jackrabbit-webdav should return 405 Method Not Allowed for POST requests by > default. When POST requests are requried robust CSRF protection must be > implemented. At least omitted Referer should be prohibited for POST requests. > Referer based protection considered weak, because it is possible to > completely bypass Referer-based protection for IE browser using Java Applets > or PDF files. The best option for CSRF protection is CSRF tokens. > CVSS: > 2.6 (AV:N/AC:H/Au:N/C:N/I:P/A:N) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3687) Backport improvements made to token based auth in OAK
[ https://issues.apache.org/jira/browse/JCR-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14901036#comment-14901036 ] Manfred Baedke commented on JCR-3687: - Backported to 2.4 with r1704373. > Backport improvements made to token based auth in OAK > - > > Key: JCR-3687 > URL: https://issues.apache.org/jira/browse/JCR-3687 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 2.7.1 >Reporter: angela >Assignee: angela > Fix For: 2.7.2, 2.4.6, 2.6.6 > > > we decided to back port the improvements made to token based authentication > in the OAK project to Jackrabbit-core. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
