[jira] [Commented] (JCR-4146) json extension is removed by AbstractWebdavServlet on COPY request

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4146:
-

See in JcrRemotingServlet...:

{noformat}
/**
 * Locator factory that specially deals with hrefs having a .json extension.
 */
{noformat}


> json extension is removed by AbstractWebdavServlet on COPY request
> --
>
> Key: JCR-4146
> URL: https://issues.apache.org/jira/browse/JCR-4146
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.15.3
>Reporter: Ana Vinatoru
>Assignee: Julian Reschke
>
> This issue was first observed via crxDE: the user did a copy / paste on a 
> node with the .json extension (let's say test.json). After saving, the new 
> node was named "Copy of test" instead of "Copy of test.json".
> I tracked the request to the AbstractWebdavServlet.doCopy method - and this 
> is where the .json extension seems to be lost.
> The Destination header sent by crxde includes the extension, but the new 
> resource created in doCopy does not have it.
> The request looked like this:
> {code:java}
> curl -u admin:admin 
> 'http://localhost:4502/crx/server/crx.default/jcr%3aroot/libs/test.json' -X 
> COPY -H 'Overwrite: T' -H 'Destination: 
> /crx/server/crx.default/jcr%3aroot/libs/Copy%20of%20test.json' -v
> {code}
> To rule out issues in other layers, I tested with the Jackrabbit 2.14.x 
> standalone.
> I uploaded the test.json file via WebDav, then executed the following curl 
> request:
> {code:java}
> curl -u admin:admin 'http://localhost:9001/server/default/jcr:root/test.json' 
> -X COPY -H 'Overwrite: T' -H 'Destination: 
> /server/default/jcr:root/copytest.json' -v
> {code}
> The new node was created, but instead of being named "copytest.json", it is 
> called "copytest".



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

[jira] [Commented] (JCR-4147) clirr profile needs to use sensible baselines

[angela (JIRA)]

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

angela commented on JCR-4147:
-

[~reschke], i only learned about the clirr profile yesterday... looking at 
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/package-info.java?view=log
 it seems that i don't have amnesia it really was never updated since Jukka 
introduced it  5 years ago... all the API extensions we added got "unnoticed" 
from a export version pov.

+1 for both suggestions.

> clirr profile needs to use sensible baselines
> -
>
> Key: JCR-4147
> URL: https://issues.apache.org/jira/browse/JCR-4147
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.15.4
>
>
> For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 
> throughout. This doesn't make any sense, it should be the previous stable 
> release.



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

[jira] [Resolved] (JCR-4137) Release Jackrabbit 2.15.3

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4137.
-
Resolution: Fixed

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




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

[ANNOUNCE] Apache Jackrabbit 2.15.3 released

[Julian Reschke]

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

https://jackrabbit.apache.org/jcr/downloads.html#v2.15

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

Release Notes -- Apache Jackrabbit -- Version 2.15.3

Introduction


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

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

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

Changes in Jackrabbit 2.15.3


Bug

[JCR-3901] - TCK LockManagerTest does not allow new JCR 2.0 
functionality for lock token transfers

[JCR-4135] - potential NPE in FSBackend

Task

[JCR-4134] - update build instructions wrt Java versions
[JCR-4139] - Update commons-fileupload dependency to 1.3.2
[JCR-4140] - Update easymock dependency to 3.4
[JCR-4142] - update junit dependency to 4.12
[JCR-4143] - update findbugs dependency to 3.0.2

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

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

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

Release Contents


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

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

About Apache Jackrabbit
---

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

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

About The Apache Software Foundation


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

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

Trademarks
--

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

Jackrabbit project logo are trademarks of The Apache Software Foundation.

[jira] [Closed] (JCR-4134) update build instructions wrt Java versions

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4134.
---

> update build instructions wrt Java versions
> ---
>
> Key: JCR-4134
> URL: https://issues.apache.org/jira/browse/JCR-4134
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: docs
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.14.1, 2.15.3
>
>
> Applies both to website and README.TXT.



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

[jira] [Closed] (JCR-4142) update junit dependency to 4.12

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4142.
---

> update junit dependency to 4.12
> ---
>
> Key: JCR-4142
> URL: https://issues.apache.org/jira/browse/JCR-4142
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_8
> Fix For: 2.16, 2.15.3
>
>




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

[jira] [Closed] (JCR-4139) Update commons-fileupload dependency to 1.3.2

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4139.
---

> Update commons-fileupload dependency to 1.3.2
> -
>
> Key: JCR-4139
> URL: https://issues.apache.org/jira/browse/JCR-4139
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_8
> Fix For: 2.16, 2.15.3
>
>




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

[jira] [Closed] (JCR-4135) potential NPE in FSBackend

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4135.
---

> potential NPE in FSBackend
> --
>
> Key: JCR-4135
> URL: https://issues.apache.org/jira/browse/JCR-4135
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-data
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.16, 2.15.3
>
>




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

[jira] [Closed] (JCR-3901) TCK LockManagerTest does not allow new JCR 2.0 functionality for lock token transfers

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-3901.
---

> TCK LockManagerTest does not allow new JCR 2.0 functionality for lock token 
> transfers
> -
>
> Key: JCR-3901
> URL: https://issues.apache.org/jira/browse/JCR-3901
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: test
>Affects Versions: 2.10.1, 2.8.1, 2.11.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_8
> Fix For: 2.16, 2.15.3
>
>
> testLockTransfer2() and testAddLockTokenToAnotherSession() assume that it's 
> always illegal to add lock tokens to multiple sessions, however 
>  allows 
> simultaneous lock ownership for open scoped locks.



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

[jira] [Closed] (JCR-4140) Update easymock dependency to 3.4

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4140.
---

> Update easymock dependency to 3.4
> -
>
> Key: JCR-4140
> URL: https://issues.apache.org/jira/browse/JCR-4140
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: parent, test
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 2.16, 2.15.3
>
>




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

[jira] [Closed] (JCR-4143) update findbugs dependency to 3.0.2

[Julian Reschke (JIRA)]

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

Julian Reschke closed JCR-4143.
---

> update findbugs dependency to 3.0.2
> ---
>
> Key: JCR-4143
> URL: https://issues.apache.org/jira/browse/JCR-4143
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_8
> Fix For: 2.16, 2.15.3
>
>




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

[RESULT] [VOTE] Release Apache Jackrabbit 2.15.3

[Julian Reschke]

On 2017-06-09 14:56, Julian Reschke wrote:

A candidate for the Jackrabbit 2.15.3 release is available at:
...


Hi there,

the vote passes as follows:

+1 Claus Köll 
+1 Davide Giannella 
+1 Julian Reschke 
+1 Marcel Reutegger 
+1 Robert Munteanu 

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

Best regards, Julian

[jira] [Created] (JCRVLT-182) Remove 'path' property from the properties.xml

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-182:
---

 Summary: Remove 'path' property from the properties.xml
 Key: JCRVLT-182
 URL: https://issues.apache.org/jira/browse/JCRVLT-182
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: Packaging
Affects Versions: 3.1.38
Reporter: Tobias Bocanegra


The path property is a reminder of 5 year old legacy behavior that used the 
path to install the package in the repository. since then we no longer rely on 
the path but use the package id.
in the light having an storage abstraction, this property really isn't needed 
anymore.




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

[jira] [Comment Edited] (JCR-4146) json extension is removed by AbstractWebdavServlet on COPY request

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on JCR-4146 at 6/14/17 12:56 PM:
---

OK, so this works correctly when using the simple WebDAV servlet 
({{/repository/default}} instead of {{/server/default/jcr%3aroot/}}).

Will have a look why the remoting servlet behaves differently.


was (Author: reschke):
OK, so this works correctly when using the simple WebDAV servlet 
(/repository/default instead of /server/default/jcr%3aroot/).

Will have a look why the remoting servlet behaves differently.

> json extension is removed by AbstractWebdavServlet on COPY request
> --
>
> Key: JCR-4146
> URL: https://issues.apache.org/jira/browse/JCR-4146
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.15.3
>Reporter: Ana Vinatoru
>Assignee: Julian Reschke
>
> This issue was first observed via crxDE: the user did a copy / paste on a 
> node with the .json extension (let's say test.json). After saving, the new 
> node was named "Copy of test" instead of "Copy of test.json".
> I tracked the request to the AbstractWebdavServlet.doCopy method - and this 
> is where the .json extension seems to be lost.
> The Destination header sent by crxde includes the extension, but the new 
> resource created in doCopy does not have it.
> The request looked like this:
> {code:java}
> curl -u admin:admin 
> 'http://localhost:4502/crx/server/crx.default/jcr%3aroot/libs/test.json' -X 
> COPY -H 'Overwrite: T' -H 'Destination: 
> /crx/server/crx.default/jcr%3aroot/libs/Copy%20of%20test.json' -v
> {code}
> To rule out issues in other layers, I tested with the Jackrabbit 2.14.x 
> standalone.
> I uploaded the test.json file via WebDav, then executed the following curl 
> request:
> {code:java}
> curl -u admin:admin 'http://localhost:9001/server/default/jcr:root/test.json' 
> -X COPY -H 'Overwrite: T' -H 'Destination: 
> /server/default/jcr:root/copytest.json' -v
> {code}
> The new node was created, but instead of being named "copytest.json", it is 
> called "copytest".



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

[jira] [Commented] (JCR-4146) json extension is removed by AbstractWebdavServlet on COPY request

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4146:
-

OK, so this works correctly when using the simple WebDAV servlet 
(/repository/default instead of /server/default/jcr%3aroot/).

Will have a look why the remoting servlet behaves differently.

> json extension is removed by AbstractWebdavServlet on COPY request
> --
>
> Key: JCR-4146
> URL: https://issues.apache.org/jira/browse/JCR-4146
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.15.3
>Reporter: Ana Vinatoru
>Assignee: Julian Reschke
>
> This issue was first observed via crxDE: the user did a copy / paste on a 
> node with the .json extension (let's say test.json). After saving, the new 
> node was named "Copy of test" instead of "Copy of test.json".
> I tracked the request to the AbstractWebdavServlet.doCopy method - and this 
> is where the .json extension seems to be lost.
> The Destination header sent by crxde includes the extension, but the new 
> resource created in doCopy does not have it.
> The request looked like this:
> {code:java}
> curl -u admin:admin 
> 'http://localhost:4502/crx/server/crx.default/jcr%3aroot/libs/test.json' -X 
> COPY -H 'Overwrite: T' -H 'Destination: 
> /crx/server/crx.default/jcr%3aroot/libs/Copy%20of%20test.json' -v
> {code}
> To rule out issues in other layers, I tested with the Jackrabbit 2.14.x 
> standalone.
> I uploaded the test.json file via WebDav, then executed the following curl 
> request:
> {code:java}
> curl -u admin:admin 'http://localhost:9001/server/default/jcr:root/test.json' 
> -X COPY -H 'Overwrite: T' -H 'Destination: 
> /server/default/jcr:root/copytest.json' -v
> {code}
> The new node was created, but instead of being named "copytest.json", it is 
> called "copytest".



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

Jackrabbit-trunk - Build # 2497 - Fixed

[Apache Jenkins Server]

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

Status: Fixed

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

[jira] [Commented] (JCR-4147) clirr profile needs to use sensible baselines

[Davide Giannella (JIRA)]

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

Davide Giannella commented on JCR-4147:
---

+1 for latest stable release. Even though it depends on for how long we want to 
keep compatibility. We *may* have to be compatible to something earlier than 
2.14.0 depending purely on arbitrary team decision.

+1 for moving this to baseline for trunk (2.15.x)

> clirr profile needs to use sensible baselines
> -
>
> Key: JCR-4147
> URL: https://issues.apache.org/jira/browse/JCR-4147
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.15.4
>
>
> For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 
> throughout. This doesn't make any sense, it should be the previous stable 
> release.



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

[jira] [Reopened] (JCR-4147) clirr profile needs to use sensible baselines

[Julian Reschke (JIRA)]

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

Julian Reschke reopened JCR-4147:
-

> clirr profile needs to use sensible baselines
> -
>
> Key: JCR-4147
> URL: https://issues.apache.org/jira/browse/JCR-4147
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.15.4
>
>
> For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 
> throughout. This doesn't make any sense, it should be the previous stable 
> release.



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

[jira] [Commented] (JCR-4147) clirr profile needs to use sensible baselines

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4147:
-

Ok, after digging further, it seems that clirr can only check compatibility, 
not semantic versioning.

Thus:

- release branches should use a clirr baseline of their *.0 version
- trunk doesn't need a clirr check

Does this sound right? It would also mean that we need to introduce baseline 
checks to check the versions of exported packages.

> clirr profile needs to use sensible baselines
> -
>
> Key: JCR-4147
> URL: https://issues.apache.org/jira/browse/JCR-4147
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.15.4
>
>
> For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 
> throughout. This doesn't make any sense, it should be the previous stable 
> release.



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

[jira] [Commented] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4144:
-

See JCR-4147 - I have updated the baseline version for the clirr check to 
2.14.0, and now the check passes (without the changes for this ticket which 
will require a version change)

> JackrabbitAccessControlList should have an API boolean 
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String 
> restrictionName).
> This method returns the type of the restriction specified restrictionName. 
> Although, it does not provide enough information to deduce whether 
> restriction is defined to accept single or multiple values. Hence, a method 
> with following signature should be added to this API
> {code}
>   boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\] 
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html



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

[jira] [Commented] (JCR-4147) clirr profile needs to use sensible baselines

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4147:
-

trunk: [r1798666|http://svn.apache.org/r1798666]


> clirr profile needs to use sensible baselines
> -
>
> Key: JCR-4147
> URL: https://issues.apache.org/jira/browse/JCR-4147
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.15.4
>
>
> For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 
> throughout. This doesn't make any sense, it should be the previous stable 
> release.



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

[jira] [Resolved] (JCR-4147) clirr profile needs to use sensible baselines

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4147.
-
   Resolution: Fixed
Fix Version/s: 2.15.4

> clirr profile needs to use sensible baselines
> -
>
> Key: JCR-4147
> URL: https://issues.apache.org/jira/browse/JCR-4147
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.15.4
>
>
> For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 
> throughout. This doesn't make any sense, it should be the previous stable 
> release.



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

[jira] [Updated] (JCR-4147) clirr profile needs to use sensible baselines

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4147:

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

> clirr profile needs to use sensible baselines
> -
>
> Key: JCR-4147
> URL: https://issues.apache.org/jira/browse/JCR-4147
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
>
> For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 
> throughout. This doesn't make any sense, it should be the previous stable 
> release.



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

[jira] [Commented] (JCR-4147) clirr profile needs to use sensible baselines

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4147:
-

[~mreutegg], [~anchela], [~edivad] - feedback appreciated - also, should we 
move over to baseline? I assume the reason why we use clirr here is entirely 
historic?

> clirr profile needs to use sensible baselines
> -
>
> Key: JCR-4147
> URL: https://issues.apache.org/jira/browse/JCR-4147
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>
> For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 
> throughout. This doesn't make any sense, it should be the previous stable 
> release.



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

[jira] [Created] (JCR-4147) clirr profile needs to use sensible baselines

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4147:
---

 Summary: clirr profile needs to use sensible baselines
 Key: JCR-4147
 URL: https://issues.apache.org/jira/browse/JCR-4147
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-parent
Reporter: Julian Reschke
Assignee: Julian Reschke


For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 
throughout. This doesn't make any sense, it should be the previous stable 
release.



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

[jira] [Commented] (JCR-4146) json extension is removed by AbstractWebdavServlet on COPY request

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4146:
-

Something like that. Will investigate.

> json extension is removed by AbstractWebdavServlet on COPY request
> --
>
> Key: JCR-4146
> URL: https://issues.apache.org/jira/browse/JCR-4146
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.15.3
>Reporter: Ana Vinatoru
>Assignee: Julian Reschke
>
> This issue was first observed via crxDE: the user did a copy / paste on a 
> node with the .json extension (let's say test.json). After saving, the new 
> node was named "Copy of test" instead of "Copy of test.json".
> I tracked the request to the AbstractWebdavServlet.doCopy method - and this 
> is where the .json extension seems to be lost.
> The Destination header sent by crxde includes the extension, but the new 
> resource created in doCopy does not have it.
> The request looked like this:
> {code:java}
> curl -u admin:admin 
> 'http://localhost:4502/crx/server/crx.default/jcr%3aroot/libs/test.json' -X 
> COPY -H 'Overwrite: T' -H 'Destination: 
> /crx/server/crx.default/jcr%3aroot/libs/Copy%20of%20test.json' -v
> {code}
> To rule out issues in other layers, I tested with the Jackrabbit 2.14.x 
> standalone.
> I uploaded the test.json file via WebDav, then executed the following curl 
> request:
> {code:java}
> curl -u admin:admin 'http://localhost:9001/server/default/jcr:root/test.json' 
> -X COPY -H 'Overwrite: T' -H 'Destination: 
> /server/default/jcr:root/copytest.json' -v
> {code}
> The new node was created, but instead of being named "copytest.json", it is 
> called "copytest".



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

[jira] [Commented] (JCR-4146) json extension is removed by AbstractWebdavServlet on COPY request

[angela (JIRA)]

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

angela commented on JCR-4146:
-

i would need to dig into the code again... wild guess: could it be that the 
.json ending gets interpreted as a hint to process the request with the 
remoting-servlet instead of the default webdav server servlet?

> json extension is removed by AbstractWebdavServlet on COPY request
> --
>
> Key: JCR-4146
> URL: https://issues.apache.org/jira/browse/JCR-4146
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.15.3
>Reporter: Ana Vinatoru
>Assignee: Julian Reschke
>
> This issue was first observed via crxDE: the user did a copy / paste on a 
> node with the .json extension (let's say test.json). After saving, the new 
> node was named "Copy of test" instead of "Copy of test.json".
> I tracked the request to the AbstractWebdavServlet.doCopy method - and this 
> is where the .json extension seems to be lost.
> The Destination header sent by crxde includes the extension, but the new 
> resource created in doCopy does not have it.
> The request looked like this:
> {code:java}
> curl -u admin:admin 
> 'http://localhost:4502/crx/server/crx.default/jcr%3aroot/libs/test.json' -X 
> COPY -H 'Overwrite: T' -H 'Destination: 
> /crx/server/crx.default/jcr%3aroot/libs/Copy%20of%20test.json' -v
> {code}
> To rule out issues in other layers, I tested with the Jackrabbit 2.14.x 
> standalone.
> I uploaded the test.json file via WebDav, then executed the following curl 
> request:
> {code:java}
> curl -u admin:admin 'http://localhost:9001/server/default/jcr:root/test.json' 
> -X COPY -H 'Overwrite: T' -H 'Destination: 
> /server/default/jcr:root/copytest.json' -v
> {code}
> The new node was created, but instead of being named "copytest.json", it is 
> called "copytest".



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

[REPORT] Jackrabbit - June 2017

[Michael Dürig]

## Description:
The Apache Jackrabbit™ content repository is a fully conforming
implementation of the Content Repository for Java™ Technology API
(JCR, specified in JSR 170 and 283). The Jackrabbit content
repository is stable, largely feature complete and actively being
maintained.
Jackrabbit Oak is an effort to implement a scalable and performant
hierarchical content repository as a modern successor to the Apache
Jackrabbit content repository. It is targeted for use as the
foundation of modern world-class web sites and other demanding
content applications. In contrast to its predecessor, Oak does not
implement all optional features from the JSR specifications and it
is not a reference implementation.

## Issues:
There are no issues requiring board attention at this time.

## Activity:
Apache Jackrabbit Oak receives most attention nowadays. All
maintenance branches and the unstable development branch are
continuously seeing moderate to high activity.

Apache Jackrabbit itself is mostly in maintenance mode with most of
the work going into bug fixing and tooling. New features are mainly
driven by dependencies from Oak.

The PMC resolved the impact of the recently published SHA-1 collisions
in the development branch. Back ports to maintenance branches are under
consideration.

The last quarter saw a much needed and anticipated refactoring of
the Oak code base leading to an overall improved and simplified module
structure. While some of this work is still ongoing we expect it to
have a positive effect on the overall evolvability and maintainability
of the code base.

We will be holding an Oak Hackathon August 21st to 25th in Basel,
Switzerland (https://wiki.apache.org/jackrabbit/Oakathon%20August%202017).
Attendance is open and free to everybody wanting to hack Oak.

## Health report:
The project is healthy with a continuous stream of traffic on all
mailing lists reflecting the activity of the respective component.

There is a wide range of topics being discussed on the dev and user
lists as well as on the various JIRA issues.

Commit activity is moderate to high mirroring the activity on the
JIRA issues.

## PMC changes:
 - Currently 51 PMC members.
 - Robert Munteanu was added to the PMC on Mon May 22 2017

## Committer base changes:
 - Currently 51 committers.
 - Robert Munteanu was added as a committer on Mon May 22 2017

## Releases:
 - jackrabbit-2.12.7 was released on Mon Apr 03 2017
 - jackrabbit-2.14.1 was released on Mon May 29 2017
 - jackrabbit-2.15.2 was released on Mon May 01 2017
 - jackrabbit-2.15.3 was released on Fri Jun 09 2017
 - oak-1.0.38 was released on Tue Mar 28 2017
 - oak-1.2.25 was released on Tue Apr 11 2017
 - oak-1.2.26 was released on Mon Jun 05 2017
 - oak-1.4.15 was released on Mon Apr 03 2017
 - oak-1.4.16 was released on Mon Jun 05 2017
 - oak-1.6.2 was released on Mon Jun 12 2017
 - oak-1.7.0 was released on Wed May 24 2017
 - oak-1.7.1 was released on Tue Jun 06 2017
 - vault-3.1.38 was released on Mon Mar 27 2017

## JIRA activity:
 - 451 JIRA tickets created in the last 3 months
 - 397 JIRA tickets closed/resolved in the last 3 months