[
https://issues.apache.org/jira/browse/JCRVLT-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16807187#comment-16807187
]
Dominik Süß commented on JCRVLT-336:
------------------------------------
[~tripod] I again can no longer assign tasks - PR with proposal created at
https://github.com/apache/jackrabbit-filevault/pull/43 - despite of the
configuration option (default unscoped as before) there is no exposed change.
As the installation bits are totally different in JCR Registry & PackageManager
I limited the option to the FS solution for now.
The alternative would have been to make the filter injeciton part of the
execution plan - but that didn't work out easily as the construction of the
filter already requires the unwrapped Filter to be known. An additional
challenge is that the ScopedFilter is based on the DefaultWorkspaceFilter which
defacto is the only implementation but not returned as such (only the
WorkSpaceFilter Interface) and therefore requires an instanceOf check & casting.
> FSPackageRegistry should allow forced application scoping of
> PackageInstallations
> ---------------------------------------------------------------------------------
>
> Key: JCRVLT-336
> URL: https://issues.apache.org/jira/browse/JCRVLT-336
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
> Reporter: Dominik Süß
> Priority: Major
>
> In contrast to JCR Package Registry the installation of Packages via FS
> PackageRegistry is designed for application deployment procedures. As these
> installations are mostly hidden behind the implementation details of
> ExecutionPlan I propose the introduction of a flag that implicitly decorates
> the filter with the already existing ScopedFilter.
> Although it is tempting to perform the same for application scoping on the
> JCR Registry the various ways to tricker package installations make it
> harder to introduce a similar configuration that catches all scenarios - as
> ExecutionPlan is not a scenario for installation via PackageManager (the
> still dominant scenario of installing packages at runtime) - the consuming
> code may decorate and set the decorated workspaceFilter, making it an
> explicit choice of the consuming code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
