[jira] [Comment Edited] (JCR-4459) Basic Authentication for HTTPS URIs does not work

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on JCR-4459 at 7/18/19 5:58 AM:
--

trunk: [r1863196|http://svn.apache.org/r1863196]
2.18: [r1863249|http://svn.apache.org/r1863249]



was (Author: reschke):
trunk: [r1863196|http://svn.apache.org/r1863196]

> Basic Authentication for HTTPS URIs does not work
> -
>
> Key: JCR-4459
> URL: https://issues.apache.org/jira/browse/JCR-4459
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
>
> ...because the auth cache is keyed by httpHost, and in the constructor, we 
> leave out the URI scheme.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (JCR-4459) Basic Authentication for HTTPS URIs does not work

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4459:

Labels: candidate_jcr_2_16  (was: candidate_jcr_2_18)

> Basic Authentication for HTTPS URIs does not work
> -
>
> Key: JCR-4459
> URL: https://issues.apache.org/jira/browse/JCR-4459
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
>
> ...because the auth cache is keyed by httpHost, and in the constructor, we 
> leave out the URI scheme.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (JCR-4459) Basic Authentication for HTTPS URIs does not work

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4459:

Fix Version/s: 2.18.3

> Basic Authentication for HTTPS URIs does not work
> -
>
> Key: JCR-4459
> URL: https://issues.apache.org/jira/browse/JCR-4459
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.4, 2.18.3
>
>
> ...because the auth cache is keyed by httpHost, and in the constructor, we 
> leave out the URI scheme.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Assigned] (JCRVLT-341) https doesn't work anymore

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra reassigned JCRVLT-341:
---

 Assignee: Tobias Bocanegra
Fix Version/s: 3.2.10

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.2.10
>
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (JCRVLT-339) Add FSPackageRegistry support for hollow packages

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-339:

   Resolution: Fixed
Fix Version/s: 3.2.10
   Status: Resolved  (was: Patch Available)

fixed in r1863240

> Add FSPackageRegistry support for hollow packages
> -
>
> Key: JCRVLT-339
> URL: https://issues.apache.org/jira/browse/JCRVLT-339
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Krystian Nowak
>Priority: Major
> Fix For: 3.2.10
>
> Attachments: JCRVLT-339.patch, test-package.zip
>
>
> The logic in 
> [FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
>  may be improved to handle truncated files proactively before 
> [ZipVaultPackage is instantiated in 
> FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
>  while trying to open it to create _VaultPackage_ in [getPackage 
> method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
> This kind of truncation is a mechanism in container based setups to 
> effectively reduce disk usage without functional impact.
> As [getPackage in 
> RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
>  is declared as not returning null (_@Nonnull_ annotation), but throwing 
> _IOException_ - this exceptional situation of truncation in filed-based case 
> might be signalled this way and handled properly by callers aware of the 
> truncation mechanism.
> Currently the exception (in the case of file truncation) is thrown multiple 
> levels lower when accessing _java.util.zip.ZipFile_ with verbose and 
> unconditional logging on multiple levels as the one given below:
> {noformat}
> 12.07.2019 15:06:48.730 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while 
> loading package /foo/bar/baz.zip.
> 12.07.2019 15:06:48.732 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud 
> not open file /foo/bar/baz.zip as ZipVaultPackage.
>  java.util.zip.ZipException: zip file is empty
>   at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
>   at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
>   at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
>   at java.util.zip.ZipFile$Source.(ZipFile.java:1274)
>   at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
>   at java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
>   at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
>   at java.util.zip.ZipFile.(ZipFile.java:247)
>   at java.util.zip.ZipFile.(ZipFile.java:177)
>   at java.util.jar.JarFile.(JarFile.java:346)
>   at java.util.jar.JarFile.(JarFile.java:317)
>   at java.util.jar.JarFile.(JarFile.java:283)
>   at 
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103) 
> [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:69)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:61)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
>  [org.apache.jackrabbit.vault:3.2.8]
> (...)
> {noformat}
> Instead a check for underlying file existence and size might be useful here 
> and in the case of truncated file a new implementation of 
> [VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
>  for hollow packages might be returned.
> (see also [^JCRVLT-339.patch] or this PR: 
> [https://github.com/apache/jackrabbit-filevault/pull/50])
> Similar approach connected with underlying VLT package file truncation in 
> container based setups can be find in SLING-8105 and its corresponding 
> change: 
> 

[jira] [Commented] (JCRVLT-339) Add FSPackageRegistry support for hollow packages

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-339:
-

[~krystian], [~dsuess] no need to attach a patch to this issue. we use the 
github PR to merge it into the repository anyways...

> Add FSPackageRegistry support for hollow packages
> -
>
> Key: JCRVLT-339
> URL: https://issues.apache.org/jira/browse/JCRVLT-339
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Krystian Nowak
>Priority: Major
> Attachments: JCRVLT-339.patch, test-package.zip
>
>
> The logic in 
> [FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
>  may be improved to handle truncated files proactively before 
> [ZipVaultPackage is instantiated in 
> FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
>  while trying to open it to create _VaultPackage_ in [getPackage 
> method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
> This kind of truncation is a mechanism in container based setups to 
> effectively reduce disk usage without functional impact.
> As [getPackage in 
> RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
>  is declared as not returning null (_@Nonnull_ annotation), but throwing 
> _IOException_ - this exceptional situation of truncation in filed-based case 
> might be signalled this way and handled properly by callers aware of the 
> truncation mechanism.
> Currently the exception (in the case of file truncation) is thrown multiple 
> levels lower when accessing _java.util.zip.ZipFile_ with verbose and 
> unconditional logging on multiple levels as the one given below:
> {noformat}
> 12.07.2019 15:06:48.730 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while 
> loading package /foo/bar/baz.zip.
> 12.07.2019 15:06:48.732 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud 
> not open file /foo/bar/baz.zip as ZipVaultPackage.
>  java.util.zip.ZipException: zip file is empty
>   at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
>   at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
>   at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
>   at java.util.zip.ZipFile$Source.(ZipFile.java:1274)
>   at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
>   at java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
>   at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
>   at java.util.zip.ZipFile.(ZipFile.java:247)
>   at java.util.zip.ZipFile.(ZipFile.java:177)
>   at java.util.jar.JarFile.(JarFile.java:346)
>   at java.util.jar.JarFile.(JarFile.java:317)
>   at java.util.jar.JarFile.(JarFile.java:283)
>   at 
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103) 
> [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:69)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:61)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
>  [org.apache.jackrabbit.vault:3.2.8]
> (...)
> {noformat}
> Instead a check for underlying file existence and size might be useful here 
> and in the case of truncated file a new implementation of 
> [VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
>  for hollow packages might be returned.
> (see also [^JCRVLT-339.patch] or this PR: 
> [https://github.com/apache/jackrabbit-filevault/pull/50])
> Similar approach connected with underlying VLT package file truncation in 
> container based setups can be find in SLING-8105 and its corresponding 
> change: 
> 

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-341:
-

Once jackrabbit 2.18.4 is released, I can include it in the next filevault 
release, 3.2.10.

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Backport OAK-7998 to 1.10.3

[Matt Ryan]

Hi,

I propose to backport the fix for OAK-7998 to 1.10.3.

The issue in OAK-7998 is that it is possible to obtain a direct download
URI for a binary that doesn't exist in blob storage.  While not usually
possible, this situation can arise if the binary in question was added via
addRecord() and then a download URI is immediately requested, if the binary
is in cache and is not yet uploaded to cloud storage.  In such a case the
binary is "in the repo" but we can't create a valid download URI for it
until it is actually in cloud storage.

The fix is implemented for 1.16.  It is a low-risk change - a couple of
unit test changes and an additional check to see whether the blob ID exists
in both the S3 and Azure backend implementations.


-MR

BUILD FAILURE: Jackrabbit Oak - Build # 2286 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #2286)

Status: Failure

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/2286/ to 
view the results.

Changes:
No changes
 

Test results:
No tests ran.<>

[jira] [Assigned] (JCRVLT-340) Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190

[angela (JIRA)]

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

angela reassigned JCRVLT-340:
-

Assignee: angela

> Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190 
> ---
>
> Key: JCRVLT-340
> URL: https://issues.apache.org/jira/browse/JCRVLT-340
> Project: Jackrabbit FileVault
>  Issue Type: New Feature
>  Components: vlt
>Reporter: angela
>Assignee: angela
>Priority: Major
>
> Request to adjust {{JackrabbitACLImporter}} and {{JcrACLManagement}} to 
> handle the policies defined by the optional authorization model provided by 
> OAK-8190.
>  
> I will try to provide a patch and tests.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4458:
-

[~woon_san] - see JCR-4460; I *think* I can now reproduce this type of problem 
with the regular integration tests...

> When JcrRemotingServlet deployed on non-root context, AclResource Webdav 
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is 
> configured in a non-root web application, the contextPath of which is "/cms" 
> for example with the servletPath, "/server", then 
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on 
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}} 
> using a repository which can be created like the following for JCR over 
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource 
> Webdav request first on the specific resource path, but 
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
>  ReportInfo)}} does not remove the contextPath, "/cms" for example, when 
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}}, 
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String, 
> boolean)}} seems to remove the contextPath properly.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4460:
-

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

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.4
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4460:

Labels: candidate_jcr_2_18  (was: )

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.4
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4460.
-
   Resolution: Fixed
Fix Version/s: 2.19.4

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.20, 2.19.4
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4460:

Description: 
Add a system property that selects a servlet context path for testing.

To run tests with non-root path:
{noformat}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
{noformat}

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.20
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4460:
---

 Summary: allow to run remoted conformance tests with a custom 
servlet context path
 Key: JCR-4460
 URL: https://issues.apache.org/jira/browse/JCR-4460
 Project: Jackrabbit Content Repository
  Issue Type: Task
  Components: jackrabbit-jcr2dav
Reporter: Julian Reschke
Assignee: Julian Reschke
 Fix For: 2.20






--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCR-4459) Basic Authentication for HTTPS URIs does not work

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4459:
-

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

> Basic Authentication for HTTPS URIs does not work
> -
>
> Key: JCR-4459
> URL: https://issues.apache.org/jira/browse/JCR-4459
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.4
>
>
> ...because the auth cache is keyed by httpHost, and in the constructor, we 
> leave out the URI scheme.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (JCR-4459) Basic Authentication for HTTPS URIs does not work

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4459.
-
   Resolution: Fixed
Fix Version/s: 2.19.4
   2.20

> Basic Authentication for HTTPS URIs does not work
> -
>
> Key: JCR-4459
> URL: https://issues.apache.org/jira/browse/JCR-4459
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.4
>
>
> ...because the auth cache is keyed by httpHost, and in the constructor, we 
> leave out the URI scheme.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[RESULT][VOTE] Release Apache Jackrabbit Oak 1.4.25

[Davide Giannella]

Hello Team,

the vote fails as follows:

+1 Davide Giannella
+1 Tommaso Teofili
-1 Marcel Reutegger (wrong release notes)

Given the feedbacks and the wrong release notes this release is going to
be cancelled and will be taken on later on.

-- Davide

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[WalterSteiner (JIRA)]

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

WalterSteiner commented on JCRVLT-341:
--

[~tripod]

Hi Tobias

can you build then the new org.apache.jackrabbit.vault.rcp-3.2.?.jar, after 
Julian has released the fix?

Thanks in advance.

Regards

Walter

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCRVLT-341:
---

ok, I opened . Please give 
2.19.4-SNAPSHOT a try once I have closed the issue.

[~tripod] - is a stable release of 2.18 sufficient?

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (JCR-4459) Basic Authentication for HTTPS URIs does not work

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4459:
---

 Summary: Basic Authentication for HTTPS URIs does not work
 Key: JCR-4459
 URL: https://issues.apache.org/jira/browse/JCR-4459
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-spi2dav
Reporter: Julian Reschke
Assignee: Julian Reschke


...because the auth cache is keyed by httpHost, and in the constructor, we 
leave out the URI scheme.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (JCR-4459) Basic Authentication for HTTPS URIs does not work

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4459:

Labels: candidate_jcr_2_18  (was: )

> Basic Authentication for HTTPS URIs does not work
> -
>
> Key: JCR-4459
> URL: https://issues.apache.org/jira/browse/JCR-4459
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_18
>
> ...because the auth cache is keyed by httpHost, and in the constructor, we 
> leave out the URI scheme.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[WalterSteiner (JIRA)]

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

WalterSteiner commented on JCRVLT-341:
--

[~reschke]

Hi Julian

In the jar there is the class 
"org.apache.jackrabbit.spi2dav.RepositoryServiceImpl" and on line 231 in this 
class, a HttpHost is instanciated. If the schema is not a parameter of the 
constructor, the constructor assumes "http". So the login fails for this url 
"*http*://@host:port". The login-address should be "*https*://@host:port".
{code:java}
try {
 URI repositoryUri = computeRepositoryUri(uri);
 httpHost = new HttpHost(repositoryUri.getHost(), repositoryUri.getPort()*, 
repositoryUri.getScheme()*);

 nsCache = new NamespaceCache();
 uriResolver = new URIResolverImpl(repositoryUri, this, 
DomUtil.createDocument());
 NamePathResolver resolver = new NamePathResolverImpl(nsCache);
 valueFactory = new ValueFactoryQImpl(qValueFactory, resolver);

} catch (URISyntaxException e) {
 throw new RepositoryException(e);
} catch (ParserConfigurationException e) {
 throw new RepositoryException(e);
}{code}
I just added "repositoryUri.getScheme()" on line 231. The original line looked 
like this

httpHost = new HttpHost(repositoryUri.getHost(), repositoryUri.getPort());

The Scheme parameter forces the HttpHost constructor to set the scheme to 
"https" or "http" depending on the value of the parameter. If you use the 
constructor without the scheme parameter, the HttpHost constructor will set the 
scheme to the default value "http".

I hope I could clarify my fix.

Regards

Walter

 

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Comment Edited] (JCRVLT-339) Add FSPackageRegistry support for hollow packages

