[
https://issues.apache.org/jira/browse/JCRVLT-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901701#comment-17901701
]
Joerg Hoh commented on JCRVLT-787:
----------------------------------
[~kwin] no, it's unrelated to JCRVLT-755; in this case we clearly know that the
package definition was the problem, and that this package should not have been
installed.
It would be good if filevault could return this as part of its API; the
cleanest way would probably be to change the signature of
{{JcrPackage.install()}} to return a result object, which contains this
information.
The 2nd best option would be a custom ProgressTrackerListener, which counts the
invocations of {{onMessage}} , assuming that this is done for every added,
deleted or modified node. The problem is here, that I don't know how the
deletion of subtrees is handled. Is there a single DELETE message for the
entire tree or do I get a message for every deleted node?
The worst solution would be, that vault logs this information itself to the
log, but we could live with that.
> package installation should provide metrics
> -------------------------------------------
>
> Key: JCRVLT-787
> URL: https://issues.apache.org/jira/browse/JCRVLT-787
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
> Affects Versions: 3.8.2
> Reporter: Joerg Hoh
> Priority: Major
>
> We recently had an issue that the installation of a content package caused
> the deletion of a large content subtree; while the package worked as it
> should , installing the package was neither expected nor known.
> For that reason we just saw the result and it took a while to identify the
> package installation as the root-cause of this situation. This was
> complicated by the lack of know-how and familiarity of the investigating
> people with filevault and content packages.
> For that reason it would be great if filevault could provide a collection of
> metrics (nodes added, nodes deleted, etc) when a package has been
> successfully installed.
> In this case the situation was like this: The filter.xml contained a rule for
> /content/foobar with no mode specified (so the default value of REPLACE was
> used), and in the package just a .content.xml for /content/foobar was
> included; that wiped the entire subtree (a few thousand nodes) in the
> repository below /content/foobar.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
