[
https://issues.apache.org/jira/browse/SLING-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778855#action_12778855
]
Ian Boston commented on SLING-1189:
-----------------------------------
So the following is just my 2c's worth.
The launchpad's job is to build a structure which the OSGi container can start
up in, IIUC it unpacks its contents into a Felix managed environment and then
hands over control to the Felix environment.
Users may then manipulate that environment using Felix tools doing all sorts of
things, unknown (like even downgrading a bundle).
Normally on second starts the launchpad just sees that Felix has a working copy
(which may have been reconfigured) and does not touch it, but hands control
over to Felix.
IMVHO, it would be wrong for the launchpad to modify the Felix environment
based on what it has internally since it has absolutely no idea what
configuration and user actions might have been taken by users to configure the
Felix environment post launch.
I know for a fact that the development community that I am working with relies
on this behavior to customise layout and configuration post launch to achieve
different aims. (Non java UI developers loading different sets of bundles to
get a edit-browser refresh cycle, sometimes older versions) for that use, this
patch would cause problems. Sorry.
> When comparing SNAPSHOT-versioned bundles, also check the Bnd-LastModified
> Header
> ---------------------------------------------------------------------------------
>
> Key: SLING-1189
> URL: https://issues.apache.org/jira/browse/SLING-1189
> Project: Sling
> Issue Type: Improvement
> Components: Launchpad
> Reporter: Justin Edelson
> Attachments: SLING-1189.patch
>
>
> As an enhancement to the functionality provided with SLING-1162, if a bundle
> in resources/bundles/<startlevel> is already installed with the same version
> and the version ends in SNAPSHOT, if both bundles include a Bnd-LastModified
> header, use that header as an additional check.
> The current implementation fails under this use case:
> 1) SNAPSHOT included in the WAR/JAR file.
> 2) newer SNAPSHOT installed via console/shell
> 3) App is restarted
> At this point, the original SNAPSHOT will be installed, not the newer one
> included.
> I'll have a patch for this soonish.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
