[jira] [Commented] (JCR-4005) TestVFSDataStore.testDeleteRecord() fails occasionally

2016-08-22 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on JCR-4005:
-

GitHub user woonsan opened a pull request:

https://github.com/apache/jackrabbit/pull/37

JCR-4005: fixing unit test. Disable asynchronous writing in unit test.

- Provide an option to disable asynchronous writing in the VFSDataStore. If 
asyncWritePoolSize is zero or less, it creates an ImmediateExecutor instead of 
ThreadPoolExecutor.
- Disable asynchronous writing in unit tests (with local file system).


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/woonsan/jackrabbit bugfix/JCR-4005

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jackrabbit/pull/37.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #37


commit 97753d367d6d5126de985b99c00bdcc992752d7c
Author: Woonsan Ko 
Date:   2016-08-23T05:11:40Z

JCR-4005: fixing unit test. Disable asynchronous writing in unit test.




> TestVFSDataStore.testDeleteRecord() fails occasionally
> --
>
> Key: JCR-4005
> URL: https://issues.apache.org/jira/browse/JCR-4005
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-vfs-ext
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The test failed on Jenkins and also fails occasionally on my machine:
> https://builds.apache.org/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-vfs-ext/2369/console



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4005) TestVFSDataStore.testDeleteRecord() fails occasionally

2016-08-22 Thread Woonsan Ko (JIRA) 

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

Woonsan Ko commented on JCR-4005:
-

