[jira] [Comment Edited] (JCR-5071) Update oak-jackrabbit-api.version.implemented in trunk to Oak 1.64.0
[ https://issues.apache.org/jira/browse/JCR-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849822#comment-17849822 ] Manfred Baedke edited comment on JCR-5071 at 5/28/24 7:57 AM: -- trunk: [e557bd7d0|https://github.com/apache/jackrabbit/commit/e557bd7d0fa0bb1350b3b384dac85f938040f0c5] was (Author: reschke): trunk: [e557bd7d0|https://github.com/apache/jackrabbit-oak/commit/e557bd7d0fa0bb1350b3b384dac85f938040f0c5] > Update oak-jackrabbit-api.version.implemented in trunk to Oak 1.64.0 > > > Key: JCR-5071 > URL: https://issues.apache.org/jira/browse/JCR-5071 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.22, 2.21.27 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-5004) jcr-commons: get rid of cglib test dependency (unmaintained)
[ https://issues.apache.org/jira/browse/JCR-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-5004: Fix Version/s: (was: 2.21.22) > jcr-commons: get rid of cglib test dependency (unmaintained) > > > Key: JCR-5004 > URL: https://issues.apache.org/jira/browse/JCR-5004 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-commons >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > > Can be replaced with Mockito. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-4987) Update to jacoco version 0.8.11
[ https://issues.apache.org/jira/browse/JCR-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved JCR-4987. - Resolution: Fixed > Update to jacoco version 0.8.11 > --- > > Key: JCR-4987 > URL: https://issues.apache.org/jira/browse/JCR-4987 > 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-4987) Update to jacoco version 0.8.11
[ https://issues.apache.org/jira/browse/JCR-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794686#comment-17794686 ] Manfred Baedke commented on JCR-4987: - trunk: [r1914461|https://svn.apache.org/viewvc?view=revision=1914461] > Update to jacoco version 0.8.11 > --- > > Key: JCR-4987 > URL: https://issues.apache.org/jira/browse/JCR-4987 > 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] [Assigned] (JCR-4987) Update to jacoco version 0.8.11
[ https://issues.apache.org/jira/browse/JCR-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-4987: --- Assignee: Manfred Baedke (was: Julian Reschke) > Update to jacoco version 0.8.11 > --- > > Key: JCR-4987 > URL: https://issues.apache.org/jira/browse/JCR-4987 > 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] [Updated] (JCR-5004) jcr-commons: get rid of cglib test dependency (unmaintained)
[ https://issues.apache.org/jira/browse/JCR-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-5004: Description: Can be replaced with Mockito. > jcr-commons: get rid of cglib test dependency (unmaintained) > > > Key: JCR-5004 > URL: https://issues.apache.org/jira/browse/JCR-5004 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-commons >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22, 2.21.22 > > > Can be replaced with Mockito. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-5004) jcr-commons: get rid of cglib test dependency (unmaintained)
[ https://issues.apache.org/jira/browse/JCR-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved JCR-5004. - Resolution: Fixed > jcr-commons: get rid of cglib test dependency (unmaintained) > > > Key: JCR-5004 > URL: https://issues.apache.org/jira/browse/JCR-5004 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-commons >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22, 2.21.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-5004) jcr-commons: get rid of cglib test dependency (unmaintained)
[ https://issues.apache.org/jira/browse/JCR-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-5004: Fix Version/s: 2.22 2.21.22 > jcr-commons: get rid of cglib test dependency (unmaintained) > > > Key: JCR-5004 > URL: https://issues.apache.org/jira/browse/JCR-5004 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-commons >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22, 2.21.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-5004) jcr-commons: get rid of cglib test dependency (unmaintained)
[ https://issues.apache.org/jira/browse/JCR-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794630#comment-17794630 ] Manfred Baedke commented on JCR-5004: - trunk: [r1914456|https://svn.apache.org/viewvc?view=revision=1914456] > jcr-commons: get rid of cglib test dependency (unmaintained) > > > Key: JCR-5004 > URL: https://issues.apache.org/jira/browse/JCR-5004 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-commons >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4967) test coverage for modification of non-versioned node with jcr:isCheckedOut==false property
[ https://issues.apache.org/jira/browse/JCR-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793730#comment-17793730 ] Manfred Baedke commented on JCR-4967: - ??Depends on how frequently "isCheckedOut" is needed.?? Yes, obviously. Let me rephrase: Is isCheckedOut actually called that often? :) > test coverage for modification of non-versioned node with > jcr:isCheckedOut==false property > -- > > Key: JCR-4967 > URL: https://issues.apache.org/jira/browse/JCR-4967 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: core >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Labels: candidate_jackrabbit_2_20 > Fix For: 2.22, 2.21.22 > > Attachments: JCR-4967.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4967) test coverage for modification of non-versioned node with jcr:isCheckedOut==false property
[ https://issues.apache.org/jira/browse/JCR-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793688#comment-17793688 ] Manfred Baedke commented on JCR-4967: - Yes. Is performance actually a concern there? > test coverage for modification of non-versioned node with > jcr:isCheckedOut==false property > -- > > Key: JCR-4967 > URL: https://issues.apache.org/jira/browse/JCR-4967 > Project: Jackrabbit Content Repository > Issue Type: Test > Components: core >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Attachments: JCR-4967.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCR-5004) jcr-commons: get rid of cglib test dependency (unmaintained)
[ https://issues.apache.org/jira/browse/JCR-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-5004: --- Assignee: Manfred Baedke > jcr-commons: get rid of cglib test dependency (unmaintained) > > > Key: JCR-5004 > URL: https://issues.apache.org/jira/browse/JCR-5004 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-commons >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4972) Remove RMI support
[ https://issues.apache.org/jira/browse/JCR-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788333#comment-17788333 ] Manfred Baedke commented on JCR-4972: - As far as I understand, JNDI is only used to look up the RMI stub of a remote repository, which of course is not supposed to be used any longer. > Remove RMI support > -- > > Key: JCR-4972 > URL: https://issues.apache.org/jira/browse/JCR-4972 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-rmi >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 2.22 > > > Due to the fact that the RMI code has been essentially unmaintained for a > decade, and the inherent risks related to deserialization, we should end > support for this module. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4972) Remove RMI support
[ https://issues.apache.org/jira/browse/JCR-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788331#comment-17788331 ] Manfred Baedke commented on JCR-4972: - Not all of jcr-servlet, just the remote repository access. JackrabbitRepositoryServlet will not be affected. > Remove RMI support > -- > > Key: JCR-4972 > URL: https://issues.apache.org/jira/browse/JCR-4972 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-rmi >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 2.22 > > > Due to the fact that the RMI code has been essentially unmaintained for a > decade, and the inherent risks related to deserialization, we should end > support for this module. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[
https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784768#comment-17784768
]
Manfred Baedke edited comment on JCR-4954 at 11/10/23 10:51 AM:
Hi [~c_koell] ,
Thx for the effort!
??I hope you will understand the problem now ;)??
Well, at least one of us doesn't fully understand the problem yet. Maybe it's
just me, but it might also be both of us :)
Let me elaborate:
??For me it's not clear how to fix the problem but I think Server B should
return on PROPFIND lockDiscovery the same LockToken as created on LOCK
Operation.??
Yes, of course, the problem is that it returns the lock with a session scope
prefix (4403ef44-4124-11e1-b965-00059a3c7a00) instead of an open scope prefix
(dccce564-412e-11e1-b969-00059a3c7a00). So the question is: Why does it do that?
Now take a look at
[https://github.com/apache/jackrabbit/blob/90b60f4561eae41256c2110df3a72b854ead962d/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/lock/LockManagerImpl.java#L675.]
As you can see, when a LockImpl object is created with an open scope, an
internal flag is set to reload the LockInfo. This will be done if and only if
the method LockImpl.updateLockInfo() is called. AFAICS {*}this operation will
transfer the lock to the new session{*}. So we have to make sure that it
actually gets called and one of the ways to do that is calling
lock.getLockToken(), which the patch does, but maybe not in the right place, or
the analysis is incomplete. To verify that, you could check if on lock
discovery, the reloadInfo flag in the constructor of LockImpl is actually set
and the method LockImpl.updateLockInfo() is not called, in which case this
general idea would be correct.
was (Author: baedke):
Hi [~c_koell] ,
Thx for the effort!
??I hope you will understand the problem now ;)??
Well, at least one of us doesn't fully understand the problem yet. Maybe it's
just me, but I'm not sure :)
Let me elaborate:
??For me it's not clear how to fix the problem but I think Server B should
return on PROPFIND lockDiscovery the same LockToken as created on LOCK
Operation.??
Yes, of course, the problem is that it returns the lock with a session scope
prefix (4403ef44-4124-11e1-b965-00059a3c7a00) instead of an open scope prefix
(dccce564-412e-11e1-b969-00059a3c7a00). So the question is: Why does it do that?
Now take a look at
[https://github.com/apache/jackrabbit/blob/90b60f4561eae41256c2110df3a72b854ead962d/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/lock/LockManagerImpl.java#L675.]
As you can see, when a LockImpl object is created with an open scope, an
internal flag is set to reload the LockInfo. This will be done if and only if
the method LockImpl.updateLockInfo() is called. AFAICS {*}this operation will
transfer the lock to the new session{*}. So we have to make sure that it
actually gets called and one of the ways to do that is calling
lock.getLockToken(), which the patch does, but maybe not in the right place, or
the analysis is incomplete. To verify that, you could check if on lock
discovery, the reloadInfo flag in the constructor of LockImpl is actually set
and the method LockImpl.updateLockInfo() is not called, in which case this
general idea would be correct.
> Problem with WebDav Client and Repository Server Deployment Model
> -
>
> Key: JCR-4954
> URL: https://issues.apache.org/jira/browse/JCR-4954
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Reporter: Claus Köll
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 2.22
>
> Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt,
> JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt,
> config.xml, jcr-4954-diagnose.patch
>
>
> We have one WebApp where we have deployed the SimpleWebDavServlet
> (WebDav-WebApp). From there we connect to a other WebApp where we have
> exposed a Repository through DavEx
> (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet)
> and also the RMI-Layer by the RMI Registry (Repository-WebApp)
> Until now we connected over RMI but now we tried to switch to DavEx. The
> Problem is, that we are now unable to unlock a opened WebDav Document.
> The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the
> DavSession so a future Requests can obtain the same DavSession to perform the
> unlock.
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700
> The Reference (Locktoken) looks like
>
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[
https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784768#comment-17784768
]
Manfred Baedke commented on JCR-4954:
-
Hi [~c_koell] ,
Thx for the effort!
??I hope you will understand the problem now ;)??
Well, at least one of us doesn't fully understand the problem yet. Maybe it's
just me, but I'm not sure :)
Let me elaborate:
??For me it's not clear how to fix the problem but I think Server B should
return on PROPFIND lockDiscovery the same LockToken as created on LOCK
Operation.??
Yes, of course, the problem is that it returns the lock with a session scope
prefix (4403ef44-4124-11e1-b965-00059a3c7a00) instead of an open scope prefix
(dccce564-412e-11e1-b969-00059a3c7a00). So the question is: Why does it do that?
Now take a look at
[https://github.com/apache/jackrabbit/blob/90b60f4561eae41256c2110df3a72b854ead962d/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/lock/LockManagerImpl.java#L675.]
As you can see, when a LockImpl object is created with an open scope, an
internal flag is set to reload the LockInfo. This will be done if and only if
the method LockImpl.updateLockInfo() is called. AFAICS {*}this operation will
transfer the lock to the new session{*}. So we have to make sure that it
actually gets called and one of the ways to do that is calling
lock.getLockToken(), which the patch does, but maybe not in the right place, or
the analysis is incomplete. To verify that, you could check if on lock
discovery, the reloadInfo flag in the constructor of LockImpl is actually set
and the method LockImpl.updateLockInfo() is not called, in which case this
general idea would be correct.
> Problem with WebDav Client and Repository Server Deployment Model
> -
>
> Key: JCR-4954
> URL: https://issues.apache.org/jira/browse/JCR-4954
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Reporter: Claus Köll
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 2.22
>
> Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt,
> JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt,
> config.xml, jcr-4954-diagnose.patch
>
>
> We have one WebApp where we have deployed the SimpleWebDavServlet
> (WebDav-WebApp). From there we connect to a other WebApp where we have
> exposed a Repository through DavEx
> (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet)
> and also the RMI-Layer by the RMI Registry (Repository-WebApp)
> Until now we connected over RMI but now we tried to switch to DavEx. The
> Problem is, that we are now unable to unlock a opened WebDav Document.
> The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the
> DavSession so a future Requests can obtain the same DavSession to perform the
> unlock.
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700
> The Reference (Locktoken) looks like
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0
> It will be generated by the LockTokenMapper
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53
> In the WebDav-WebApp the HeaderLockToken will be stored in this format
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4
> As you can see it will be double wrapped. That's not really a Problem because
> on unlock the WebDav-WebApp removes the prefix
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:
> Finally this locktoken will be send from the WebDav-App to the
> Repository-WebApp
> opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4
> On the Repository-WebApp the JCRWebdavServer will look for a DavSession in
> the Cache based on the lockToken
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210
> So the problem is that the DavSession whitch have created the Lock, is stored
> with a lockToken that do not match with the incoming lockToken
> Cache-Key-Token:
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0
> Incoming-Token:
> opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4
> The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is
> present)
>
[jira] [Updated] (JCR-4988) Jacoco produces a lot of exceptions with Java 21
[ https://issues.apache.org/jira/browse/JCR-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4988: Description: Those are java.lang.IllegalArgumentExceptions due to unsupported class file major versions. Apparently, Jacoco 0.8.8 (which we are currently using) as well as 0.8.11 (the most recent version) are not compatible with Java 21. Fortunately they do not cause jacoco:0.8.8:check to fail. was: Those are java.lang.IllegalArgumentExceptions due to unsupported class file major versions. Apparently, Jacoco 0.8.8 (which we are currently using) as well as 0.8.11 (the most recent version) are not compatible with Java 21. Fortunately they do not cause jacoco:0.8.8:check to fail. > Jacoco produces a lot of exceptions with Java 21 > > > Key: JCR-4988 > URL: https://issues.apache.org/jira/browse/JCR-4988 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Manfred Baedke >Priority: Minor > > Those are java.lang.IllegalArgumentExceptions due to unsupported class file > major versions. Apparently, Jacoco 0.8.8 (which we are currently using) as > well as 0.8.11 (the most recent version) are not compatible with Java 21. > Fortunately they do not cause jacoco:0.8.8:check to fail. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-4988) Jacoco produces a lot of exceptions with Java 21
Manfred Baedke created JCR-4988: --- Summary: Jacoco produces a lot of exceptions with Java 21 Key: JCR-4988 URL: https://issues.apache.org/jira/browse/JCR-4988 Project: Jackrabbit Content Repository Issue Type: Task Reporter: Manfred Baedke Those are java.lang.IllegalArgumentExceptions due to unsupported class file major versions. Apparently, Jacoco 0.8.8 (which we are currently using) as well as 0.8.11 (the most recent version) are not compatible with Java 21. Fortunately they do not cause jacoco:0.8.8:check to fail. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779392#comment-17779392 ] Manfred Baedke commented on JCR-4954: - Yes, but it is an open scoped lock, so the lock holder should be transitioned. That's what my previous patch, which apparently did not work, tries to address. > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt, > JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt, > config.xml, jcr-4954-diagnose.patch > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is familiar with the code of LockTokenMapper can explain > the two different Scopes (SESSIONSCOPED/OPENSCOPED) > One possible solution could be to change the code in the LockTokenMapper to > always return the Node Identifier with the same SCOPE-PREFIX? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778674#comment-17778674 ] Manfred Baedke commented on JCR-4954: - Hi [~c_koell], Yes, that was indeed a misunderstanding on my side. Sorry for the noise. > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt, > JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt, > config.xml, jcr-4954-diagnose.patch > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is familiar with the code of LockTokenMapper can explain > the two different Scopes (SESSIONSCOPED/OPENSCOPED) > One possible solution could be to change the code in the LockTokenMapper to > always return the Node Identifier with the same SCOPE-PREFIX? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778651#comment-17778651 ] Manfred Baedke commented on JCR-4954: - Hi [~c_koell], ??s it now clear to you ??? No. Let me repeat: SimpleWebDavServlet: Response-Header: Name [Lock-Token] Value [] JcrRemotingServlet: Response-Header: Name [Lock-Token] Value [] > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt, > JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt, > config.xml, jcr-4954-diagnose.patch > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is familiar with the code of LockTokenMapper can explain > the two different Scopes (SESSIONSCOPED/OPENSCOPED) > One possible solution could be to change the code in the LockTokenMapper to > always return the Node Identifier with the same SCOPE-PREFIX? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778651#comment-17778651 ] Manfred Baedke edited comment on JCR-4954 at 10/23/23 12:59 PM: Hi [~c_koell], ??Is it now clear to you??? No. Let me repeat: SimpleWebDavServlet: Response-Header: Name [Lock-Token] Value [] JcrRemotingServlet: Response-Header: Name [Lock-Token] Value [] was (Author: baedke): Hi [~c_koell], ??s it now clear to you ??? No. Let me repeat: SimpleWebDavServlet: Response-Header: Name [Lock-Token] Value [] JcrRemotingServlet: Response-Header: Name [Lock-Token] Value [] > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt, > JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt, > config.xml, jcr-4954-diagnose.patch > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is familiar with the code of LockTokenMapper can explain > the two different Scopes (SESSIONSCOPED/OPENSCOPED) > One possible solution could be to change the code in the LockTokenMapper to > always return the Node Identifier with the same SCOPE-PREFIX? -- 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: Attachment: jcr-4946.patch > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- 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: Attachment: (was: jcr-4946.patch) > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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: Resolution: Fixed Status: Resolved (was: Patch Available) > 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 > Fix For: 2.22, 2.21.21 > > Attachments: JCR-4570.patch, jcr-4570-2.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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: Fix Version/s: 2.22 2.21.21 > 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 > Fix For: 2.22, 2.21.21 > > Attachments: JCR-4570.patch, jcr-4570-2.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=1732#comment-1732 ] Manfred Baedke commented on JCR-4570: - trunk (2.21.21): [1913142|https://svn.apache.org/viewvc?view=revision=1913142] > 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, jcr-4570-2.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1640#comment-1640 ] Manfred Baedke commented on JCR-4954: - [~c_koell], Re config: I'm more interested in the setup of the infrastructure. There has to be an spi2dav Repo setup somewhere for the WebDAV Servlet to act upon, no? > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt, > JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt, > config.xml, jcr-4954-diagnose.patch > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is familiar with the code of LockTokenMapper can explain > the two different Scopes (SESSIONSCOPED/OPENSCOPED) > One possible solution could be to change the code in the LockTokenMapper to > always return the Node Identifier with the same SCOPE-PREFIX? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[
https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1292#comment-1292
]
Manfred Baedke commented on JCR-4954:
-
[~c_koell], now I'm totally confused, because both logs contain exactly one
LOCK request/response pair and they simply do not match:
SimpleWebDavServlet:
{code:java}
023-10-19 14:10:39.849-Method [LOCK] ->
/repository/template/tirolgvat/2016/9/4/2/10/24/46b237050a0a80969a8156c54ced1b37.doc
Request-Header: Name [Cache-Control] Value [no-cache]
Request-Header: Name [Connection] Value [Keep-Alive]
Request-Header: Name [Pragma] Value [no-cache]
Request-Header: Name [Content-Type] Value [text/xml; charset="utf-8"]
Request-Header: Name [Authorization] Value [Bearer]
Request-Header: Name [User-Agent] Value [Microsoft Office Word 2014 (16.0.5404)
Windows NT 10.0]
Request-Header: Name [X-Office-Major-Version] Value [16]
Request-Header: Name [X-MS-CookieUri-Requested] Value [t]
Request-Header: Name [X-FeatureVersion] Value [1]
Request-Header: Name [Translate] Value [f]
Request-Header: Name [Timeout] Value [Second-3600]
Request-Header: Name [X-IDCRL_ACCEPTED] Value [t]
Request-Header: Name [Content-Length] Value [202]
Request-Header: Name [Host] Value [localhost:9109]
Request-Header: Name [Cookie] Value
[JSESSIONID=jWAkYBW4sn5F_VZlcVdZnfy:2a16e4ec-c45a-40b9-bfc1-1768fb34e82b;
JSESSIONID=jWAkYBW4sn5F_VZlcVdZnfy:2a16e4ec-c45a-40b9-bfc1-1768fb34e82b]
Request-Payload [LV\udvt0047
]
2023-10-19 14:10:40.493-Response Headers
Response-Header: Name [X-Powered-By] Value [Servlet/4.0]
Response-Header: Name [Cast] Value [127.0.0.1:9109]
Response-Header: Name [Lock-Token] Value
[]
Response-Header: Name [Content-Type] Value [text/xml; charset=UTF-8]
Response-Header: Name [Content-Length] Value [434]
Response-Payload [infinitySecond-3598LV\udvt0047opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:6007b5ba-b2c2-4bd1-8a27-9457a39a5ba7]
{code}
JcrRemotingServlet:
{code:java}
2023-10-19 14:10:39.924-Request Method [LOCK] ->
/jcr/server/template/jcr%3aroot/tirolgvat/2016/9/4/2/10/24/46b237050a0a80969a8156c54ced1b37.doc/
Request-Header: Name [Timeout] Value [Second-3600]
Request-Header: Name [Depth] Value [infinity]
Request-Header: Name [Link] Value
[;
rel="http://www.day.com/jcr/webdav/1.0/session-id;]
Request-Header: Name [Content-Length] Value [184]
Request-Header: Name [Content-Type] Value [application/xml; charset=UTF-8]
Request-Header: Name [Host] Value [localhost:9080]
Request-Header: Name [Connection] Value [Keep-Alive]
Request-Header: Name [User-Agent] Value [Apache-HttpClient/4.5.14 (Java/17.0.7)]
Request-Header: Name [Accept-Encoding] Value [gzip,deflate]
Request-Header: Name [Authorization] Value [Basic
eyJkZXBhcnRtZW50TmFtZSI6IiIsInNlY3VyaXR5Q2xhc3MiOi05OSwiZ3ZCaXJ0aGRhdGUiOiIiLCJ0ZWxlcGhvbmVOdW1iZXIiOiIiLCJkaXNwbGF5TmFtZSI6Ik11c3Rlcm1hbm4sIE1heCIsImdpdmVuTmFtZSI6Ik1heCIsImVtcGxveWVlSUQiOiJVRFZUMDk5OSIsIndlYmRhdiI6dHJ1ZSwidXNlck5hbWUiOiJ1ZHZ0MDk5OSIsImVtcGxveWVlTnVtYmVyIjoiIiwiY2hlY2tJbnRlcm5hbE5vZGVMaXN0Ijp0cnVlLCJndkdpZCI6IiIsInVpZCI6InVkdnQwOTk5QHRpcm9sLmd2LmF0IiwiYWNjZXNzTm9kZUlkcyI6WyI2MDA3YjViYS1iMmMyLTRiZDEtOGEyNy05NDU3YTM5YTViYTciLCIxMThmM2Q0YS04NjIwLTRkODItYTk2My0yYjlkZDE5MTMyNWIiLCIwYzVlNzkwOC01MTZiLTQyZTMtYjJjOC00OTMwOTc1MTM2NjAiLCI5ODQzMjc4MC0yOWY4LTRmMWItYWE3NS00NWFhN2MxM2Y2YzMiLCIyNTJmZWNiZS0xOTgyLTQ2ZDctOWJhMi1jMmU0MDkzZjViNGYiLCJmMzdjNzQ4NS1kNTA0LTRiNGYtYjU4Mi1hMzAzNmYyODlhMzYiLCJlYTJhY2RiZC00YTBjLTQxZDYtYTlkOS02ZjUyNWFiOTJkYzciLCJkYTdlZjA5NC0yNWVmLTQ1NDItYmIwYS01YTNiNmIyMDEwMGMiXSwic24iOiJNdXN0ZXJtYW5uIiwiamNyV29ya3NwYWNlTmFtZXMiOlsidGVtcGxhdGUiXSwiZW1haWwiOiIifQ==]
Request-Payload [LV\udvt0047
]
2023-10-19 14:10:39.985-Response Method [LOCK] ->
/jcr/server/template/jcr%3aroot/tirolgvat/2016/9/4/2/10/24/46b237050a0a80969a8156c54ced1b37.doc/
Response-Header: Name [X-Powered-By] Value [Servlet/4.0]
Response-Header: Name [Lock-Token] Value
[]
Response-Header: Name [Content-Type] Value [text/xml; charset=UTF-8]
Response-Header: Name [Content-Length] Value [452]
Response-Payload [infinitySecond-3599LV\udvt0047opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:6007b5ba-b2c2-4bd1-8a27-9457a39a5ba7-Y]
{code}
The headers just do not match. In particular, the JcrRemotingServlet sends an
open scoped lock-token and the SimpleWebDavServlet magically receives a session
scoped lock-token.
What am I missing?
> Problem with WebDav Client and Repository Server Deployment Model
> -
>
> Key: JCR-4954
> URL: https://issues.apache.org/jira/browse/JCR-4954
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Reporter: Claus Köll
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 2.22
>
> Attachments: Call-Hierarchy.txt,
[jira] [Commented] (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:comment-tabpanel=1214#comment-1214 ] Manfred Baedke commented on JCR-4570: - Updated jcr-4570-2.patch, because the old version meanwhile didn't merge without conflicts. > 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, jcr-4570-2.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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: (was: jcr-4570-2.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, jcr-4570-2.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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-2.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, jcr-4570-2.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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: Resolution: Fixed Status: Resolved (was: Patch Available) > 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 > Fix For: 2.22, 2.21.21 > > Attachments: jcr-4571.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (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:comment-tabpanel=1195#comment-1195 ] Manfred Baedke edited comment on JCR-4571 at 10/19/23 11:11 AM: trunk (2.21.21): [1913113|https://svn.apache.org/viewvc?view=revision=1913113] was (Author: baedke): trunk: [1913113|https://svn.apache.org/viewvc?view=revision=1913113] > 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 > Fix For: 2.22, 2.21.21 > > Attachments: jcr-4571.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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: Fix Version/s: 2.22 2.21.21 > 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 > Fix For: 2.22, 2.21.21 > > Attachments: jcr-4571.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=1195#comment-1195 ] Manfred Baedke commented on JCR-4571: - trunk: [1913113|https://svn.apache.org/viewvc?view=revision=1913113] > 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.20.10#820010)
[jira] [Comment Edited] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1179#comment-1179 ] Manfred Baedke edited comment on JCR-4954 at 10/19/23 10:28 AM: [~c_koell], after staring at the code for quite some time I came to the conclusion that we actually have two independent issues: the first problem is that the LockTokenMapper should not add a prefix to a LockToken that is already prefixed. The second problem is that the JcrRemotingServlet at some point creates a LockImpl with an internal flag that it needs a refresh, but the refresh would only happen as a side effect of a method that never gets called. That means that the lock is attached to the wrong session, which makes the LockTokenMapper unable to read the lock token. Both issues are hopefully addressed in the attached experimental [patch|https://issues.apache.org/jira/secure/attachment/13063696/jcr-4954-diagnose.patch] . Could you try if it helps? was (Author: baedke): [~c_koell], after staring at the code for quite some time I came to the conclusion that we actually have two independent issues: the first problem is that the LockTokenMapper should not add a prefix to a LockToken that is already prefixed. The second problem is that the JcrRemotingServlet at some point creates a LockImpl with an internal flag that it needs a refresh, but the refresh would only happen as a side effect of a method that never gets called. That means that the lock is attached to the wrong session, which makes the LockTokenMapper unable to read the lock token. Both issues are hopefully addressed in the attached experimental patch. Could you try if it helps? > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt, > SimpleWebDavServlet.txt, config.xml, jcr-4954-diagnose.patch > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1179#comment-1179 ] Manfred Baedke commented on JCR-4954: - [~c_koell], after staring at the code for quite some time I came to the conclusion that we actually have two independent issues: the first problem is that the LockTokenMapper should not add a prefix to a LockToken that is already prefixed. The second problem is that the JcrRemotingServlet at some point creates a LockImpl with an internal flag that it needs a refresh, but the refresh would only happen as a side effect of a method that never gets called. That means that the lock is attached to the wrong session, which makes the LockTokenMapper unable to read the lock token. Both issues are hopefully addressed in the attached experimental patch. Could you try if it helps? > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt, > SimpleWebDavServlet.txt, config.xml, jcr-4954-diagnose.patch > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is familiar with the code of LockTokenMapper can explain > the two different Scopes (SESSIONSCOPED/OPENSCOPED) > One possible solution could be to change the code in the LockTokenMapper to > always return the Node Identifier with the same SCOPE-PREFIX? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4954: Attachment: jcr-4954-diagnose.patch > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt, > SimpleWebDavServlet.txt, config.xml, jcr-4954-diagnose.patch > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is familiar with the code of LockTokenMapper can explain > the two different Scopes (SESSIONSCOPED/OPENSCOPED) > One possible solution could be to change the code in the LockTokenMapper to > always return the Node Identifier with the same SCOPE-PREFIX? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776114#comment-17776114 ] Manfred Baedke commented on JCR-4954: - [~c_koell], could you share the configuration files of the web applications? Then we can quickly set up a test environment. > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is familiar with the code of LockTokenMapper can explain > the two different Scopes (SESSIONSCOPED/OPENSCOPED) > One possible solution could be to change the code in the LockTokenMapper to > always return the Node Identifier with the same SCOPE-PREFIX? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[
https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776110#comment-17776110
]
Manfred Baedke commented on JCR-4954:
-
I do not understand this call stack from server B:
{code:java}
bstractWebdavServlet.doPropFind -> LOCKDISCOVERY
org.apache.jackrabbit.webdav.jcr.AbstractResource.initProperties
properties.add(new
LockDiscovery(getLocks()));
org.apache.jackrabbit.webdav.jcr.AbstractResource.getLocks
// write lock (either
exclusive or session-scoped).
getLock(Type.WRITE,
Scope.EXCLUSIVE);
org.apache.jackrabbit.webdav.jcr.DefaultItemCollection.getLock
jcrLock ->
org.apache.jackrabbit.core.lock.XALockImpl
ActiveLock lock
= new JcrActiveLock(jcrLock);
org.apache.jackrabbit.webdav.jcr.lock.JcrActiveLock.toXml
org.apache.jackrabbit.webdav.jcr.lock.JcrActiveLock.getToken
[jira] [Comment Edited] (JCR-4956) Replace deprecated Surefire fork options
[ https://issues.apache.org/jira/browse/JCR-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774825#comment-17774825 ] Manfred Baedke edited comment on JCR-4956 at 10/13/23 8:38 AM: --- trunk (2.21.21): [r1912931|http://svn.apache.org/r1912931] was (Author: baedke): trunk: r1912931 > Replace deprecated Surefire fork options > > > Key: JCR-4956 > URL: https://issues.apache.org/jira/browse/JCR-4956 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Fix For: 2.21.21 > > Attachments: jcr-4956.patch > > > Some subprojects use the the deprecated Surefire option"forkMode" (or even > the option "fork", which AFAIK never existed). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4956) Replace deprecated Surefire fork options
[ https://issues.apache.org/jira/browse/JCR-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4956: Fix Version/s: 2.21.21 > Replace deprecated Surefire fork options > > > Key: JCR-4956 > URL: https://issues.apache.org/jira/browse/JCR-4956 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Fix For: 2.21.21 > > Attachments: jcr-4956.patch > > > Some subprojects use the the deprecated Surefire option"forkMode" (or even > the option "fork", which AFAIK never existed). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4956) Replace deprecated Surefire fork options
[ https://issues.apache.org/jira/browse/JCR-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774825#comment-17774825 ] Manfred Baedke commented on JCR-4956: - trunk: r1912931 > Replace deprecated Surefire fork options > > > Key: JCR-4956 > URL: https://issues.apache.org/jira/browse/JCR-4956 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4956.patch > > > Some subprojects use the the deprecated Surefire option"forkMode" (or even > the option "fork", which AFAIK never existed). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4956) Replace deprecated Surefire fork options
[ https://issues.apache.org/jira/browse/JCR-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4956: Resolution: Fixed Status: Resolved (was: Patch Available) > Replace deprecated Surefire fork options > > > Key: JCR-4956 > URL: https://issues.apache.org/jira/browse/JCR-4956 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4956.patch > > > Some subprojects use the the deprecated Surefire option"forkMode" (or even > the option "fork", which AFAIK never existed). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4956) Replace deprecated Surefire fork options
[ https://issues.apache.org/jira/browse/JCR-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746445#comment-17746445 ] Manfred Baedke edited comment on JCR-4956 at 10/13/23 7:32 AM: --- We can actually just remove them, because the default forkCount=1 is just what we want. Find a patch attached. was (Author: baedke): We can actually just remove them, because the default forkCount=1 are just what we want. Find a patch attached. > Replace deprecated Surefire fork options > > > Key: JCR-4956 > URL: https://issues.apache.org/jira/browse/JCR-4956 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4956.patch > > > Some subprojects use the the deprecated Surefire option"forkMode" (or even > the option "fork", which AFAIK never existed). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4972) Remove RMI support
[ https://issues.apache.org/jira/browse/JCR-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768652#comment-17768652 ] Manfred Baedke commented on JCR-4972: - +1 > Remove RMI support > -- > > Key: JCR-4972 > URL: https://issues.apache.org/jira/browse/JCR-4972 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-rmi >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 2.22 > > > Due to the fact that the RMI code has been essentially unmaintained for a > decade, and the inherent risks related to deserialization, we should end > support for this module. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-4954: --- Assignee: Manfred Baedke (was: Claus Köll) > Problem with WebDav Client and Repository Server Deployment Model > - > > Key: JCR-4954 > URL: https://issues.apache.org/jira/browse/JCR-4954 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-webdav >Reporter: Claus Köll >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: Call-Hierarchy.txt > > > We have one WebApp where we have deployed the SimpleWebDavServlet > (WebDav-WebApp). From there we connect to a other WebApp where we have > exposed a Repository through DavEx > (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet) > and also the RMI-Layer by the RMI Registry (Repository-WebApp) > Until now we connected over RMI but now we tried to switch to DavEx. The > Problem is, that we are now unable to unlock a opened WebDav Document. > The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the > DavSession so a future Requests can obtain the same DavSession to perform the > unlock. > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700 > The Reference (Locktoken) looks like > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > It will be generated by the LockTokenMapper > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53 > In the WebDav-WebApp the HeaderLockToken will be stored in this format > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4 > As you can see it will be double wrapped. That's not really a Problem because > on unlock the WebDav-WebApp removes the prefix > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00: > Finally this locktoken will be send from the WebDav-App to the > Repository-WebApp > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > On the Repository-WebApp the JCRWebdavServer will look for a DavSession in > the Cache based on the lockToken > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210 > So the problem is that the DavSession whitch have created the Lock, is stored > with a lockToken that do not match with the incoming lockToken > Cache-Key-Token: > opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0 > Incoming-Token: > opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4 > The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is > present) > https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118 > Maybe someone which is familiar with the code of LockTokenMapper can explain > the two different Scopes (SESSIONSCOPED/OPENSCOPED) > One possible solution could be to change the code in the LockTokenMapper to > always return the Node Identifier with the same SCOPE-PREFIX? -- 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: In Progress (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-4960) Disable RMI by default
[ https://issues.apache.org/jira/browse/JCR-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4960: Attachment: jcr-4960.patch Status: Patch Available (was: In Progress) > Disable RMI by default > -- > > Key: JCR-4960 > URL: https://issues.apache.org/jira/browse/JCR-4960 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-jcr-rmi, jackrabbit-standalone, > jackrabbit-standalone-components, jackrabbit-webapp >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.22 > > Attachments: jcr-4960.patch > > > Because it's inherently prone to security issues, RMI should be disabled by > default. The documentation needs to be updated to reflect that and to explain > how to enable it again. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4957) jackrabbit-standalone: 2.21.18 breaks binary compatibility
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749149#comment-17749149
]
Manfred Baedke edited comment on JCR-4957 at 7/31/23 11:07 AM:
---
??I encourage you to use JApiCmp or RevApi which will then require you to
formally recognize what is an official break in compatibility. Otherwise,
you'll be leaving user (like me) with the joy of randomly discovering broken
APIs??
Thank you for the suggestion. We already use the baseline goal of the maven
bundle plugin for that. It was disabled in this particular case, because the
affected classes are not considered part of the public API.
was (Author: baedke):
??I encourage you to use JApiCmp or RevApi which will then require you to
formally recognize what is an official break in compatibility. Otherwise,
you'll be leaving user (like me) with the joy of randomly discovering broken
APIs??
Thank you for the suggestion. We already use the baseline goal of the maven
bundle plugin or that. It was disabled in this particular case, because the
affected classes are not considered part of the public API.
> jackrabbit-standalone: 2.21.18 breaks binary compatibility
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-standalone-components
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_jackrabbit_2_20
> Fix For: 2.22, 2.21.19
>
> Attachments: jcr-4957.patch
>
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCR-4957) jackrabbit-standalone: 2.21.18 breaks binary compatibility
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749149#comment-17749149
]
Manfred Baedke edited comment on JCR-4957 at 7/31/23 11:06 AM:
---
??I encourage you to use JApiCmp or RevApi which will then require you to
formally recognize what is an official break in compatibility. Otherwise,
you'll be leaving user (like me) with the joy of randomly discovering broken
APIs??
Thank you for the suggestion. We already use the baseline goal of the maven
bundle plugin or that. It was disabled in this particular case, because the
affected classes are not considered part of the public API.
was (Author: baedke):
??I encourage you to use JApiCmp or RevApi which will then require you to
formally recognize what is an official break in compatibility. Otherwise,
you'll be leaving user (like me) with the joy of randomly discovering broken
APIs ??
Thank you for the suggestion. We already use the baseline goal of the maven
bundle plugin or that. It was disabled in this particular case, because the
affected classes are not considered part of the public API.
> jackrabbit-standalone: 2.21.18 breaks binary compatibility
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-standalone-components
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_jackrabbit_2_20
> Fix For: 2.22, 2.21.19
>
> Attachments: jcr-4957.patch
>
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-4957) jackrabbit-standalone: 2.21.18 breaks binary compatibility
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749149#comment-17749149
]
Manfred Baedke commented on JCR-4957:
-
??I encourage you to use JApiCmp or RevApi which will then require you to
formally recognize what is an official break in compatibility. Otherwise,
you'll be leaving user (like me) with the joy of randomly discovering broken
APIs ??
Thank you for the suggestion. We already use the baseline goal of the maven
bundle plugin or that. It was disabled in this particular case, because the
affected classes are not considered part of the public API.
> jackrabbit-standalone: 2.21.18 breaks binary compatibility
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-standalone-components
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_jackrabbit_2_20
> Fix For: 2.22, 2.21.19
>
> Attachments: jcr-4957.patch
>
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCR-4960) Disable RMI by default
Manfred Baedke created JCR-4960: --- Summary: Disable RMI by default Key: JCR-4960 URL: https://issues.apache.org/jira/browse/JCR-4960 Project: Jackrabbit Content Repository Issue Type: Task Components: jackrabbit-jcr-rmi Reporter: Manfred Baedke Assignee: Manfred Baedke Because it's inherently prone to security issues, RMI should be disabled by default. The documentation needs to be updated to reflect that and to explain how to enable it again. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746932#comment-17746932
]
Manfred Baedke commented on JCR-4957:
-
??Good to know but it makes it near impossible to use GitHub's dependabot or
Maven's display dependency updates plugin; maybe the version should have an
"-unstable" or "-M" version postfix to make it obvious it should not be used as
a dependency.??
At least for the version plugin it should be possible to create an exclusion
rule based on RegEx.
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Manfred Baedke
>Priority: Major
> Attachments: jcr-4957.patch
>
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746890#comment-17746890
]
Manfred Baedke commented on JCR-4957:
-
Find attached a patch that passes a baseline check.
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Manfred Baedke
>Priority: Major
> Attachments: jcr-4957.patch
>
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCR-4958) Decide what jackrabbit-standalone-components should expose as public API
Manfred Baedke created JCR-4958: --- Summary: Decide what jackrabbit-standalone-components should expose as public API Key: JCR-4958 URL: https://issues.apache.org/jira/browse/JCR-4958 Project: Jackrabbit Content Repository Issue Type: Task Components: jackrabbit-standalone-components Reporter: Manfred Baedke Apache Commons VFS uses public methods of Classes that are part of jackrabbit-standalone-components (for testing purposes), but the baseline check is disabled here. We should decide about the public API we want to expose and introduce a baseline check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-4957:
Attachment: jcr-4957.patch
Status: Patch Available (was: Open)
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Manfred Baedke
>Priority: Major
> Attachments: jcr-4957.patch
>
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-4957:
Attachment: (was: jcr-4957.patch)
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Manfred Baedke
>Priority: Major
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-4957:
Status: Open (was: Patch Available)
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Manfred Baedke
>Priority: Major
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated JCR-4957:
Attachment: jcr-4957.patch
Status: Patch Available (was: In Progress)
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Manfred Baedke
>Priority: Major
> Attachments: jcr-4957.patch
>
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746825#comment-17746825
]
Manfred Baedke edited comment on JCR-4957 at 7/25/23 8:15 AM:
--
[~reschke]
??I really wasn't aware of this kind of usage.??
Me neither, which is unfortunate, because it's explicitly mentioned in the
JavaDoc. It should be easy to bring the old API back.
??If standalone-components is a public API, it should have OSGi annotations to
the baseline check manages API stability.??
Yes, we should create a separate issue for that.
??the main method really really is an aspect of the demo project??
Yes. The signature or semantics of the main method didn't change, though.
was (Author: baedke):
[~reschke]
??I really wasn't aware of this kind of usage.??
Me neither, which is unfortunate, because it's explicitly mentioned in the
JavaDoc. It should be easy to bring the old API back.
??If standalone-components is a public API, it should have OSGi annotations to
the baseline check manages API stability.??
Yes, we should create a separate issue for that.
??the main method really really is an aspect of the demo project??
Yes. The main method didn't change, though.
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Manfred Baedke
>Priority: Major
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746825#comment-17746825
]
Manfred Baedke edited comment on JCR-4957 at 7/25/23 8:14 AM:
--
[~reschke]
??I really wasn't aware of this kind of usage.??
Me neither, which is unfortunate, because it's explicitly mentioned in the
JavaDoc. It should be easy to bring the old API back.
??If standalone-components is a public API, it should have OSGi annotations to
the baseline check manages API stability.??
Yes, we should create a separate issue for that.
??the main method really really is an aspect of the demo project??
Yes. The main method didn't change, though.
was (Author: baedke):
[~reschke]
??I really wasn't aware of this kind of usage.??
Me neither, which is unfortunate, because it's explicitly mentioned in the
JavaDoc. It should be easy to bring the old API back.
??If standalone-components is a public API, it should have OSGi annotations to
the baseline check manages API stability.??
Yes, we should create a separate issue for that.
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Manfred Baedke
>Priority: Major
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746825#comment-17746825
]
Manfred Baedke commented on JCR-4957:
-
[~reschke]
??I really wasn't aware of this kind of usage.??
Me neither, which is unfortunate, because it's explicitly mentioned in the
JavaDoc. It should be easy to bring the old API back.
??If standalone-components is a public API, it should have OSGi annotations to
the baseline check manages API stability.??
Yes, we should create a separate issue for that.
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Priority: Major
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke reassigned JCR-4957:
---
Assignee: Manfred Baedke
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Manfred Baedke
>Priority: Major
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCR-4956) Replace deprecated Surefire fork options
[ https://issues.apache.org/jira/browse/JCR-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746445#comment-17746445 ] Manfred Baedke edited comment on JCR-4956 at 7/24/23 1:01 PM: -- We can actually just remove them, because the default forkCount=1 are just what we want. Find a patch attached. was (Author: baedke): We can actually just remove them, because the default forkCount=1 are just what we want. > Replace deprecated Surefire fork options > > > Key: JCR-4956 > URL: https://issues.apache.org/jira/browse/JCR-4956 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4956.patch > > > Some subprojects use the the deprecated Surefire option"forkMode" (or even > the option "fork", which AFAIK never existed). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4956) Replace deprecated Surefire fork options
[ https://issues.apache.org/jira/browse/JCR-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4956: Attachment: jcr-4956.patch Status: Patch Available (was: In Progress) > Replace deprecated Surefire fork options > > > Key: JCR-4956 > URL: https://issues.apache.org/jira/browse/JCR-4956 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: jcr-4956.patch > > > Some subprojects use the the deprecated Surefire option"forkMode" (or even > the option "fork", which AFAIK never existed). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-4956) Replace deprecated Surefire fork options
Manfred Baedke created JCR-4956: --- Summary: Replace deprecated Surefire fork options Key: JCR-4956 URL: https://issues.apache.org/jira/browse/JCR-4956 Project: Jackrabbit Content Repository Issue Type: Task Reporter: Manfred Baedke Assignee: Manfred Baedke Some subprojects use the the deprecated Surefire option"forkMode" (or even the option "fork", which AFAIK never existed). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17742329#comment-17742329 ] Manfred Baedke commented on JCR-4570: - Oups. Probably I ran the integration tests in a sub dir. Find a new patch attached. > 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, jcr-4570-2.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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: Status: Open (was: Patch Available) > 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, jcr-4570-2.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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-2.patch Status: Patch Available (was: Open) > 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, jcr-4570-2.patch > > > Also other lock types are completely ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (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:comment-tabpanel=17740635#comment-17740635 ] Manfred Baedke edited comment on JCR-4946 at 7/6/23 2:41 PM: - Since OAK-10166 is closed, the patch may be applied as soon as JCR-4570 and JCR-4571 are closed. was (Author: baedke): Since OAK-10166 is closed, the patch may be applied. > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17740635#comment-17740635 ] Manfred Baedke commented on JCR-4946: - Since OAK-10166 is closed, the patch may be applied. > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- 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: Status: Open (was: Patch Available) > 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. > Also, the case sensitivity of the lock token comparison is not tested . -- 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: Attachment: jcr-4946.patch Status: Patch Available (was: Open) > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- 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: Attachment: (was: jcr-4946.patch) > 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. > Also, the case sensitivity of the lock token comparison is not tested . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17740594#comment-17740594 ] Manfred Baedke commented on JCR-4945: - [~kwin], you are absolutely right, don't know what went wrong there and what I was thinking. Thanks for catching that. New patch file attached. > 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] [Commented] (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:comment-tabpanel=17740577#comment-17740577 ] Manfred Baedke commented on JCR-4945: - [~kwin], ok, then I agree that it should work. It did not with my initial tests, but I will retry with the current version. > 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 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:comment-tabpanel=17740573#comment-17740573 ] Manfred Baedke commented on JCR-4945: - Well, it doesn't. If we don't do the explicit import, maven will create an import of [1.7.x,2) > 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 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:comment-tabpanel=17740573#comment-17740573 ] Manfred Baedke edited comment on JCR-4945 at 7/6/23 12:06 PM: -- [~kwin], well, it doesn't. If we don't do the explicit import, maven will create an import of [1.7.x,2) was (Author: baedke): Well, it doesn't. If we don't do the explicit import, maven will create an import of [1.7.x,2) > 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 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:comment-tabpanel=17740569#comment-17740569 ] Manfred Baedke commented on JCR-4945: - Hi [~kwin], I don't understand, Jackrabbit has no package imports besides org.slf4j. This Ticket is just about testing that Jackrabbit will run in a Container where slf4j 2 ist deployed. > 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-4944) upgrade to Tomcat 9.x
[ https://issues.apache.org/jira/browse/JCR-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4944: Attachment: jcr-4944.patch Status: Patch Available (was: In Progress) Patch upgrades to Tomcat 9.0.76. > upgrade to Tomcat 9.x > - > > Key: JCR-4944 > URL: https://issues.apache.org/jira/browse/JCR-4944 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-webapp >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4944.patch > > > Tomcat 8.5 will be EOLd in 2024. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (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:comment-tabpanel=17740239#comment-17740239 ] Manfred Baedke edited comment on JCR-4946 at 7/5/23 2:38 PM: - Unfortunately the patch increases the minor version of the package org.apache.jackrabbit.webdav.lock. I don't know a way to prevent that, though I think increasing the micro version would be appropriate here. I guess it's not a big deal. was (Author: baedke): Unfortunately the patch increases the major version of the package org.apache.jackrabbit.webdav.lock. I don't know a way to prevent that. I guess it's not a big deal. > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17740239#comment-17740239 ] Manfred Baedke commented on JCR-4946: - Unfortunately the patch increases the major version of the package org.apache.jackrabbit.webdav.lock. I don't know a way to prevent that. I guess it's not a big deal. > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (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:comment-tabpanel=17740238#comment-17740238 ] Manfred Baedke edited comment on JCR-4946 at 7/5/23 2:32 PM: - Patches for JCR-4570 and JCR-4571 should be applied first. Then we should decide if the tested behavior is correct at all, see OAK-10166. If it's not AbstractActiveLock#isLockedByToken(String) and IfHeaderEntryToken#match(String, String) have to be changed as indicated by the inline comments (kudos to balamir.ko...@gmail.com who pointed that out on oak-dev). was (Author: baedke): Patches for JCR-4570 and JCR-4571 should be applied first. Then we should decide if the tested behavior is correct at all, see OAK-10166. If it's not AbstractActiveLock#isLockedByToken(String) and IfHeaderEntryToken#match(String, String) have to be changed as indicated by the inline comments. > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (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:comment-tabpanel=17740238#comment-17740238 ] Manfred Baedke edited comment on JCR-4946 at 7/5/23 2:30 PM: - Patches for JCR-4570 and JCR-4571 should be applied first. Then we should decide if the tested behavior is correct at all, see OAK-10166. If it's not AbstractActiveLock#isLockedByToken(String) and IfHeaderEntryToken#match(String, String) have to be changed as indicated by the inline comments. was (Author: baedke): Patches for JCR-4570 and JCR-4571 should be applied first. Then we should decide if the tested behavior is correct at all, see OAK-10166. > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17740238#comment-17740238 ] Manfred Baedke commented on JCR-4946: - Patches for JCR-4570 and JCR-4571 should be applied first. Then we should decide if the tested behavior is correct at all, see OAK-10166. > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- 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: Attachment: jcr-4946.patch Status: Patch Available (was: In Progress) > 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 > Attachments: jcr-4946.patch > > > The method ActiveLock#isLockedByToken(String lockToken) is implemented at > several places, but only needs one implementation in AbstractActiveLock. > Also, the case sensitivity of the lock token comparison is not tested . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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 Status: Patch Available (was: In Progress) > 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.20.10#820010)
[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 > Attachments: jcr-4571.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17740211#comment-17740211 ] Manfred Baedke commented on JCR-4570: - New patch attached. > 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.20.10#820010)
[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 Status: Patch Available (was: In Progress) > 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.20.10#820010)
[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: (was: 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.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 at several places, but only needs one implementation in AbstractActiveLock. Also, the case sensitivity of the lock token comparison is not tested . was: The method ActiveLock#isLockedByToken(String lockToken) is implemented at several places, but only needs one implementation in AbstractActiveLock. Also, no tests are failing if we change the case sensitivity of the lock token comparison. > 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. > Also, the case sensitivity of the lock token comparison is not tested . -- 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 at several places, but only needs one implementation in AbstractActiveLock. Also, no tests are failing when we change the case sensitivity of the lock token comparison. was: The method ActiveLock#isLockedByToken(String lockToken) is implemented at several places, but only needs one implementation in AbstractActiveLock. Also, no tests will fail when we change the case sensitivity of the lock token comparison. > 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. > Also, no tests are failing when we change the case sensitivity of the lock > token comparison. -- 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 at several places, but only needs one implementation in AbstractActiveLock. Also, no tests are failing if we change the case sensitivity of the lock token comparison. was: The method ActiveLock#isLockedByToken(String lockToken) is implemented at several places, but only needs one implementation in AbstractActiveLock. Also, no tests are failing when we change the case sensitivity of the lock token comparison. > 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. > Also, no tests are failing if we change the case sensitivity of the lock > token comparison. -- 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 at several places, but only needs one implementation in AbstractActiveLock. Also, no tests will fail when we change the case sensitivity of the lock token comparison. was:The method ActiveLock#isLockedByToken(String lockToken) is implemented at several places, but only needs one implementation in AbstractActiveLock. > 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. > Also, no tests will fail when we change the case sensitivity of the lock > token comparison. -- This message was sent by Atlassian Jira (v8.20.10#820010)
