Community
Participate
Working Groups
Build Identifier: 3.7.0 I20100921-1024 After p2 provisioning operations the changes in the bundles set are reflected in the configuration/bundles.info file as well as in the plugins folder but are not known to the OSGi framework until the simpleconfigurator component applies the changes at the next framework start. In case of an updated bundle, the change is detected on the basis of the bundle's symbolic name and version written in bundles.info; the bundle installation, however, is delegated to the OSGi framework providing the bundle's location only. The location is usually a reference to the bundle's file in plugins folder and is assumed to be unique for each version. This assumption does not hold true for systems which choose a custom naming scheme for its installed bundles which is not tied to the bundle's version, e.g. the file name contains the symbolic name only. In case that an old and a new version of the bundle turn out to share the same file name in the plugins folder, the location in bundles.info seems to be unchanged so the framework assumes that it is already installed and does not refresh the information about it. The simpleconfigurator fails to detect that and the updated bundle is actually not installed at all. Reproducible: Always Steps to Reproduce: 1. Unpack the system from the system.zip attachment. Note that it is specifically customized bundles file name to contain only the symbolic name in the plugins folder after p2 install, i.e. the version part is missing. 2. Unpack the attached p2 repositories which contain two different versions of a TestBundle. 3. Install from test_repo1 using the p2 director application from Eclipse IDE with the following arguments "-repository file:/<path_to_repository>/test_repo1 -installIU TestFeature.feature.group -destination <path_to_the_unzipped_system> -profile Test -bundlepool <path_to_the_unzipped_system>" 4. Start the OSGi framework in the folder of the unzipped system with the following command: "java -Dosgi.install.area=. -Dorg.eclipse.equinox.simpleconfigurator.exclusiveInstallation=false -Declipse.ignoreApp=true -Dosgi.noShutdown=true -jar plugins\org.eclipse.osgi.jar -consoleLog -console". It is necessary for the simpleconfigurator to apply the change from the previous step. You can check that the new bundle is installed by listing all bundles with the "ss" command in OSGi console. Take note of TestBundle's version. Compare it with the contents in configuration/bundles.info. 5. Install the same bundle from repository test_repo2 in the same way as in step 3 with the necessary change of the repository argument. 6. Open configuration/bundles.info and the manifest in plugins/TestBundle.jar to make sure that the version of TestBundle was updated. Take note that the bundle'e file name was not changed. 7. Start the framework with the same command as in step 4. Observe that TestBundle is now missing in the bundles list, i.e. simpleconfigurator has failed to update it.
Created attachment 180022 [details] OSGi system with customized bundle file names in plugins folder
Created attachment 180023 [details] p2 repository with old version of TestBundle
Created attachment 180024 [details] p2 repository with new version of TestBundle
Created attachment 180026 [details] patch for simpleconfigurator to invoke a bundle update if needed Simpleconfigurator calls the OSGi framework to install the updated bundle supplying its bundle location. In case that this location is the same for the old and for the new version of the bundle, OSGi does not perform any installation and returns the old org.osgi.framework.Bundle's instance to simpleconfigurator. The patch adds an additional check for the bundle's name and version extracted from bundles.info and from the returned instance. If any changes are detected, simpleconfigurator invokes the update of the bundle to synchronize the metadata.
What I don't understand is why simpleconfigurator did not uninstall the old version first. I thought it usually uninstalled the old versions before installing the new bundles. The other thing that seems strange is that it seems like the jar is being replaced on disk without doing an OSGi provisioning operation. I think p2 depends on the fact that each version of the bundle will always be located in a unique location on disk. Otherwise I think you will run into some pretty strange issues if you simply override an installed bundle's jar on disk. Moving to p2.
(In reply to comment #5) > What I don't understand is why simpleconfigurator did not uninstall the old > version first. I thought it usually uninstalled the old versions before > installing the new bundles. The other thing that seems strange is that it > seems like the jar is being replaced on disk without doing an OSGi provisioning > operation. I think p2 depends on the fact that each version of the bundle will > always be located in a unique location on disk. Otherwise I think you will run > into some pretty strange issues if you simply override an installed bundle's > jar on disk. > > Moving to p2. Actually, the bundle seems to be uninstalled (instead of updated) because you will notice that it is not listed in the result of "ss" command in step 7.
Patch released. Thx.
(In reply to comment #7) > Patch released. Thx. Note that this fix causes bug 387611.
