You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2015/05/26 16:40:17 UTC

[jira] [Commented] (SLING-4747) Installer does not consistently update bundle location in Webconsole

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

Carsten Ziegeler commented on SLING-4747:
-----------------------------------------

The location string is the first location when the bundle gets installed, it does not change through an update (please see the framework spec for this). If it changes, this means the bundle is removed and the new version is installed fresh

> Installer does not consistently update bundle location in Webconsole
> --------------------------------------------------------------------
>
>                 Key: SLING-4747
>                 URL: https://issues.apache.org/jira/browse/SLING-4747
>             Project: Sling
>          Issue Type: Bug
>          Components: Installer
>    Affects Versions: File Installer 1.0.4
>            Reporter: Jörg Hoh
>
> I have a sling-based application using Apache Oak as content repository. I started with Oak being part of the Launchpad, so I had for example a bundle "org.apache.jackrabbit.oak-solr-osgi" in version 1.0. The OSGI Webconsole displayed as bundle location "launchpad:resources/install.crx3/15/oak-solr-osgi-1.0.0.jar", which is perfect.
> Now I upgraded Oak to version 1.0.13 by putting the bundles inside /libs/system/install. The OSGI Webconsole displays for my bundle oak-solr-osgi the version 1.0.13, but still shows as Bundle location the string "launchpad:resources/install.crx3/15/oak-solr-osgi-1.0.0.jar".
> But this isn't true for all bundles. For example I deployed the bundle oak-mk in version 1.0.13 in the very same way as the oak-solr-osgi bundle, but there the bundle location is updated and displays "jcrinstall:/libs/system/install.crx3/oak-mk-1.0.13.jar", which is correct.
> So the update process seems to work to reliably. I've seen this behaviour not only for mixed installers, but also with jcrinstaller only.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)