[jira] [Resolved] (JCRVLT-50) Add support for "hollow" packages

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-50.

   Resolution: Fixed
Fix Version/s: 3.1.40

fixed in r1797321

> Add support for "hollow" packages
> -
>
> Key: JCRVLT-50
> URL: https://issues.apache.org/jira/browse/JCRVLT-50
> Project: Jackrabbit FileVault
>  Issue Type: New Feature
>  Components: Packaging
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 3.1.40
>
>
> when installing the customer package that is 3Gb, I noticed that installing 
> it requires about 10Gb...
> The root cause seems that it doesn't use the file directly, but instead 
> perform multiple copies before actually starting to extract it.
> 1. it copies the package from crx-quickstart/install to datastore 
> 2. from datastore if first copy it in /tmp like 
> vaultpack7793665768596308927.zip
> 3. in /tmp/ it create a second copy __vlttmpbuffer2535888623024233693.dat
> So at the end it will have used many diskspace which in the case of large 
> package is not efficient.
> It could be nice if it would use the original file (datastore or /install 
> folder) all the time.
> ---
> I think we should have 2 improvements:
> # add option for streaming install which would:
> ** create a "hollow" package, that does not store the package content in the 
> repository (basically, a 0 byte jcr:data). I think it's still good to have 
> the package node so that you see it was installed
> ** would not create a snapshot by default
> ** would not allow to uninstall
> ** would install directly from the stream, w/o need of tmp file (there might 
> be a problem with large zip's that still need a tmp file - but with java7 
> that might not be a problem anymore)
> # add option to select a file on the server disk for installation. this can 
> be done independent of the "hollow" package support above. but would allow to 
> scp the files on the server, and then install it w/o an ever-open browser 
> connection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: How can java code connect to remote jackrabbit oak standalone server and get a repository reference back?

[Chetan Mehrotra]

You should be able to use same approach as used for Jackrabbit with
Oak. The standalone example application server would listen at port
8080 and support remote access via DavEx (at `/server`)  and WebDAV
(at `/repository/default`).
Chetan Mehrotra


On Fri, Jun 2, 2017 at 12:23 AM, Austin Zhang  wrote:
> Hi,
>
> I’m learning jackrabbit oak, when trying  the standalone server example, 
> after the server starting up, from my java code I want to connect to the 
> server and get a handle(reference) of the repository back.
>
> We know jackrabbit 2 can do this kind of thing by RMI, JNDI, Webdav or some 
> other ways, but I could not find anyway that jackrabbit oak does.
>
> My question is how can our code to connect to a remote jackrabbit oak 
> standalone server and get a repository reference back, so we can do all our 
> operations on it?

How can java code connect to remote jackrabbit oak standalone server and get a repository reference back?

[Austin Zhang]

Hi,

I’m learning jackrabbit oak, when trying  the standalone server example, after 
the server starting up, from my java code I want to connect to the server and 
get a handle(reference) of the repository back.

We know jackrabbit 2 can do this kind of thing by RMI, JNDI, Webdav or some 
other ways, but I could not find anyway that jackrabbit oak does.

My question is how can our code to connect to a remote jackrabbit oak 
standalone server and get a repository reference back, so we can do all our 
operations on it? 

Release Plan Oak 1.2.26

[Amit Jain]

Hi,

I would be releasing Oak 1.2.26 on Monday (5th June). As always if you need
to put in urgently let me know.

Thanks
Amit

[jira] [Resolved] (JCRVLT-163) Avoid compressing incompressible binaries

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-163.
-
Resolution: Fixed

thanks for the patch. applied in r1797308

