Bugzilla – Full Text Bug Listing
| Summary: | Deploying an invalid bundle, then redeploying fails | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Alex Blewitt <alex.blewitt> |
| Component: | unknown | Assignee: | Glyn Normington <glyn.normington> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | glyn.normington |
| Version: | unspecified | ||
| Target Milestone: | 2.1.0.RC1-incubation | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
Thanks for reporting this. Please could you clarify what mechanism was being used to "upload" the bundle, i.e. admin console, Eclipse tooling, or even JMX? Thanks. Sorry, should have said. I was using the web upload tool. Thanks Alex. That's the admin console in Virgo lingo. :-) I am re-creating this problem. My first attempt was to copy the JAR to pickup and this worked correctly: [2010-10-11 15:50:12.631] fs-watcher <HD0001I> Hot deployer processing 'CREATED' event for file 'bug327209.jar'. [2010-10-11 15:50:12.665] fs-watcher <DE0000I> Installing bundle 'bug327209' version '0.0.0'. [2010-10-11 15:50:12.687] fs-watcher <DE0001I> Installed bundle 'bug327209' version '0.0.0'. [2010-10-11 15:50:12.715] fs-watcher <DE0004I> Starting bundle 'bug327209' version '0.0.0'. [2010-10-11 15:50:12.721] start-signalling-4 <DE0005I> Started bundle 'bug327209' version '0.0.0'. [2010-10-11 15:51:04.755] fs-watcher <HD0001I> Hot deployer processing 'MODIFIED' event for file 'bug327209.jar'. [2010-10-11 15:51:04.762] fs-watcher <DE0007I> Refreshing bundle 'bug327209' version '0.0.0'. [2010-10-11 15:51:04.785] fs-watcher <DE0070W> Cannot refresh bundle 'bug327209' version '0.0.0' as the identity would change. The new identity would have been 'BSNForBug327209' version '0.0.0'. [2010-10-11 15:51:04.789] fs-watcher <DE0009E> Refresh failed for bundle 'bug327209' version '0.0.0'. [2010-10-11 15:51:04.795] fs-watcher <DE0010I> Stopping bundle 'bug327209' version '0.0.0'. [2010-10-11 15:51:04.804] fs-watcher <DE0011I> Stopped bundle 'bug327209' version '0.0.0'. [2010-10-11 15:51:04.810] fs-watcher <DE0013I> Uninstalling bundle 'bug327209' version '0.0.0'. [2010-10-11 15:51:04.819] fs-watcher <DE0014I> Uninstalled bundle 'bug327209' version '0.0.0'. [2010-10-11 15:51:04.987] fs-watcher <DE0000I> Installing bundle 'BSNForBug327209' version '0.0.0'. [2010-10-11 15:51:05.007] fs-watcher <DE0001I> Installed bundle 'BSNForBug327209' version '0.0.0'. [2010-10-11 15:51:05.022] fs-watcher <DE0004I> Starting bundle 'BSNForBug327209' version '0.0.0'. [2010-10-11 15:51:05.036] start-signalling-4 <DE0005I> Started bundle 'BSNForBug327209' version '0.0.0'. I'll now try the admin console... Under the admin console, got the same result (below). The behaviour here is that redeploying the bundle first attempts to refresh the bundle but when Virgo discovers that the bundle identity (bundle symbolic name - generated automatically in the first case - plus bundle version) changes, it "escalates" the refresh into undeploy/redeploy. [2010-10-11 15:53:54.894] http-8080-4 <DE0000I> Installing bundle 'bug327209' version '0.0.0'. [2010-10-11 15:53:54.910] http-8080-4 <DE0001I> Installed bundle 'bug327209' version '0.0.0'. [2010-10-11 15:53:54.922] http-8080-4 <DE0004I> Starting bundle 'bug327209' version '0.0.0'. [2010-10-11 15:53:54.931] start-signalling-4 <DE0005I> Started bundle 'bug327209' version '0.0.0'. [2010-10-11 15:54:23.735] http-8080-4 <DE0007I> Refreshing bundle 'bug327209' version '0.0.0'. [2010-10-11 15:54:23.748] http-8080-4 <DE0070W> Cannot refresh bundle 'bug327209' version '0.0.0' as the identity would change. The new identity would have been 'BSNForBug327209' version '0.0.0'. [2010-10-11 15:54:23.762] http-8080-4 <DE0009E> Refresh failed for bundle 'bug327209' version '0.0.0'. [2010-10-11 15:54:23.772] http-8080-4 <DE0010I> Stopping bundle 'bug327209' version '0.0.0'. [2010-10-11 15:54:23.780] http-8080-4 <DE0011I> Stopped bundle 'bug327209' version '0.0.0'. [2010-10-11 15:54:23.786] http-8080-4 <DE0013I> Uninstalling bundle 'bug327209' version '0.0.0'. [2010-10-11 15:54:23.793] http-8080-4 <DE0014I> Uninstalled bundle 'bug327209' version '0.0.0'. [2010-10-11 15:54:23.910] http-8080-4 <DE0000I> Installing bundle 'BSNForBug327209' version '0.0.0'. [2010-10-11 15:54:23.924] http-8080-4 <DE0001I> Installed bundle 'BSNForBug327209' version '0.0.0'. [2010-10-11 15:54:23.933] http-8080-4 <DE0004I> Starting bundle 'BSNForBug327209' version '0.0.0'. [2010-10-11 15:54:23.942] start-signalling-4 <DE0005I> Started bundle 'BSNForBug327209' version '0.0.0'. I'm guessing that the input bundle specified: Bundle-ManifestVersion: 2 so I'll try this and see if the behaviour is different as the automatic upgrading logic on Virgo won't kick in in that case. Nope. This also worked as expected. Please can you attach both versions of your bundle to reproduce the problem? Note that although the manifest version upgrading logic would not kick in, we default the BSN anyway just to be kind. Also note that it is better to start Virgo with the -clean shell script option than manually modify the contents of the work directory as the latter can lead to unpredictable behaviour. Closing as not reproducible until such time as a testcase is available. Alex: if you wouldn't mind trying this again in the next day or two, I can look into the problem in this week's sprint if you manage to reproduce it and attach test bundles. Create an empty bundle as follows: echo "Bundle-symbolicname: test" > MANIFEST.MF jar cfm test.jar MANIFEST.MF Upload and see obvious failure echo "Bundle-SymbolicName: test" > MANIFEST.MF jar cfm test.jar MANIFEST.MF Upload and see less obvious failure Stop Restart Upload and see obvious failure Stop Restart -clean and upload works Thanks Alex. I'll try again to reproduce this. (I notice that you don't put Bundle-ManifestVersion:2 in there, so both are strictly-speaking OSGi R3 bundles.) The problem reproduced. :-) Virgo correctly upgrades the manifest of the first JAR deployed to R4 (which it requires as a minimum for various reasons) by adding a Bundle-ManifestVersion: 2 header. Then Virgo checks that Bundle-SymbolicName is present in order to provide a default if it is omitted. However, Virgo treats manifest headers as case-insensitive. This is correct. See for example [1] which clearly states: "Manifest header names are case-insensitive." So Virgo leaves the Bundle-symbolicname header intact and proceeds to install the bundle into Equinox. However, Equinox fails in StateBuilder.validateHeaders which throws a BundleException complaining, incorrectly, that the Bundle-SymbolicName header must be specified. (The logic calls Hashtable.get passing "Bundle-SymbolicName" which returns null since the hashtable key is "Bundle-symbolicname".) So the root cause of this bug appears to be in Equinox. The interface we are calling, StateObjectFactory.createBundleDescription(State, Dictionary, String, long) says in its javadoc: "The manifest should contain String keys and String values which correspond to proper OSGi manifest headers and values." which is the case here because manifest header names are case-insensitive. That said, there was a bug in Virgo in that the cleanup wasn't working properly for this path. I corrected this in kernel commit d221cd02e9ad0262433a4a7f1e956ca15a9dcbbb. Just running a full kernel build before pushing. With this in place, the second deploy works fine and there are no non-obvious failures. Let's use this bug for the Virgo fix since the title was about redeploying. I have raised bug 327885 against Equinox to investigate the other bug. [1] http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html#getHeaders() Pushed to 2.1.x and master branches. Yes, I was aware they were R3 :-) the cleanup was really the problem though. I wasn't too surprised that it failed, but when I couldn't redeploy the fixed version it was a concern :-) Thanks again for taking the trouble to raise this and provide the testcase! |
Build Identifier: Virgo 2.1.0M5 I installed a JAR which had a typo on Bundle-SymbolicName via Virgo. The exception message, whilst buried, gave the clue and I fixed the JAR (same name) and re-uploaded. However, the re-upload failed. It seems that the manifest (in deployer\staging\global\thebundle\theversion) still contained the old bundle manifest. Caused by: org.osgi.framework.BundleException: The "Bundle-SymbolicName" header must be specified at org.eclipse.osgi.internal.resolver.StateBuilder.validateHeaders(StateBuilder.java:200) at org.eclipse.osgi.internal.resolver.StateBuilder.createBundleDescription(StateBuilder.java :50) at org.eclipse.osgi.internal.resolver.StateObjectFactoryImpl.createBundleDescription(StateOb jectFactoryImpl.java:32) at org.eclipse.virgo.kernel.userregion.internal.quasi.StandardQuasiFramework.doInstall(Stand ardQuasiFramework.java:112) It seemed to do a refresh, rather than wiping hte Manifest and replacing it with the (fixed) good version. [2010-10-07 11:19:25.109] http-8080-5 <DE0003E> Install failed for bundle 'thebundle' version 'theversion'. [2010-10-07 11:44:16.406] http-8080-5 <DE0007I> Refreshing bundle 'thebundle' version 'theversion'. (obviously 'thebundle' and' theversion' have been changed here from valid name/numbers) Reproducible: Always Steps to Reproduce: 1. Create a bundle, but put a typo (or miss out) Bundle-SymbolicName 2. Attempt to upload, see failure 3. Fix bundle, attempt to re-upload 4. see same failure 5. stop virgo 6. wipe references in work\o.e.v.region.user\upload and work\o.e.v.kernel.deployer\staging\global\bundle 7. start virgo 8. upload same binary as in 3 and it now works