You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2009/11/17 14:32:39 UTC

[jira] Issue Comment Edited: (SLING-1189) When comparing SNAPSHOT-versioned bundles, also check the Bnd-LastModified Header

    [ https://issues.apache.org/jira/browse/SLING-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778869#action_12778869 ] 

Felix Meschberger edited comment on SLING-1189 at 11/17/09 1:31 PM:
--------------------------------------------------------------------

Justin, thanks for providing the patch; Ian thanks for your thoughts.

Here are mine:

As I understand it, the patch just enhances the way replacements of installed SNAPSHOT bundles are detected. As such it is just a - useful IMHO - extension of the existing functionality.

Currently the BootstrapInstaller looks into the package being run (the sling standalone application or the sling web application) for bundles to be placed into the ${sling.home}/startup folder. Such bundles are unpacked. After unpacking all bundles, the ${sling.home}/startup folder is scanned for any bundles which needs to be installed or updated.

Installation takes place, if no bundle with the bundle symbolic name of the bundle file is installed. An update may take place if there exists a bundle with the same symbolic name. Depending on the bundle versions, it is checked whether an update really does take place:

   * If the bundle file version is more recent than the installed version, update takes place
   * If the bundle file and installed version are the same *and* are SNAPSHOTs, an update takes place

This patch refines the second state: which only updates the installed bundles for SNAPSHOT versions if any of the following applies:

   * either of the bundles does not have a bnd-lastmodified header (set by the bnd library on behalf of the maven bundle plugin)
   * both have a bnd-lastmodified header but the value of the bundle file indicates a more recent build

So in this respect, I think this patch makes sense. Except for potential bundle updates, nothing really happens. Most notably, there is no downgrade taking place.

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.

Most importantly: The BootstrapInstaller only copies bundle files if either the launcher file is more recent than the latest BootstrapInstaller cycle or any bundle has been added since the last BootstrapInstaller cycle. Generally, all things unmodified, the BootstrapInstaller will do nothing.


So, I would be positive to apply this patch.

WDYT Ian ?

      was (Author: fmeschbe):
    Justin, thanks for providing the patch; Ian thanks for your thoughts.

Here are mine:

As I understand it, the patch just enhances the way replacements of installed SNAPSHOT bundles are detected. As such it is just a - useful IMHO - extension of the existing functionality.

Currently the BootstrapInstaller looks into the package being run (the sling standalone application or the sling web application) for bundles to be placed into the ${sling.home}/startup folder. Such bundles are unpacked. After unpacking all bundles, the ${sling.home}/startup folder is scanned for any bundles which needs to be installed or updated.

Installation takes place, if no bundle with the bundle symbolic name of the bundle file is installed. An update may take place if there exists a bundle with the same symbolic name. Depending on the bundle versions, it is checked whether an update really does take place:

   * If the bundle file version is more recent than the installed version, update takes place
   * If the bundle file and installed version are the same *and* are SNAPSHOTs, an update takes place

This patch refines the second state: which only updates the installed bundles for SNAPSHOT versions if any of the following applies:

   * either of the bundles does not have a bnd-lastmodified header (set by the bnd library on behalf of the maven bundle plugin)
   * both have a bnd-lastmodified header but the value of the bundle file indicates a more recent build

So in this respect, I think this patch makes sense. Except for potential bundle updates, nothing really happens. Most notably, there is no downgrade taking place.

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.

So, I would be positive to apply this patch.

WDYT Ian ?
  
> 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.