[
https://issues.apache.org/jira/browse/SLING-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778888#action_12778888
]
Justin Edelson commented on SLING-1189:
---------------------------------------
I think Felix captured the current / post-patch behavior correctly.
The purpose of this patch is to better refine the "should the currently
installed bundle be replaced" logic. This isn't to say that Ian's concerns
aren't valid -- they are. Launchpad would be a lot easier if it could read your
mind :) But, short of that, it has (IMHO) to try to strike a balance between
behaving like a traditional Java app (i.e. what's in the WAR/JAR is what is
used) and a bare-bones OSGi framework. For me, this is all about trying to meet
expectations - if someone upgrades a bundle inside the WAR file, it's
reasonable to expect the bundle to be installed when the WAR is deployed.
To be clear, downgraded bundles will be overwritten without this patch (or
SLING-1162) if the base JAR changes.
Felix - I don't understand what you mean here:
> To ensure no bundles from a launcher will ever be installed, I suggest the
> bar launcher application (or launcher web
> application) from the launchpad/base module is used for launching.
Also, I'm not sure this is true:
> The BootstrapInstaller only copies bundle files if ... any bundle has been
> added since
> the last BootstrapInstaller cycle.
Ian - perhaps it would make sense to add support for a property called
"neverUpgradeInstalledBundles" or something like that? While I think the
current behavior (i.e. basing the decision to scan for upgrades on the
timestamp of the base JAR) is correct, I can imagine it could get confusing.
> 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.