I think I figured out the root cause.
It occasionally fails in the {{assertNull}} line below.
{code}
protected void doDeleteRecordTest() throws Exception {
// SNIP
DataRecord rec2 = ds.addRecord(new ByteArrayInputStream(data2));
// SNIP
((MultiDataStoreAware)ds).deleteRecord(rec2.getIdentifier());

assertNull("rec2 should be null",
ds.getRecordIfStored(rec2.getIdentifier()));
{code}

The reason is as follows:
- By default, a CachingDataStore (such as VFSDataStore) writes data to the 
backend asynchronously when invoking {{DataStore#addRecord()}}.
- If this asynchronous job doesn't complete before invoking 
{{DataStore#deleteRecord()}}, the deletion actually didn't happen. As a result, 
the assertion of the deletion fails.

For more detail, here's an invocation flow:
- CachingDataStore#addRecord()
--> VFSBackend#writeAsync()
--> new CachingDataRecord()
--> CachingDataRecord#getLength()
--> CachingDataStore#getLength()
 (if not found in {{recLenCache}}, put in a new item : 
{{recLenCache.put(identifier, length)}}.)

Meanwhile, the {{DataStore#deleteRecord()}} could complete its call before 
{{CachingDataStore#getLength()}} completes. Therefore, the same identifier can 
be just added to {{recLenCache}} even if it was supposed to be deleted in 
another thread.

Also, {{DataStore#getRecordIfStored()}} returns a {{CachingDataRecord}} 
instance because it finds the (deleted) item from {{recLenCache}}. (See 
{{CachingDataStore#getRecordIfStored()}}).

-

I think this is caused by the difference between how {{TestCaseBase}} was 
implemented and how {{CachingDataStore}} was designed.
{{CachingDataStore}} enables asynchronous writing to the backend by default 
(actually always). Therefore, unless the DataStore does something very special 
when writing asynchronously and reading synchronously, this problem should 
always happen.
In contrast, {{TestCaseBase}} seems to have been implemented originally for 
non-Caching DataStore implementations that do not have any asynchronous writing.
At the moment, {{CachingDataStore}} doesn't care about synchronous 
deleting/reading while adding(writing) something asynchronously. And it seems 
more complex if we want to care about that (even in the future).

Therefore, my conclusion is:
- Simply provide an option to disable asynchronous writing in the VFSDataStore,
- and disable asynchronous writing in unit tests (with local file system).
- In reality, users can still enable asynchronous writing. In that case, they 
should be aware that a delete invocation might fail. I guess this can be 
acceptable in many practical use cases.

> TestVFSDataStore.testDeleteRecord() fails occasionally
> --
>
> Key: JCR-4005
> URL: https://issues.apache.org/jira/browse/JCR-4005
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-vfs-ext
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The test failed on Jenkins and also fails occasionally on my machine:
> https://builds.apache.org/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-vfs-ext/2369/console



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jackrabbit-trunk - Build # 2371 - Fixed

2016-08-22 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Jackrabbit-trunk (build #2371)

Status: Fixed

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

[ANNOUNCE] Apache Jackrabbit Filevault 3.1.28 released

2016-08-22 Thread Tobias Bocanegra 
The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Filevault 3.1.28. The release is available for download at:

https://dist.apache.org/repos/dist/release/jackrabbit/filevault/3.1.28/

See the release notes below for details about this release:

Introduction

The FileVault introduces a JCR repository to filesystem mapping. The mapping
is exposed by and API and used by the _CRX Content Packaging_  that allows to
create portable packages of repository content.

The Vault Command Line Interface aka _vlt_ that provides a subversion like
utility to work and develop with repository content.


Changes in Jackrabbit FileVault 3.1.28
--
Bug Fixes:
* [JCRVLT-89] - JcrPackageImpl.uninstall() throws exception if
snapshot is missing
* [JCRVLT-108] - Import of binaries fail because they cannot be
converted to strings
* [JCRVLT-114] - Subpackage extraction that contains vlt:definitiion
might already have installed state
* [JCRVLT-117] - Potential XSS problem in
org.apache.jackrabbit.vault.util.HtmlProgressListener
* [JCRVLT-121] - Credential challenge incorrect for dst server in rcp

Improvements:
* [JCRVLT-105] - Use Node.setPrimaryType() when changing primary type.
* [JCRVLT-113] - Skip installation of sub packages if newer version is
already present and installed
* [JCRVLT-116] - InstallHookProcessor.Hook should not only use TCCL as fallback
* [JCRVLT-120] - Allow to filter content properties based on property
name and value
* [JCRVLT-122] - Avoid deprecated Item.save()

.
.
.
Continue reading on
https://dist.apache.org/repos/dist/release/jackrabbit/filevault/3.1.28/RELEASE-NOTES.txt
.
.
.

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://www.apache.org/dist/jackrabbit/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 100 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 2,500+ 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.

[VOTE][RESULT] Release Apache Jackrabbit Filevault 3.1.28

2016-08-22 Thread Tobias Bocanegra 
Hello Team,

the vote passes as follows:

+1 Tobias Bocanegra
+1 Marcel Reutegger
+1 Stefan Guggisberg
+1 Timothee Maret (non binding)

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

On Mon, Aug 22, 2016 at 10:22 PM, Stefan Guggisberg  wrote:
>> Please vote on releasing this package as Apache Jackrabbit Filevault 3.1.28.
>> The vote is open for the next 72 hours and passes if a majority of at
>> least three +1 Jackrabbit PMC votes are cast.
>>
>> [ ] +1 Release this package as Apache Jackrabbit Filevault 3.1.28
>> [ ] -1 Do not release this package because...
>
> verified signature,
> checked sha1 digest,
> built from source and successfully ran all tests
>
> +1 Release this package as Apache Jackrabbit Filevault 3.1.28
>
> cheers
> stefan

Re: Jackrabbit-trunk - Build # 2369 - Unstable

2016-08-22 Thread Marcel Reutegger 

Created JCR-4005.

Regards
 Marcel

On 22/08/16 12:55, Apache Jenkins Server wrote:

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

Status: Unstable

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

Re: [VOTE] Release Apache Jackrabbit Filevault 3.1.28

2016-08-22 Thread Stefan Guggisberg 
> Please vote on releasing this package as Apache Jackrabbit Filevault 3.1.28.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Filevault 3.1.28
> [ ] -1 Do not release this package because...

verified signature,
checked sha1 digest,
built from source and successfully ran all tests

+1 Release this package as Apache Jackrabbit Filevault 3.1.28

cheers
stefan

Jackrabbit-trunk - Build # 2370 - Failure

2016-08-22 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Jackrabbit-trunk (build #2370)

Status: Failure

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

[jira] [Commented] (JCR-3997) TraversingItemVisitor causes stackoverflowexception with breadth first traversal

2016-08-22 Thread Ankit Agarwal (JIRA) 

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

Ankit Agarwal commented on JCR-3997:


[~chetanm] I have updated the pull request with test case.

thanks,

> TraversingItemVisitor causes stackoverflowexception with breadth first 
> traversal
> 
>
> Key: JCR-3997
> URL: https://issues.apache.org/jira/browse/JCR-3997
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Reporter: Chetan Mehrotra
> Fix For: 2.13.2
>
> Attachments: OAK-4549-test.patch
>
>
> [TraversingItemVisitor|https://docs.adobe.com/docs/en/spec/jsr170/javadocs/jcr-1.0/javax/jcr/util/TraversingItemVisitor.html]
>  when used in breadth first traversal mode can lead to StackOverflowException 
> with very flat child list. This happens because it uses recursion [1] instead 
> of plain iteration which would increase the stack size proportional to number 
> of immediate child node.
> The code technically belong to JSR-283 project. For now creating the issue 
> here
> [1] 
> https://java.net/projects/jsr-283/sources/svn/content/trunk/src/java/javax/jcr/util/TraversingItemVisitor.java?rev=967



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-3997) TraversingItemVisitor causes stackoverflowexception with breadth first traversal

2016-08-22 Thread Ankit Agarwal (JIRA) 

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

Ankit Agarwal edited comment on JCR-3997 at 8/22/16 1:00 PM:
-

[~chetanm] I have updated the pull request with test case.
cc: [~amitgupt]

thanks,


was (Author: anagarwa):
[~chetanm] I have updated the pull request with test case.

thanks,

> TraversingItemVisitor causes stackoverflowexception with breadth first 
> traversal
> 
>
> Key: JCR-3997
> URL: https://issues.apache.org/jira/browse/JCR-3997
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Reporter: Chetan Mehrotra
> Fix For: 2.13.2
>
> Attachments: OAK-4549-test.patch
>
>
> [TraversingItemVisitor|https://docs.adobe.com/docs/en/spec/jsr170/javadocs/jcr-1.0/javax/jcr/util/TraversingItemVisitor.html]
>  when used in breadth first traversal mode can lead to StackOverflowException 
> with very flat child list. This happens because it uses recursion [1] instead 
> of plain iteration which would increase the stack size proportional to number 
> of immediate child node.
> The code technically belong to JSR-283 project. For now creating the issue 
> here
> [1] 
> https://java.net/projects/jsr-283/sources/svn/content/trunk/src/java/javax/jcr/util/TraversingItemVisitor.java?rev=967



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4005) TestVFSDataStore.testDeleteRecord() fails occasionally

2016-08-22 Thread Woonsan Ko (JIRA) 

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

Woonsan Ko commented on JCR-4005:
-

Hi [~mreutegg],

I'll take a look into it asap today.

Regards,

Woonsan

> TestVFSDataStore.testDeleteRecord() fails occasionally
> --
>
> Key: JCR-4005
> URL: https://issues.apache.org/jira/browse/JCR-4005
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-vfs-ext
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The test failed on Jenkins and also fails occasionally on my machine:
> https://builds.apache.org/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-vfs-ext/2369/console



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4005) TestVFSDataStore.testDeleteRecord() fails occasionally

2016-08-22 Thread Marcel Reutegger (JIRA) 

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

Marcel Reutegger commented on JCR-4005:
---

Ignored test for now: http://svn.apache.org/r1757155

> TestVFSDataStore.testDeleteRecord() fails occasionally
> --
>
> Key: JCR-4005
> URL: https://issues.apache.org/jira/browse/JCR-4005
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-vfs-ext
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The test failed on Jenkins and also fails occasionally on my machine:
> https://builds.apache.org/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-vfs-ext/2369/console



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4005) TestVFSDataStore.testDeleteRecord() fails occasionally

2016-08-22 Thread Marcel Reutegger (JIRA) 

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

Marcel Reutegger commented on JCR-4005:
---

[~woon_san], any idea what is going wrong here?

> TestVFSDataStore.testDeleteRecord() fails occasionally
> --
>
> Key: JCR-4005
> URL: https://issues.apache.org/jira/browse/JCR-4005
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-vfs-ext
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The test failed on Jenkins and also fails occasionally on my machine:
> https://builds.apache.org/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-vfs-ext/2369/console



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCR-4005) TestVFSDataStore.testDeleteRecord() fails occasionally

2016-08-22 Thread Marcel Reutegger (JIRA) 
Marcel Reutegger created JCR-4005:
-

 Summary: TestVFSDataStore.testDeleteRecord() fails occasionally
 Key: JCR-4005
 URL: https://issues.apache.org/jira/browse/JCR-4005
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-vfs-ext
Reporter: Marcel Reutegger
Priority: Minor


The test failed on Jenkins and also fails occasionally on my machine:
https://builds.apache.org/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-vfs-ext/2369/console



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.33

2016-08-22 Thread Amit Jain 
Hi,

On Mon, Aug 22, 2016 at 2:04 PM, Dominique Jaeggi  wrote:

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

+1 Release this package as Apache Jackrabbit Oak 1.0.33

Thanks
Amit

Jackrabbit-trunk - Build # 2369 - Unstable

2016-08-22 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Jackrabbit-trunk (build #2369)

Status: Unstable

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

[jira] [Updated] (JCR-3975) Commons-VFS Datastore implementation

2016-08-22 Thread Marcel Reutegger (JIRA) 

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

Marcel Reutegger updated JCR-3975:
--
Component/s: jackrabbit-vfs-ext

> Commons-VFS Datastore implementation
> 
>
> Key: JCR-3975
> URL: https://issues.apache.org/jira/browse/JCR-3975
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-vfs-ext
>Reporter: Woonsan Ko
>Assignee: Marcel Reutegger
> Fix For: 2.13.2
>
>
> Commons-VFS DataStore may provide capability to use various backends such as 
> Local File System, WebDAV, SFTP, HDFS, etc., thus leveraging all benefits of 
> different backends like low cost, infinite, reliable, scalable storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jackrabbit 2.13.2 release plan

2016-08-22 Thread Marcel Reutegger 

Hi all,

I'd like to create a Jackrabbit 2.13.2 release, now that
JCR-3975 is applied and to get required changes like JCR-4000
into Oak.

The list of unresolved issues for 2.13.2 can be found here:
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.13.2%20AND%20project%20%3D%20JCR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

None of them looks like a blocker. I will start the release
process tomorrow if there are no objections.

Regards
 Marcel

[jira] [Resolved] (JCR-3975) Commons-VFS Datastore implementation

2016-08-22 Thread Marcel Reutegger (JIRA) 

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

Marcel Reutegger resolved JCR-3975.
---
Resolution: Fixed
  Assignee: Marcel Reutegger

Applied pull request to trunk: http://svn.apache.org/r1757129

Thanks a lot for your contribution Woonsan!

> Commons-VFS Datastore implementation
> 
>
> Key: JCR-3975
> URL: https://issues.apache.org/jira/browse/JCR-3975
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>Reporter: Woonsan Ko
>Assignee: Marcel Reutegger
> Fix For: 2.13.2
>
>
> Commons-VFS DataStore may provide capability to use various backends such as 
> Local File System, WebDAV, SFTP, HDFS, etc., thus leveraging all benefits of 
> different backends like low cost, infinite, reliable, scalable storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JCR-4004) Log exception in AbstractDataStore.getReferenceFromIdentifier()

2016-08-22 Thread Marcel Reutegger (JIRA) 

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

Marcel Reutegger resolved JCR-4004.
---
Resolution: Fixed

Applied changes suggested by Woonsan Ko in JCR-3975: 
http://svn.apache.org/r1757125

> Log exception in AbstractDataStore.getReferenceFromIdentifier()
> ---
>
> Key: JCR-4004
> URL: https://issues.apache.org/jira/browse/JCR-4004
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-data
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 2.13.2
>
>
> The method should log the exception instead as mentioned in the TODO in the 
> code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-3975) Commons-VFS Datastore implementation

2016-08-22 Thread Marcel Reutegger (JIRA) 

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

Marcel Reutegger commented on JCR-3975:
---

Thanks for the updated pull request. I will commit your changes with one minor 
change. I would like to move the changes in AbstractDataStore into a separate 
issue (JCR-4004). It's in a different module and independent of your changes.

> Commons-VFS Datastore implementation
> 
>
> Key: JCR-3975
> URL: https://issues.apache.org/jira/browse/JCR-3975
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>Reporter: Woonsan Ko
> Fix For: 2.13.2
>
>
> Commons-VFS DataStore may provide capability to use various backends such as 
> Local File System, WebDAV, SFTP, HDFS, etc., thus leveraging all benefits of 
> different backends like low cost, infinite, reliable, scalable storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCR-4004) Log exception in AbstractDataStore.getReferenceFromIdentifier()

2016-08-22 Thread Marcel Reutegger (JIRA) 
Marcel Reutegger created JCR-4004:
-

 Summary: Log exception in 
AbstractDataStore.getReferenceFromIdentifier()
 Key: JCR-4004
 URL: https://issues.apache.org/jira/browse/JCR-4004
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-data
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Priority: Minor
 Fix For: 2.13.2


The method should log the exception instead as mentioned in the TODO in the 
code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.33

2016-08-22 Thread Marcel Reutegger 

On 22/08/16 10:34, Dominique Jaeggi wrote:

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


All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.0.33

Regards
 Marcel

[VOTE] Release Apache Jackrabbit Oak 1.0.33

2016-08-22 Thread Dominique Jaeggi 
A candidate for the Jackrabbit Oak 1.0.33 release is available at:

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

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

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

The SHA1 checksum of the archive is
74a069f439a23f0f28754de7f33c0e8da74240da.

A staged Maven repository is available for review at:

https://repository.apache.org/

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

$ sh check-release.sh oak 1.0.33 74a069f439a23f0f28754de7f33c0e8da74240da

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

[ ] +1 Release this package as Apache Jackrabbit Oak 1.0.33

[ ] -1 Do not release this package because...

My vote is +1.

Thanks
dom.

Re: [VOTE] Release Apache Jackrabbit Filevault 3.1.28

2016-08-22 Thread Marcel Reutegger 

On 18/08/16 09:09, Tobias Bocanegra wrote:

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


All checks OK.

+1 Release this package as Apache Jackrabbit Filevault 3.1.28

Regards
 Marcel