[
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)
