[jira] [Comment Edited] (SLING-6392) OSGi Installer: Symbolic name changes on a resource keeping the same URL are not supported

["Konrad Windszus (JIRA)" <ji...@apache.org>]

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