[jira] [Commented] (JCRVLT-750) startup error around unclosed archives

["Konrad Windszus (Jira)" <ji...@apache.org>]

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

Konrad Windszus commented on JCRVLT-750:
----------------------------------------

From the log shared above it pretty much looks like this missing close is within `com.adobe.granite.installer.factory.packages.impl.PackageTransformer`. The sub packages are IMHO properly closed in https://github.com/apache/jackrabbit-filevault/blob/14727e599aec7cfb5135eaa33944a11a391188f6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L535. Please reopen if you have a test case pointing to an issue within FileVault.

> startup error around unclosed archives
> --------------------------------------
>
>                 Key: JCRVLT-750
>                 URL: https://issues.apache.org/jira/browse/JCRVLT-750
>             Project: Jackrabbit FileVault
>          Issue Type: Bug
>          Components: vlt
>    Affects Versions: 3.7.2
>            Reporter: Ankita Agarwal
>            Priority: Major
>
> {code:java}
> 11.03.2024 13:33:10.690 *ERROR* [OsgiInstallerImpl] org.apache.jackrabbit.vault.fs.io.AbstractArchive Detected unclosed archive. To figure out where it has been opened set the Java System property 'vault.enableStackTraces' to 'true'11.03.2024 13:33:10.690 *ERROR* [OsgiInstallerImpl] org.apache.jackrabbit.vault.fs.io.AbstractArchive Detected unclosed archive. To figure out where it has been opened set the Java System property 'vault.enableStackTraces' to 'true'11.03.2024 13:33:10.690 *ERROR* [OsgiInstallerImpl] org.apache.jackrabbit.vault.fs.io.AbstractArchive Detected unclosed archive. To figure out where it has been opened set the Java System property 'vault.enableStackTraces' to 'true' 
> Full stacktrace of above unclosed archive is (it can be seen in logs using the switch {{{}-Dvault.enableStackTraces=true{}}}):
> {code}
> {code:xml}
> java.lang.Exception: Open Stack Trace
> 	at org.h2.util.CloseWatcher.register(CloseWatcher.java:85)
> 	at org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:156)
> 	at org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.getArchive(ZipVaultPackage.java:107)
> 	at org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.getMetaInf(ZipVaultPackage.java:145)
> 	at org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.getPropertiesMap(ZipVaultPackage.java:323)
> 	at org.apache.jackrabbit.vault.packaging.impl.PackagePropertiesImpl.getProperty(PackagePropertiesImpl.java:265)
> 	at org.apache.jackrabbit.vault.packaging.impl.PackagePropertiesImpl.getId(PackagePropertiesImpl.java:62)
> 	at org.apache.jackrabbit.vault.packaging.impl.JcrPackageDefinitionImpl.unwrap(JcrPackageDefinitionImpl.java:219)
> 	at org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.tryUnwrap(JcrPackageImpl.java:258)
> 	at org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:414)
> 	at org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:356)
> 	at org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:350)
> 	at com.adobe.granite.installer.factory.packages.impl.PackageTransformer$InstallPackageTask.execute(PackageTransformer.java:348)
> 	at org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:918)
> 	at org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:755)
> 	at org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:304)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> {code}
> It seems that, in case of sub packages, filevault opens the archive but only processes (and close) them in case of non-recursive import option is set to false [0]. Packages are deployed non-recursively in this case and filevault is not closing the archives when subpacks are not empty.
> This seems to be happening for the we-retail packages, as in case of we-retail the created archive is of type ZipArchive [1] (and we are adding a close watcher for it [3]), for other cases in which subpacks are there, archive is of type MemoryArchive [2]
> I believe this [filevault.patch{^}!https://jira.corp.adobe.com/images/icons/link_attachment_7.gif|width=7,height=7!{^}|https://jira.corp.adobe.com/secure/attachment/11792561/11792561_filevault.patch] should fix the problem,
> [0]: [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L484]
> [1]: [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L323-L333]
> [2]: [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L306-L323]
> [3]: [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/ZipArchive.java#L156]
> [Edit|https://jira.corp.adobe.com/secure/EditComment!default.jspa?id=14661174&commentId=41010223]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)