[
https://issues.apache.org/jira/browse/SLING-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874155#comment-15874155
]
Konrad Windszus edited comment on SLING-6392 at 2/20/17 7:48 AM:
-----------------------------------------------------------------
Just to outline what the problem was and why the patch was reverted: It
conflicts with a 3rd party {{ResourceTransformer}} which takes care of
{{content-packages}}, very similar to what Sling does in
https://github.com/apache/sling/tree/trunk/installer/factories/packages. The
difference to the Sling version is that the 3rd party resource transformer will
put a resource for each subpackage with the same url into the
{{TransformationResults}}. Basically the patch conflicts with all
{{ResourceTransformers}} returning more than one {{TransformationResult}}.
The only way to solve this is to change the Resource URL. So multiple resources
extracted from the same source should get different URLs, i.e.
{{/some/path/resource1}} is transformed into URLs
{{/some/path/resource1/subresource1}} and
{{/some/path/resource1/subresource2}}. In case of updates/removes of the
original URL, all child URLs should also be considered.
To be backwards compatible the separation of the Resource URLs should be done
in {{o.a.s.installer.core.impl.PersistentResourceList#transform}} by just
appending a suffix like {{/<index>}} to the resource URL for each individual
sub resource.
[~cziegeler][[~dsuess][[~karlpauls] WDYT? Is it planned to have the
improved/changed subpackage handling also in the Sling module?
was (Author: kwin):
Just to outline what the problem was and why the patch was reverted: It
conflicts with a 3rd party {{ResourceTransformer}} which takes care of
{{content-packages}}, very similar to what Sling does in
https://github.com/apache/sling/tree/trunk/installer/factories/packages. The
difference to the Sling version is that the 3rd party resource transformer will
put a resource for each subpackage with the same url into the
{{TransformationResult}}s. Basically the patch conflicts with all
{{ResourceTransformer}}s returning more than one {{TransformationResult}}.
The only way to solve this is to change the Resource URL. So multiple resources
extracted from the same source should get different URLs, i.e.
{{/some/path/resource1}} is transformed into URLs
{{/some/path/resource1/subresource1}} and
{{/some/path/resource1/subresource2}}. In case of updates/removes of the
original URL, all child URLs should also be considered.
To be backwards compatible the separation of the Resource URLs should be done
in {{o.a.s.installer.core.impl.PersistentResourceList#transform}} by just
appending a suffix like {{/<index>}} to the resource URL for each individual
sub resource.
[~cziegeler][[~dsuess][[~karlpauls] WDYT? Is it planned to have the
improved/changed subpackage handling also in the Sling module?
> OSGi Installer: Symbolic name changes on a resource keeping the same URL are
> not supported
> ------------------------------------------------------------------------------------------
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
> Issue Type: Bug
> Components: Installer
> Affects Versions: Installer Core 3.8.0
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-test-v01.patch, SLING-6392-test-v02.patch,
> SLING-6392-v01.patch
>
>
> After deploying bundle with symbolic name {{A}} to JCR location
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is
> correctly being picked up by the JcrInstaller or FileInstaller and deployed
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the
> updated JAR has been deployed to the same location in the JCR
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}}
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is
> getting installed!
> Such a change can happen if you use the {{maven-bundle-plugin}} with a
> default configuration and you just change the groupId of the underlying maven
> project. That will not affect the finalName of the artifact (by default
> artifactId) but the symbolic name of the bundle (see
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