> Avoid compressing incompressible binaries
> -
>
> Key: JCRVLT-163
> URL: https://issues.apache.org/jira/browse/JCRVLT-163
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.0
>Reporter: Timothee Maret
> Fix For: 3.1.40
>
> Attachments: JCRVLT-163.patch
>
>
> As discussed in [0], this issue tracks allowing to specify the compression 
> level when building packages. The primary idea is to avoid compressing 
> (compression level = {{NO_COMPRESSION}})  already compressed binaries, 
> identified based on their MIME type.
> Setting the compression level is a tradeoff between the compression speed and 
> the size of the compressed artefacts.
> Different use cases likely favour maximising either of the two. 
> Therefor, it may make sense to allow configuring the compression levels per 
> use case (not globally).
> A generic way to express this configuration would be:
> * a mapping from MIME type to compression level
> * the default level (for MIME type not matching any entry in the mapping)
> [0] https://www.mail-archive.com/dev@jackrabbit.apache.org/msg37807.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (JCRVLT-163) Avoid compressing incompressible binaries

[Timothee Maret (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16033049#comment-16033049
 ] 

Timothee Maret commented on JCRVLT-163:
---

[~tripod] I have updated the patch [0] with your suggestions, fixed the code 
such that it passes the unit test, adjusted the MIN_AUTO_DETECTION_LENGTH 
according to my benchmarks and ignored the performance tests by default. The 
unit tests for all modules in the {{jackrabbit-filevault}} project seem to run 
successfully.

[0] 
https://github.com/tmaret/jackrabbit-filevault/commit/9249b633025c33b7606912ae2c39b9197cc990ad

> Avoid compressing incompressible binaries
> -
>
> Key: JCRVLT-163
> URL: https://issues.apache.org/jira/browse/JCRVLT-163
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.0
>Reporter: Timothee Maret
> Fix For: 3.1.40
>
> Attachments: JCRVLT-163.patch
>
>
> As discussed in [0], this issue tracks allowing to specify the compression 
> level when building packages. The primary idea is to avoid compressing 
> (compression level = {{NO_COMPRESSION}})  already compressed binaries, 
> identified based on their MIME type.
> Setting the compression level is a tradeoff between the compression speed and 
> the size of the compressed artefacts.
> Different use cases likely favour maximising either of the two. 
> Therefor, it may make sense to allow configuring the compression levels per 
> use case (not globally).
> A generic way to express this configuration would be:
> * a mapping from MIME type to compression level
> * the default level (for MIME type not matching any entry in the mapping)
> [0] https://www.mail-archive.com/dev@jackrabbit.apache.org/msg37807.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (JCR-4141) SecurityProviderRegistration.maybeUnregister: typo on comment

[angela (JIRA)]

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

angela updated JCR-4141:

Fix Version/s: 1.8
   1.7.1

> SecurityProviderRegistration.maybeUnregister: typo on comment
> -
>
> Key: JCR-4141
> URL: https://issues.apache.org/jira/browse/JCR-4141
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: core
>Reporter: angela
>Priority: Trivial
> Fix For: 1.7.1, 1.8
>
>
> the comment within {{SecurityProviderRegistration.maybeUnregister}} states{
> {code}
> // The preconditions are not satisfied. This may happen when a
> // dependency is unbound from the current component.
> if (preconditions.areSatisfied()) {
> log.info("Aborting: preconditions are satisfied");
> return;
> }
> {code}
> what is actually meant is that the preconditions are still satisfied and we 
> therefore have no reason to continue with the unregistration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (JCR-4141) SecurityProviderRegistration.maybeUnregister: typo on comment

[angela (JIRA)]

angela created JCR-4141:
---

 Summary: SecurityProviderRegistration.maybeUnregister: typo on 
comment
 Key: JCR-4141
 URL: https://issues.apache.org/jira/browse/JCR-4141
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: core
Reporter: angela
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Oak 1.7.1 release plan

[Davide Giannella]

Hello team,

I'm planning to cut Oak (1.7.1) on Monday 5th June.

If there are any objections please let me know. Otherwise I will
re-schedule any non-resolved issue for the next iteration.

Thanks
Davide

Oak 1.4.16 release plan

[Davide Giannella]

Hello team,

I'm planning to cut Oak on Monday 5th June.

If there are any objections please let me know. Otherwise I will
re-schedule any non-resolved issue for the next iteration.

Thanks
Davide

[jira] [Commented] (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:comment-tabpanel=16032915#comment-16032915
 ] 

Julian Reschke commented on JCR-4140:
-

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


> 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.3.15#6346)

Jackrabbit-trunk - Build # 2491 - Fixed

[Apache Jenkins Server]

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

Status: Fixed

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

[jira] [Resolved] (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 resolved JCR-4140.
-
   Resolution: Fixed
Fix Version/s: 2.15.3

> 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.3.15#6346)

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

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4140:
---

 Summary: 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






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (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:comment-tabpanel=16032872#comment-16032872
 ] 

Julian Reschke commented on JCR-4139:
-

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


> 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.3.15#6346)

[jira] [Resolved] (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 resolved JCR-4139.
-
   Resolution: Fixed
Fix Version/s: 2.15.3

> 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.3.15#6346)

[jira] [Updated] (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 updated JCR-4139:

Labels: candidate_jcr_2_10 candidate_jcr_2_12 candidate_jcr_2_14 
candidate_jcr_2_8  (was: )

> 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.3.15#6346)

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

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4139:
---

 Summary: 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
 Fix For: 2.16






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (JCR-4136) Release Jackrabbit 2.14.1

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4136.
-
Resolution: Fixed

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




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[ANNOUNCE] Apache Jackrabbit 2.14.1 released

[Julian Reschke]

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

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

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

Release Notes -- Apache Jackrabbit -- Version 2.14.1

Introduction


This is Apache Jackrabbit(TM) 2.14.1, 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.14.1 is a patch release that contains fixes and
improvements over Jackrabbit 2.14. Jackrabbit 2.14.x releases are
considered stable and targeted for production use.

Changes in Jackrabbit 2.14.1


Bug

[JCR-4100] - jackrabbit-webdav: Scope implements equals() but not 
hashCode()

[JCR-4102] - jcr2dav: change polling thread sometimes dies with NPE
[JCR-4118] - RepositoryChecker creates invalid node names
[JCR-4121] - ConcurrentModificationException in 
InternalVersionHistoryImpl.fixLegacy()

[JCR-4133] - fix javadoc problems that are errors with JDK8

Task

[JCR-4104] - cleanup how command lines for test executions are 
constructed

[JCR-4106] - fix JCR API docs link
[JCR-4107] - Upgrade to httpclient 4.5.3
[JCR-4119] - Upgrade httpcomponents/httpmime to 4.5.3
[JCR-4122] - align parent pom references with Oak
[JCR-4129] - get rid of unused org.json dependency
[JCR-4134] - update build instructions wrt Java versions


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.

[ANNOUNCE] Apache Jackrabbit 2.14.1 released

[Julian Reschke]

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

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

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

Release Notes -- Apache Jackrabbit -- Version 2.14.1

Introduction


This is Apache Jackrabbit(TM) 2.14.1, 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.14.1 is a patch release that contains fixes and
improvements over Jackrabbit 2.14. Jackrabbit 2.14.x releases are
considered stable and targeted for production use.

Changes in Jackrabbit 2.14.1


Bug

[JCR-4100] - jackrabbit-webdav: Scope implements equals() but not 
hashCode()

[JCR-4102] - jcr2dav: change polling thread sometimes dies with NPE
[JCR-4118] - RepositoryChecker creates invalid node names
[JCR-4121] - ConcurrentModificationException in 
InternalVersionHistoryImpl.fixLegacy()

[JCR-4133] - fix javadoc problems that are errors with JDK8

Task

[JCR-4104] - cleanup how command lines for test executions are 
constructed

[JCR-4106] - fix JCR API docs link
[JCR-4107] - Upgrade to httpclient 4.5.3
[JCR-4119] - Upgrade httpcomponents/httpmime to 4.5.3
[JCR-4122] - align parent pom references with Oak
[JCR-4129] - get rid of unused org.json dependency
[JCR-4134] - update build instructions wrt Java versions


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] [Commented] (JCRVLT-163) Avoid compressing incompressible binaries

[Timothee Maret (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032718#comment-16032718
 ] 

Timothee Maret commented on JCRVLT-163:
---

Thanks [~tripod] for looking at this and for the suggestions. I'll update the 
branch https://github.com/tmaret/jackrabbit-filevault/tree/JCRVLT-163

bq. optimize your test output stream, by also overriding the other write() 
methods:
+1

bq. your tests take a very long time 

IIRC {{CompressionUtilTest}} is a unit test that should run quickly and 
{{TestCompressionExport}} was meant as a performance integration test such that 
we could get tweak the offsets (e.g. {{MIN_AUTO_DETECTION_LENGTH}}). As is, I 
think the performance integration test should not run as part of the regular 
build because I. it takes too long to run and II. some of the assertions are 
likely to fail from time to time (test heavily dependent on timing).

Since the test is likely to fail from time to time, I suggest to ignore the 
{{TestCompressionExport}} by default.

bq. and seem to fail when there is nothing to optimize.

Ok, I'll look at it again.

> Avoid compressing incompressible binaries
> -
>
> Key: JCRVLT-163
> URL: https://issues.apache.org/jira/browse/JCRVLT-163
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.0
>Reporter: Timothee Maret
> Fix For: 3.1.40
>
> Attachments: JCRVLT-163.patch
>
>
> As discussed in [0], this issue tracks allowing to specify the compression 
> level when building packages. The primary idea is to avoid compressing 
> (compression level = {{NO_COMPRESSION}})  already compressed binaries, 
> identified based on their MIME type.
> Setting the compression level is a tradeoff between the compression speed and 
> the size of the compressed artefacts.
> Different use cases likely favour maximising either of the two. 
> Therefor, it may make sense to allow configuring the compression levels per 
> use case (not globally).
> A generic way to express this configuration would be:
> * a mapping from MIME type to compression level
> * the default level (for MIME type not matching any entry in the mapping)
> [0] https://www.mail-archive.com/dev@jackrabbit.apache.org/msg37807.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (JCRVLT-163) Avoid compressing incompressible binaries

[Tobias Bocanegra (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032688#comment-16032688
 ] 

Tobias Bocanegra commented on JCRVLT-163:
-

optimize your test output stream, by also overriding the other write() methods:

{noformat}
public class WriteCountOutputStream extends OutputStream {

long size = 0;

@Override
public void write(int b) throws IOException {
size++;
}

@Override
public void write(byte[] b) throws IOException {
size+= b.length;
}

@Override
public void write(byte[] b, int off, int len) throws IOException {
size+= len;
}

public long size() {
return size;
}
}
{noformat}

> Avoid compressing incompressible binaries
> -
>
> Key: JCRVLT-163
> URL: https://issues.apache.org/jira/browse/JCRVLT-163
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.0
>Reporter: Timothee Maret
> Fix For: 3.1.40
>
> Attachments: JCRVLT-163.patch
>
>
> As discussed in [0], this issue tracks allowing to specify the compression 
> level when building packages. The primary idea is to avoid compressing 
> (compression level = {{NO_COMPRESSION}})  already compressed binaries, 
> identified based on their MIME type.
> Setting the compression level is a tradeoff between the compression speed and 
> the size of the compressed artefacts.
> Different use cases likely favour maximising either of the two. 
> Therefor, it may make sense to allow configuring the compression levels per 
> use case (not globally).
> A generic way to express this configuration would be:
> * a mapping from MIME type to compression level
> * the default level (for MIME type not matching any entry in the mapping)
> [0] https://www.mail-archive.com/dev@jackrabbit.apache.org/msg37807.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (JCRVLT-163) Avoid compressing incompressible binaries

[Tobias Bocanegra (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032684#comment-16032684
 ] 

Tobias Bocanegra commented on JCRVLT-163:
-

[~marett] thanks for the patch. I quickly checked it and looks good to me, 
except that your tests take a very long time and seem to fail when there is 
nothing to optimize.
also another test fails:

because of this change:

{noformat}
jOut.setLevel(NO_COMPRESSION); // The entry to be written is assumed to 
not be compressible
{noformat}



{noformat}
---
Test set: org.apache.jackrabbit.vault.packaging.integration.TestPackageInstall
---
Tests run: 27, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 3.018 sec <<< 
FAILURE!
testRewrap(org.apache.jackrabbit.vault.packaging.integration.TestPackageInstall)
  Time elapsed: 0.084 sec  <<< ERROR!
java.util.zip.ZipException: invalid entry compressed size (expected 2 but got 5 
bytes)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267)
at 
org.apache.jackrabbit.vault.fs.io.JarExporter.write(JarExporter.java:219)
at 
org.apache.jackrabbit.vault.packaging.impl.PackageManagerImpl.rewrap(PackageManagerImpl.java:221)
at 
org.apache.jackrabbit.vault.packaging.impl.PackageManagerImpl.rewrap(PackageManagerImpl.java:165)
at 
org.apache.jackrabbit.vault.packaging.impl.JcrPackageManagerImpl.rewrap(JcrPackageManagerImpl.java:671)
at 
org.apache.jackrabbit.vault.packaging.integration.TestPackageInstall.testRewrap(TestPackageInstall.java:77)

{noformat}

> Avoid compressing incompressible binaries
> -
>
> Key: JCRVLT-163
> URL: https://issues.apache.org/jira/browse/JCRVLT-163
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.0
>Reporter: Timothee Maret
> Fix For: 3.1.40
>
> Attachments: JCRVLT-163.patch
>
>
> As discussed in [0], this issue tracks allowing to specify the compression 
> level when building packages. The primary idea is to avoid compressing 
> (compression level = {{NO_COMPRESSION}})  already compressed binaries, 
> identified based on their MIME type.
> Setting the compression level is a tradeoff between the compression speed and 
> the size of the compressed artefacts.
> Different use cases likely favour maximising either of the two. 
> Therefor, it may make sense to allow configuring the compression levels per 
> use case (not globally).
> A generic way to express this configuration would be:
> * a mapping from MIME type to compression level
> * the default level (for MIME type not matching any entry in the mapping)
> [0] https://www.mail-archive.com/dev@jackrabbit.apache.org/msg37807.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[RESULT] [VOTE] Release Apache Jackrabbit 2.14.1

[Julian Reschke]

Hi there,

the vote passes as follows:

+1 Chetan Mehrotra 
+1 Claus Köll 
+1 Julian Reschke 
+1 Tomek Rękawek 

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

Best regards, Julian

Re: Backports OAK-5827 & JCR-4115?

[Julian Reschke]

On 2017-06-01 11:13, Amit Jain wrote:

Ok. Maybe this time we create a 2.14.2 release in 4-5 weeks time?


OK.

(You may have to remind me though :-)

Re: Backports OAK-5827 & JCR-4115?

[Amit Jain]

Ok. Maybe this time we create a 2.14.2 release in 4-5 weeks time?

On Thu, Jun 1, 2017 at 2:37 PM, Julian Reschke 
wrote:

> On 2017-06-01 10:53, Amit Jain wrote:
>
>> On Thu, Jun 1, 2017 at 2:12 PM, Julian Reschke 
>> wrote:
>>
>> Now when do we need that in a 2.14 release?
>>>
>>>
>> I think we can follow the normal schedule (monthly?)
>>
>> Thanks
>> Amit
>>
>
> I currently do one Jackrabbit release per month (unless something is
> urgent) - but these apply to trunk and all branches. So another 2.14
> release wouldn't happen for another few months, unless we accelerate it...
>
> Best regards, Julian
>
>

Re: Backports OAK-5827 & JCR-4115?

[Julian Reschke]

On 2017-06-01 10:53, Amit Jain wrote:

On Thu, Jun 1, 2017 at 2:12 PM, Julian Reschke 
wrote:


Now when do we need that in a 2.14 release?



I think we can follow the normal schedule (monthly?)

Thanks
Amit


I currently do one Jackrabbit release per month (unless something is 
urgent) - but these apply to trunk and all branches. So another 2.14 
release wouldn't happen for another few months, unless we accelerate it...


Best regards, Julian

Re: Backports OAK-5827 & JCR-4115?

[Amit Jain]

On Thu, Jun 1, 2017 at 2:12 PM, Julian Reschke 
wrote:

> Now when do we need that in a 2.14 release?
>

I think we can follow the normal schedule (monthly?)

Thanks
Amit

Re: Backports OAK-5827 & JCR-4115?

[Julian Reschke]

On 2017-06-01 08:32, Amit Jain wrote:

On Wed, May 31, 2017 at 4:36 PM, Julian Reschke 
wrote:


I can do the backport if you want



Sure.


Done (JCR-4115).

Now when do we need that in a 2.14 release?

Best regards, Julian

Intent to backport OAK-5921

[Alex Parvulescu]

Hi,

OAK-5921 removes an unnecessary OSGi import on segment-tar. It's a trivial
change that will not affect any existing setups in any way.

thanks,
alex

[jira] [Updated] (JCR-4138) Not able to upload a large file (2 GB) via Jackrabbit to an Oracle Database

[Mateusz Kluska (JIRA)]

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

Mateusz Kluska updated JCR-4138:

Description: 
I have configured Jackrabbit datastore to Oracle database. I use JCR API and 
when I upload file greater or equal 2GB I get following error(attachment 
log.txt).

The problem is in class 'org.apache.jackrabbit.core.util.db.ConnectionHelper' 
and method 'execute' where is called method setBinaryStream. There stream size 
is cast to int. That caused a problem when stream size is bigger than max int 
(2GB or grater). You should use 
[this|https://commons.apache.org/proper/commons-dbcp/apidocs/org/apache/commons/dbcp2/DelegatingPreparedStatement.html#setBinaryStream-int-java.io.InputStream-long-]
 method there instead of casting. Oracle JDBC also handles long binary stream 
size.


  was:
I have configured jackrabbit datastore to Oracle database. I use JCR Api and 
when I upload file greater or Equal 2GB I get following error(attachment 
log.txt).

The problem is in class 'org.apache.jackrabbit.core.util.db.ConnectionHelper' 
and method 'execute' where is called method setBinaryStream. There stream size 
is cast to int. That caused a problem when stream size is bigger than max int 
(2GB or grater). You should use 
[this|https://commons.apache.org/proper/commons-dbcp/apidocs/org/apache/commons/dbcp2/DelegatingPreparedStatement.html#setBinaryStream-int-java.io.InputStream-long-]
 method there instead of casting. Ojdbc also handle long binary stream size.



> Not able to upload a large file (2 GB) via Jackrabbit to an Oracle Database
> ---
>
> Key: JCR-4138
> URL: https://issues.apache.org/jira/browse/JCR-4138
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core, jackrabbit-data
>Affects Versions: 2.14.0
>Reporter: Mateusz Kluska
> Attachments: log.txt
>
>
> I have configured Jackrabbit datastore to Oracle database. I use JCR API and 
> when I upload file greater or equal 2GB I get following error(attachment 
> log.txt).
> The problem is in class 'org.apache.jackrabbit.core.util.db.ConnectionHelper' 
> and method 'execute' where is called method setBinaryStream. There stream 
> size is cast to int. That caused a problem when stream size is bigger than 
> max int (2GB or grater). You should use 
> [this|https://commons.apache.org/proper/commons-dbcp/apidocs/org/apache/commons/dbcp2/DelegatingPreparedStatement.html#setBinaryStream-int-java.io.InputStream-long-]
>  method there instead of casting. Oracle JDBC also handles long binary stream 
> size.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (JCR-4138) Not able to upload a large file (2 GB) via Jackrabbit to an Oracle Database

[Mateusz Kluska (JIRA)]

Mateusz Kluska created JCR-4138:
---

 Summary: Not able to upload a large file (2 GB) via Jackrabbit to 
an Oracle Database
 Key: JCR-4138
 URL: https://issues.apache.org/jira/browse/JCR-4138
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, jackrabbit-data
Affects Versions: 2.14.0
Reporter: Mateusz Kluska
 Attachments: log.txt

I have configured jackrabbit datastore to Oracle database. I use JCR Api and 
when I upload file greater or Equal 2GB I get following error(attachment 
log.txt).

The problem is in class 'org.apache.jackrabbit.core.util.db.ConnectionHelper' 
and method 'execute' where is called method setBinaryStream. There stream size 
is cast to int. That caused a problem when stream size is bigger than max int 
(2GB or grater). You should use 
[this|https://commons.apache.org/proper/commons-dbcp/apidocs/org/apache/commons/dbcp2/DelegatingPreparedStatement.html#setBinaryStream-int-java.io.InputStream-long-]
 method there instead of casting. Ojdbc also handle long binary stream size.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4115:

Fix Version/s: 2.14.2

> Don't use SHA-1 for new DataStore binaries (Jackrabbit)
> ---
>
> Key: JCR-4115
> URL: https://issues.apache.org/jira/browse/JCR-4115
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Thomas Mueller
>Assignee: Amit Jain
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.16, 2.15.1, 2.14.2
>
> Attachments: JCR-4115b.patch, JCR-4115c.patch, JCR-4115.patch
>
>
> A collision for SHA-1 has been published. We still use SHA-1 for the 
> FileDataStore, and I believe the S3 DataStore right now. Given there is a 
> collision, we should switch to a stronger algorithm, for example SHA-256, for 
> new binaries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4115:

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

> Don't use SHA-1 for new DataStore binaries (Jackrabbit)
> ---
>
> Key: JCR-4115
> URL: https://issues.apache.org/jira/browse/JCR-4115
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Thomas Mueller
>Assignee: Amit Jain
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.16, 2.15.1, 2.14.2
>
> Attachments: JCR-4115b.patch, JCR-4115c.patch, JCR-4115.patch
>
>
> A collision for SHA-1 has been published. We still use SHA-1 for the 
> FileDataStore, and I believe the S3 DataStore right now. Given there is a 
> collision, we should switch to a stronger algorithm, for example SHA-256, for 
> new binaries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4115:
-

trunk: [r1785225|http://svn.apache.org/r1785225]
2.14: [r1797148|http://svn.apache.org/r1797148]


> Don't use SHA-1 for new DataStore binaries (Jackrabbit)
> ---
>
> Key: JCR-4115
> URL: https://issues.apache.org/jira/browse/JCR-4115
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Thomas Mueller
>Assignee: Amit Jain
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.16, 2.15.1, 2.14.2
>
> Attachments: JCR-4115b.patch, JCR-4115c.patch, JCR-4115.patch
>
>
> A collision for SHA-1 has been published. We still use SHA-1 for the 
> FileDataStore, and I believe the S3 DataStore right now. Given there is a 
> collision, we should switch to a stronger algorithm, for example SHA-256, for 
> new binaries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (JCRVLT-180) implement filesystem based persistence layer

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-180:
---

 Summary: implement filesystem based persistence layer
 Key: JCRVLT-180
 URL: https://issues.apache.org/jira/browse/JCRVLT-180
 Project: Jackrabbit FileVault
  Issue Type: Sub-task
Reporter: Tobias Bocanegra






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (JCRVLT-178) create persistence layer api

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-178:
---

 Summary: create persistence layer api
 Key: JCRVLT-178
 URL: https://issues.apache.org/jira/browse/JCRVLT-178
 Project: Jackrabbit FileVault
  Issue Type: Sub-task
Reporter: Tobias Bocanegra






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (JCRVLT-179) implement jcr based persistence layer

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-179:
---

 Summary: implement jcr based persistence layer
 Key: JCRVLT-179
 URL: https://issues.apache.org/jira/browse/JCRVLT-179
 Project: Jackrabbit FileVault
  Issue Type: Sub-task
Reporter: Tobias Bocanegra






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Backports OAK-5827 & JCR-4115?

[Amit Jain]

On Wed, May 31, 2017 at 4:36 PM, Julian Reschke 
wrote:

> I can do the backport if you want


Sure.