[Krystian Nowak (JIRA)]

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

Krystian Nowak edited comment on JCRVLT-339 at 7/17/19 7:48 AM:


[~dsuess]: Didn't know how to put binaries to patch - shall I attach them to 
this JIRA issue, or is pointing to the PR 
[https://github.com/apache/jackrabbit-filevault/pull/50/files] (as [~tripod] 
mentioned) enough?

Edit: OK, I've uploaded just one of them (it's a copy of some already 
pre-existing one already for some other tests), the other cannot be uploaded to 
JIRA, as it doesn't seem to allow to upload 0-byte files...


was (Author: krystian):
[~dsuess]: Didn't know how to put binaries to patch - shall I attach them to 
this JIRA issue, or is pointing to the PR 
[https://github.com/apache/jackrabbit-filevault/pull/50/files] (as [~tripod] 
mentioned) enough?

> Add FSPackageRegistry support for hollow packages
> -
>
> Key: JCRVLT-339
> URL: https://issues.apache.org/jira/browse/JCRVLT-339
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Krystian Nowak
>Priority: Major
> Attachments: JCRVLT-339.patch, test-package.zip
>
>
> The logic in 
> [FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
>  may be improved to handle truncated files proactively before 
> [ZipVaultPackage is instantiated in 
> FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
>  while trying to open it to create _VaultPackage_ in [getPackage 
> method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
> This kind of truncation is a mechanism in container based setups to 
> effectively reduce disk usage without functional impact.
> As [getPackage in 
> RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
>  is declared as not returning null (_@Nonnull_ annotation), but throwing 
> _IOException_ - this exceptional situation of truncation in filed-based case 
> might be signalled this way and handled properly by callers aware of the 
> truncation mechanism.
> Currently the exception (in the case of file truncation) is thrown multiple 
> levels lower when accessing _java.util.zip.ZipFile_ with verbose and 
> unconditional logging on multiple levels as the one given below:
> {noformat}
> 12.07.2019 15:06:48.730 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while 
> loading package /foo/bar/baz.zip.
> 12.07.2019 15:06:48.732 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud 
> not open file /foo/bar/baz.zip as ZipVaultPackage.
>  java.util.zip.ZipException: zip file is empty
>   at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
>   at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
>   at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
>   at java.util.zip.ZipFile$Source.(ZipFile.java:1274)
>   at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
>   at java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
>   at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
>   at java.util.zip.ZipFile.(ZipFile.java:247)
>   at java.util.zip.ZipFile.(ZipFile.java:177)
>   at java.util.jar.JarFile.(JarFile.java:346)
>   at java.util.jar.JarFile.(JarFile.java:317)
>   at java.util.jar.JarFile.(JarFile.java:283)
>   at 
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103) 
> [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:69)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:61)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
>  [org.apache.jackrabbit.vault:3.2.8]
> (...)
> {noformat}
> Instead a check for underlying file existence and size might be 

[jira] [Updated] (JCRVLT-339) Add FSPackageRegistry support for hollow packages

[Krystian Nowak (JIRA)]

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

Krystian Nowak updated JCRVLT-339:
--
Attachment: test-package.zip

> Add FSPackageRegistry support for hollow packages
> -
>
> Key: JCRVLT-339
> URL: https://issues.apache.org/jira/browse/JCRVLT-339
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Krystian Nowak
>Priority: Major
> Attachments: JCRVLT-339.patch, test-package.zip
>
>
> The logic in 
> [FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
>  may be improved to handle truncated files proactively before 
> [ZipVaultPackage is instantiated in 
> FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
>  while trying to open it to create _VaultPackage_ in [getPackage 
> method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
> This kind of truncation is a mechanism in container based setups to 
> effectively reduce disk usage without functional impact.
> As [getPackage in 
> RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
>  is declared as not returning null (_@Nonnull_ annotation), but throwing 
> _IOException_ - this exceptional situation of truncation in filed-based case 
> might be signalled this way and handled properly by callers aware of the 
> truncation mechanism.
> Currently the exception (in the case of file truncation) is thrown multiple 
> levels lower when accessing _java.util.zip.ZipFile_ with verbose and 
> unconditional logging on multiple levels as the one given below:
> {noformat}
> 12.07.2019 15:06:48.730 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while 
> loading package /foo/bar/baz.zip.
> 12.07.2019 15:06:48.732 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud 
> not open file /foo/bar/baz.zip as ZipVaultPackage.
>  java.util.zip.ZipException: zip file is empty
>   at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
>   at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
>   at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
>   at java.util.zip.ZipFile$Source.(ZipFile.java:1274)
>   at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
>   at java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
>   at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
>   at java.util.zip.ZipFile.(ZipFile.java:247)
>   at java.util.zip.ZipFile.(ZipFile.java:177)
>   at java.util.jar.JarFile.(JarFile.java:346)
>   at java.util.jar.JarFile.(JarFile.java:317)
>   at java.util.jar.JarFile.(JarFile.java:283)
>   at 
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103) 
> [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:69)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:61)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
>  [org.apache.jackrabbit.vault:3.2.8]
> (...)
> {noformat}
> Instead a check for underlying file existence and size might be useful here 
> and in the case of truncated file a new implementation of 
> [VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
>  for hollow packages might be returned.
> (see also [^JCRVLT-339.patch] or this PR: 
> [https://github.com/apache/jackrabbit-filevault/pull/50])
> Similar approach connected with underlying VLT package file truncation in 
> container based setups can be find in SLING-8105 and its corresponding 
> change: 
> [https://github.com/apache/sling-org-apache-sling-feature-extension-content/commit/9eecc6d2137c8cafa70edcfd3faa839ed4412f4e]



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-339) Add FSPackageRegistry support for hollow packages

[Krystian Nowak (JIRA)]

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

Krystian Nowak commented on JCRVLT-339:
---

[~dsuess]: Didn't know how to put binaries to patch - shall I attach them to 
this JIRA issue, or is pointing to the PR 
[https://github.com/apache/jackrabbit-filevault/pull/50/files] (as [~tripod] 
mentioned) is enough?

> Add FSPackageRegistry support for hollow packages
> -
>
> Key: JCRVLT-339
> URL: https://issues.apache.org/jira/browse/JCRVLT-339
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Krystian Nowak
>Priority: Major
> Attachments: JCRVLT-339.patch
>
>
> The logic in 
> [FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
>  may be improved to handle truncated files proactively before 
> [ZipVaultPackage is instantiated in 
> FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
>  while trying to open it to create _VaultPackage_ in [getPackage 
> method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
> This kind of truncation is a mechanism in container based setups to 
> effectively reduce disk usage without functional impact.
> As [getPackage in 
> RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
>  is declared as not returning null (_@Nonnull_ annotation), but throwing 
> _IOException_ - this exceptional situation of truncation in filed-based case 
> might be signalled this way and handled properly by callers aware of the 
> truncation mechanism.
> Currently the exception (in the case of file truncation) is thrown multiple 
> levels lower when accessing _java.util.zip.ZipFile_ with verbose and 
> unconditional logging on multiple levels as the one given below:
> {noformat}
> 12.07.2019 15:06:48.730 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while 
> loading package /foo/bar/baz.zip.
> 12.07.2019 15:06:48.732 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud 
> not open file /foo/bar/baz.zip as ZipVaultPackage.
>  java.util.zip.ZipException: zip file is empty
>   at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
>   at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
>   at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
>   at java.util.zip.ZipFile$Source.(ZipFile.java:1274)
>   at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
>   at java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
>   at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
>   at java.util.zip.ZipFile.(ZipFile.java:247)
>   at java.util.zip.ZipFile.(ZipFile.java:177)
>   at java.util.jar.JarFile.(JarFile.java:346)
>   at java.util.jar.JarFile.(JarFile.java:317)
>   at java.util.jar.JarFile.(JarFile.java:283)
>   at 
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103) 
> [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:69)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:61)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
>  [org.apache.jackrabbit.vault:3.2.8]
> (...)
> {noformat}
> Instead a check for underlying file existence and size might be useful here 
> and in the case of truncated file a new implementation of 
> [VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
>  for hollow packages might be returned.
> (see also [^JCRVLT-339.patch] or this PR: 
> [https://github.com/apache/jackrabbit-filevault/pull/50])
> Similar approach connected with underlying VLT package file truncation in 
> container based setups can be find in SLING-8105 and its 

[jira] [Comment Edited] (JCRVLT-339) Add FSPackageRegistry support for hollow packages

[Krystian Nowak (JIRA)]

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

Krystian Nowak edited comment on JCRVLT-339 at 7/17/19 7:46 AM:


[~dsuess]: Didn't know how to put binaries to patch - shall I attach them to 
this JIRA issue, or is pointing to the PR 
[https://github.com/apache/jackrabbit-filevault/pull/50/files] (as [~tripod] 
mentioned) enough?


was (Author: krystian):
[~dsuess]: Didn't know how to put binaries to patch - shall I attach them to 
this JIRA issue, or is pointing to the PR 
[https://github.com/apache/jackrabbit-filevault/pull/50/files] (as [~tripod] 
mentioned) is enough?

> Add FSPackageRegistry support for hollow packages
> -
>
> Key: JCRVLT-339
> URL: https://issues.apache.org/jira/browse/JCRVLT-339
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Krystian Nowak
>Priority: Major
> Attachments: JCRVLT-339.patch
>
>
> The logic in 
> [FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
>  may be improved to handle truncated files proactively before 
> [ZipVaultPackage is instantiated in 
> FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
>  while trying to open it to create _VaultPackage_ in [getPackage 
> method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
> This kind of truncation is a mechanism in container based setups to 
> effectively reduce disk usage without functional impact.
> As [getPackage in 
> RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
>  is declared as not returning null (_@Nonnull_ annotation), but throwing 
> _IOException_ - this exceptional situation of truncation in filed-based case 
> might be signalled this way and handled properly by callers aware of the 
> truncation mechanism.
> Currently the exception (in the case of file truncation) is thrown multiple 
> levels lower when accessing _java.util.zip.ZipFile_ with verbose and 
> unconditional logging on multiple levels as the one given below:
> {noformat}
> 12.07.2019 15:06:48.730 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while 
> loading package /foo/bar/baz.zip.
> 12.07.2019 15:06:48.732 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud 
> not open file /foo/bar/baz.zip as ZipVaultPackage.
>  java.util.zip.ZipException: zip file is empty
>   at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
>   at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
>   at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
>   at java.util.zip.ZipFile$Source.(ZipFile.java:1274)
>   at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
>   at java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
>   at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
>   at java.util.zip.ZipFile.(ZipFile.java:247)
>   at java.util.zip.ZipFile.(ZipFile.java:177)
>   at java.util.jar.JarFile.(JarFile.java:346)
>   at java.util.jar.JarFile.(JarFile.java:317)
>   at java.util.jar.JarFile.(JarFile.java:283)
>   at 
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103) 
> [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:69)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:61)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
>  [org.apache.jackrabbit.vault:3.2.8]
> (...)
> {noformat}
> Instead a check for underlying file existence and size might be useful here 
> and in the case of truncated file a new implementation of 
> [VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
> 

[jira] [Comment Edited] (JCRVLT-341) https doesn't work anymore

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-341 at 7/17/19 7:08 AM:
--

> AFAICS the {{httpHost}} is only used for the basic authentication 

yes, I think so, too. that's why the error is not a SSL handshake error or 
similar, but a {{PathNotFoundException}}, because the credentials are not 
picked up for the http scheme. right?

btw, I can reproduce the error locally, too.


was (Author: tripod):
> AFAICS the {{httpHost}} is only used for the basic authentication 

yes, I think so, too. that's why the error is not a SSL handshake error or 
similar, but a {{PathNotFoundException}}, because the credentials are not 
picked up for the http scheme. right?

btw, I can reproduce the error locally, tool.

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-341:
-

> AFAICS the {{httpHost}} is only used for the basic authentication 

yes, I think so, too. that's why the error is not a SSL handshake error or 
similar, but a {{PathNotFoundException}}, because the credentials are not 
picked up for the http scheme. right?

btw, I can reproduce the error locally, tool.

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCRVLT-341:
---

What exactly is the fix?

This will require a sequence of Jackrabbit and filevault releases, so it'll 
take some time...

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[WalterSteiner (JIRA)]

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

WalterSteiner commented on JCRVLT-341:
--

[~tripod] [~reschke] [~kwin]

Hi all

I managed to fix the bug locally on my machine. I applied the fix above and now 
it works fine.

I hope you can fix it soon. Do you have a timeline?

Regards

Walter

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on JCRVLT-341:


AFAICS the {{httpHost}} is only used for the basic authentication 
(https://github.com/apache/jackrabbit/blob/48e725ca1931e972fd6bde3902db85b9769e7011/jackrabbit-spi2dav/src/main/java/org/apache/jackrabbit/spi2dav/RepositoryServiceImpl.java#L552).
 And there the scheme should IMHO not matter.

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCRVLT-341:
---

Please open a bug for JCR then. I assume that the service would need to use 

 instead?

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-339) Add FSPackageRegistry support for hollow packages

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-339:
-

^^^ the PR is here: 
[https://github.com/apache/jackrabbit-filevault/pull/50/files]

> Add FSPackageRegistry support for hollow packages
> -
>
> Key: JCRVLT-339
> URL: https://issues.apache.org/jira/browse/JCRVLT-339
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Krystian Nowak
>Priority: Major
> Attachments: JCRVLT-339.patch
>
>
> The logic in 
> [FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
>  may be improved to handle truncated files proactively before 
> [ZipVaultPackage is instantiated in 
> FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
>  while trying to open it to create _VaultPackage_ in [getPackage 
> method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
> This kind of truncation is a mechanism in container based setups to 
> effectively reduce disk usage without functional impact.
> As [getPackage in 
> RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
>  is declared as not returning null (_@Nonnull_ annotation), but throwing 
> _IOException_ - this exceptional situation of truncation in filed-based case 
> might be signalled this way and handled properly by callers aware of the 
> truncation mechanism.
> Currently the exception (in the case of file truncation) is thrown multiple 
> levels lower when accessing _java.util.zip.ZipFile_ with verbose and 
> unconditional logging on multiple levels as the one given below:
> {noformat}
> 12.07.2019 15:06:48.730 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while 
> loading package /foo/bar/baz.zip.
> 12.07.2019 15:06:48.732 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud 
> not open file /foo/bar/baz.zip as ZipVaultPackage.
>  java.util.zip.ZipException: zip file is empty
>   at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
>   at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
>   at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
>   at java.util.zip.ZipFile$Source.(ZipFile.java:1274)
>   at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
>   at java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
>   at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
>   at java.util.zip.ZipFile.(ZipFile.java:247)
>   at java.util.zip.ZipFile.(ZipFile.java:177)
>   at java.util.jar.JarFile.(JarFile.java:346)
>   at java.util.jar.JarFile.(JarFile.java:317)
>   at java.util.jar.JarFile.(JarFile.java:283)
>   at 
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103) 
> [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:69)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:61)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
>  [org.apache.jackrabbit.vault:3.2.8]
> (...)
> {noformat}
> Instead a check for underlying file existence and size might be useful here 
> and in the case of truncated file a new implementation of 
> [VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
>  for hollow packages might be returned.
> (see also [^JCRVLT-339.patch] or this PR: 
> [https://github.com/apache/jackrabbit-filevault/pull/50])
> Similar approach connected with underlying VLT package file truncation in 
> container based setups can be find in SLING-8105 and its corresponding 
> change: 
> 

[jira] [Commented] (JCRVLT-341) https doesn't work anymore

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-341:
-

I guess the problem is in spi2dav, then:

[https://github.com/apache/jackrabbit/blob/48e725ca1931e972fd6bde3902db85b9769e7011/jackrabbit-spi2dav/src/main/java/org/apache/jackrabbit/spi2dav/RepositoryServiceImpl.java#L331]

/cc [~reschke]

 

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCRVLT-339) Add FSPackageRegistry support for hollow packages

[JIRA]

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

Dominik Süß commented on JCRVLT-339:


[~tripod] sure thing -  [~krystian] patch looks good. The only thing is that 
the patch by nature doesn't contain the binary - a PR via github would be 
easier as it would also provide the binary test resource. Constrained to 
properties is fine as this is all information typically required to visualize 
package or calculate dependencies and therefore allows removal of the binaries 
(no need for truncation afterwards) without affecting the installation of 3rd 
packages.

> Add FSPackageRegistry support for hollow packages
> -
>
> Key: JCRVLT-339
> URL: https://issues.apache.org/jira/browse/JCRVLT-339
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Krystian Nowak
>Priority: Major
> Attachments: JCRVLT-339.patch
>
>
> The logic in 
> [FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
>  may be improved to handle truncated files proactively before 
> [ZipVaultPackage is instantiated in 
> FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
>  while trying to open it to create _VaultPackage_ in [getPackage 
> method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
> This kind of truncation is a mechanism in container based setups to 
> effectively reduce disk usage without functional impact.
> As [getPackage in 
> RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
>  is declared as not returning null (_@Nonnull_ annotation), but throwing 
> _IOException_ - this exceptional situation of truncation in filed-based case 
> might be signalled this way and handled properly by callers aware of the 
> truncation mechanism.
> Currently the exception (in the case of file truncation) is thrown multiple 
> levels lower when accessing _java.util.zip.ZipFile_ with verbose and 
> unconditional logging on multiple levels as the one given below:
> {noformat}
> 12.07.2019 15:06:48.730 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while 
> loading package /foo/bar/baz.zip.
> 12.07.2019 15:06:48.732 *ERROR* [MyThread1] 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud 
> not open file /foo/bar/baz.zip as ZipVaultPackage.
>  java.util.zip.ZipException: zip file is empty
>   at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
>   at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
>   at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
>   at java.util.zip.ZipFile$Source.(ZipFile.java:1274)
>   at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
>   at java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
>   at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
>   at java.util.zip.ZipFile.(ZipFile.java:247)
>   at java.util.zip.ZipFile.(ZipFile.java:177)
>   at java.util.jar.JarFile.(JarFile.java:346)
>   at java.util.jar.JarFile.(JarFile.java:317)
>   at java.util.jar.JarFile.(JarFile.java:283)
>   at 
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103) 
> [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:69)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.(ZipVaultPackage.java:61)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
>  [org.apache.jackrabbit.vault:3.2.8]
>   at 
> org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
>  [org.apache.jackrabbit.vault:3.2.8]
> (...)
> {noformat}
> Instead a check for underlying file existence and size might be useful here 
> and in the case of truncated file a new implementation of 
> [VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
>  for hollow packages might be returned.
> 

[jira] [Comment Edited] (JCRVLT-341) https doesn't work anymore

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-341 at 7/17/19 6:00 AM:
--

[~tripod]

If I change the url pattern as your proposing, I get the following error

{noformat}
{
"status": "error",
 "message": "Error while executing 'start': Login failed: Invalid workspace 
name ''."
}
{noformat}

I debugged the code a little bit and I think I found the error. It is during 
the login in the source repository. 

In the following jar "org.apache.jackrabbit.vault.rcp-3.2.8.jar" includes 

{noformat}


 org.apache.jackrabbit
 jackrabbit-spi2dav
 2.16.3

{noformat}

That jar has the class "org.apache.jackrabbit.spi2dav.RepositoryServiceImpl" 
and on line 231 of this class,  a HttpHost is instanciated. If the schema is 
not a parameter of the constructor, the constructor assumes "http". So the 
login fails for this url "*http*://@host:port". The login-address should be 
"*https*://@host:port".

{code}
try {
 URI repositoryUri = computeRepositoryUri(uri);
 httpHost = new HttpHost(repositoryUri.getHost(), repositoryUri.getPort()*, 
repositoryUri.getScheme()*);

 nsCache = new NamespaceCache();
 uriResolver = new URIResolverImpl(repositoryUri, this, 
DomUtil.createDocument());
 NamePathResolver resolver = new NamePathResolverImpl(nsCache);
 valueFactory = new ValueFactoryQImpl(qValueFactory, resolver);

} catch (URISyntaxException e) {
 throw new RepositoryException(e);
} catch (ParserConfigurationException e) {
 throw new RepositoryException(e);
}
{code}

Do you have the possibility to fix that and send me a patch so I can test it?

Thanks a lot in advance.

Regards

Walter


was (Author: ch00stw):
[~tripod]

If I change the url pattern as your proposing, I get the following error

{

"status": "error",
 "message": "Error while executing 'start': Login failed: Invalid workspace 
name ''."
}

I debugged the code a little bit and I think I found the error. It is during 
the login in the source repository. 

In the following jar "org.apache.jackrabbit.vault.rcp-3.2.8.jar" includes 



 org.apache.jackrabbit
 jackrabbit-spi2dav
 2.16.3


 

That jar has the class "org.apache.jackrabbit.spi2dav.RepositoryServiceImpl" 
and on line 231 of this class,  a HttpHost is instanciated. If the schema is 
not a parameter of the constructor, the constructor assumes "http". So the 
login fails for this url "*http*://@host:port". The login-address should be 
"*https*://@host:port".

<<

try {
 URI repositoryUri = computeRepositoryUri(uri);
 httpHost = new HttpHost(repositoryUri.getHost(), repositoryUri.getPort()*, 
repositoryUri.getScheme()*);

 nsCache = new NamespaceCache();
 uriResolver = new URIResolverImpl(repositoryUri, this, 
DomUtil.createDocument());
 NamePathResolver resolver = new NamePathResolverImpl(nsCache);
 valueFactory = new ValueFactoryQImpl(qValueFactory, resolver);

} catch (URISyntaxException e) {
 throw new RepositoryException(e);
} catch (ParserConfigurationException e) {
 throw new RepositoryException(e);
}

>>

Do you have the possibility to fix that and send me a patch so I can test it?

Thanks a lot in advance.

Regards

Walter

> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Priority: Major
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now 
> upgraded to the version 3.2.8. I want to transfer with the following path 
> "/content/etc/robots.txt"  from one aem-author instance to another. I get the 
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt] 
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src 
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException: 
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is 
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
>  "cmd":"create",
>  "id":"copy-contentetcrobots.txt",
>  
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
>  "dst":"/content/etc/robots.txt",
>  "batchsize": 2048,
>  "update": true,
>  "onlyNewer": true,
>  "recursive": true,
>  "throttle": 1,
>  "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our 
> company.
>  
>  



--
This message was sent by Atlassian JIRA