[
https://issues.apache.org/jira/browse/SLING-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587697#comment-16587697
]
Georg Henzler edited comment on SLING-7790 at 8/21/18 4:41 PM:
---------------------------------------------------------------
[~kwin] So after more tests I agree that automatically installing all contained
bundles and configurations is dangerous. I think a good middle ground is to
specify a regex called {{installPathRegex}} in the package properties, that way
it is easy to specify a root path (like e.g. {{/apps/myproj/install.*}}) or
list individual entries (e.g.
{{(/apps/myproj/install/bundle1.jar|/apps/myproj/install/bundle2.jar)}}) or
just provide a certain bundle/config directly
({{/apps/myproj/install/bundle1.jar}}).
To not couple this too closely to the JCR installer, the properties
{{sling.jcrinstall.folder.name.regexp}} and
{{sling.jcrinstall.folder.max.depth}} in PID
{{org.apache.sling.installer.provider.jcr.impl.JcrInstaller}} are not taken
into account. It is up to the user to use a path that is in line with the
JcrInstaller or not, the only thing taken into account is that
{{installPathRegex}} matches and the extension is either {{.config}} or
{{.jar}} to install configs or bundles respectively.
One use case that has to be covered though is runmodes, the
{{<path>.runmode.andOtherRunmode.andThirdRunmode/<configOrBundle}} notation
shall be supported.
I updated
https://github.com/ghenzler/org.apache.sling.installer.provider.installhook
accordingly.
was (Author: henzlerg):
[~kwin] So after more tests I agree that automatically install all contained
bundles and configurations is dangerous. I think a good middle ground to
specify a regex called {{installPathRegex}} in the package properties, that way
it is easy to specify a root path (like e.g. {{/apps/myproj/install.*}}) or
list individual entries (e.g.
{{(/apps/myproj/install/bundle1.jar|/apps/myproj/install/bundle2.jar)}}) or
just provide a certain bundle/config directly
({{/apps/myproj/install/bundle1.jar}}).
To not couple this too closely to the JCR installer, the properties
{{sling.jcrinstall.folder.name.regexp}} and
{{sling.jcrinstall.folder.max.depth}} in PID
{{org.apache.sling.installer.provider.jcr.impl.JcrInstaller}} are not taken
into account (it is up to the user to use a path that is in line with the
JcrInstaller or not, the only thing taken into account is that
{{installPathRegex}} matches and the extension is either {{.config}} or
{{.jar}} to install configs or bundles respectively.
One use case that has to be covered though is runmodes, the
{{.runmode.andOtherRunmode.andThirdRunmode}} notation shall be supported.
I updated
https://github.com/ghenzler/org.apache.sling.installer.provider.installhook
accordingly.
> Allow for synchronous installation of bundles and configurations via install
> hook
> ---------------------------------------------------------------------------------
>
> Key: SLING-7790
> URL: https://issues.apache.org/jira/browse/SLING-7790
> Project: Sling
> Issue Type: New Feature
> Components: Installer
> Reporter: Georg Henzler
> Assignee: Georg Henzler
> Priority: Major
>
> Normally bundles configurations are installed asynchronously after a bundle
> is saved to the JCR during package installation (vault packages). This is due
> to the backgroundThread that the OsgiInstallerImpl is using. Since the
> introduction of the pauseInstallation signal node via SLING-3747, the
> installation of bundles and configurations is even forced to after the
> completed vault package installation. This behaviour also means that the
> package dependency can be declared, but it is not effective on "contained
> bundle level" but only on JCR content level. The following is not possible
> today:
> Complete Package with sub packages:
> * Package A (containing Bundle A)
> * Package B (containing Bundle B) with dependency to Bundle A
> If it is just a OSGi package dependency from Bundle B to Bundle A the
> installation order does not matter (the OSGi framework will sort it out).
> However if the content of Package B has a dependency to bundle A (think
> custom oak restrictions [1] or install hooks referenced) there will be an
> error.
> To allow for those cases and to avoid manual steps (not providing a complete
> package often means exactly that), it would be good to have a means to
> install contained bundles of a package synchronously. This can be achieved by
> a fairly simple install hook that "pre-installs" the contained
> InstallableResources with the correct digest to the OsgiInstaller. The
> subsequent call of sling-org-apache-sling-installer-provider-jcr will just
> update the already installed resource again with the same digest (which will
> not cause any action in the system).
> Obviously this mechanism should only be used where needed and only for
> configurations and bundles that are safe to install (bundles/configs that
> will never restart any of the base services). Using the install hook makes
> the mechanism "opt-in".
> [1]
> https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#pluggability
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
