Bugzilla – Full Text Bug Listing
| Summary: | Old version of installed bundle gets loaded (was: LinkageError on TextEdit) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Yaroslav Bulatov <yaroslavvb> | ||||||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | daniel_megert, david_williams, jeffmcaffer, martinae, pombredanne, tjwatson, zhouyiy | ||||||||
| Version: | 3.3 | ||||||||||
| Target Milestone: | 3.2.2 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 181382 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Yaroslav Bulatov
Could you please provide a test case and the build id? Thanks. Build id: I20060810-1230
Test case:
Create new Java Project, create new class Test, type the following
public interface Test { }, go to Source/Format
Closing as dup of bug 155981. If you didn't install on top of an existing installation, please reopen. *** This bug has been marked as a duplicate of 155981 *** Hm, a duplicate, let's have a closer look: When you installed over the old version, did you extract the whole JAR or just a selection of plugins (e.g. on JDT)? Do you have other plugins installed? Do you still have the old install? Can start it again and attach here what you get from 'Help > About Eclipse SDK > Configuration Details'? I tried to reproduce and extracted 3.3 M1 over 3.2 and then I20060830-1650 over that. Created a file and did organize import or format but didn't see a problem. Me and Dani were wondering if it is possible that an older version of org.eclipse.text could be loaded. The configuration details show a strange state: all 3 instanceof of org.eclipse.text are markes as resolved, but non active. Jeff, do you have any idea what be the problem here? TestEdit didn't have any API change, but private methods got added. A subclass of TextEdits got a 'toString' added. Moving to core.runtime for comments *** Bug 155981 has been marked as a duplicate of this bug. *** > but non active
This might be because org.eclipse.text does not have an activator. However, I'd then expect two listed as 'installed' and one as 'resolved'.
See also bug 155981 for more information Created attachment 49476 [details] my configuration details My configuration details, but as mentioned, I couldn't reproduce this bug. But the scenario is the same as in bug 155981 I also tried this: 1. have R3.2 2. replace (i.e. delete old version) org.eclipse.text with latest 3.3 plug-in ==> no problems i.e. organize import and format work as expected. The following bundles: org.eclipse.jface (3.2.0.I20060605-1400) "JFace" [Resolved] org.eclipse.jface (3.3.0.I20060801-0800) "JFace" [Resolved] org.eclipse.jface (3.3.0.I20060829-0800) "JFace" [Resolved] org.eclipse.jface.databinding (1.0.0.I20060605-1400) "JFace Data Binding" [Resolved] org.eclipse.jface.databinding (1.0.100.I20060803-0010) "JFace Data Binding" [Resolved] org.eclipse.jface.databinding (1.0.100.I20060829-0800) "JFace Data Binding" [Resolved] org.eclipse.jface.text (3.2.0.v20060605-1400) "JFace Text" [Resolved] org.eclipse.jface.text (3.3.0.v20060809-1200) "JFace Text" [Resolved] org.eclipse.jface.text (3.3.0.v20060829-0800) "JFace Text" [Resolved] org.eclipse.text (3.2.0.v20060605-1400) "Text" [Resolved] org.eclipse.text (3.3.0.v20060809-1200) "Text" [Resolved] org.eclipse.text (3.3.0.v20060829-0800) "Text" [Resolved] Are not specified as singleton bundles. This allows more than one version to be resolved at the same time. Are there issues if multiple versions of jface and text are used in the same system? Should these bundles be specified as singleton bundles? >Are not specified as singleton bundles
Can't tell for sure but I think someone ones said this is only needed if there's an activator.
This is not really a reason to use singletons. Here are the most common reasons: - The bundle specifies extensions or extension points. The extension registry require these bundles to be singletons - The bundle uses a resource that cannot be shared between different versions of the bundle. SWT declares itself a singleton because it does not want to share the display with other versions of SWT. This does not really have anything to do with whether you have a bundle activator or not. Non-singleton bundles are allowed to have bundle activators. What I expect is happening here is that different bundles are getting wired to different versions of jface and when they attempt to pass objects between to two clients things start to break. Yes, I can also remember all those other arguments but they don't apply to org.eclipse.text i.e. I would still mark it as no-singleton when following those rules. Jeff, this sounds more serious to me. Might this be a 3.2.1 candidate? I'm increasing the severity of this one, because it affects all clients where new versions of a bundle get installed into the same location as existing ones.
I just run into a similar problem - no linkage error BUT it seems that Equinox loads classes from BOTH VERSIONS of the installed plug-ins. I have the following installed:
org.eclipse.jface.text_3.3.0.v20060926-0800.jar
Bundle-Version: 3.3.0.v20060926-0800
org.eclipse.jface.text_3.3.0.zzz20060927-1520.jar
Bundle-Version: 3.3.0.zzz20060927-1520
and both got RESOLVED. I would expect that only the newest gets resolved.
This happens because singleton:=true isn't specified which in my opinion should not cause the effect that an older bundle versions gets used.
If a bundle is not a singleton bundle then it is "by design" that each bundle is allowed to resolve. And both can be used by different clients. If you want to prevent that then you should specify them as singletons. (In reply to comment #16) > This happens because singleton:=true isn't specified which in my opinion should > not cause the effect that an older bundle versions gets used. > It is a key feature of OSGi to allow multiple versions of classes to be loaded if desired. This allows clients which require different versions of some class to run in the same framework. If you don't want to allow this for your bundle, either don't install multiple versions of the bundle, or have all the versions of the bundle marked as singletons. I see this but shouldn't it always take the "newest" one that matches the client's requirement? Why does it load two different versions if the newest works for both clients? Or in other words: what is the algorithm to decide which version of the plug-in to load? Is there any work around for this bug until a new release fixes. I am using eclipse and this bug in this last release is a major problem for using eclipse. What can I do? Nevermind, I figured out, I just delete my old org.eclipse.text_3.1.1.jar. Can an equinox runtime expert comment on comment 19 i.e. is it really the case that if more than one version of a (non-singleton) bundle meets the version requirement an arbitrary version is taken each time and that this process is not deterministic? (In reply to comment #19 and comment #20) It depends on a few things ... The framework does not agressively rewire previously resolved bundles to new bundles when they get installed. So if some clients are wired to the old version of your bundle and a new version of your bundle is installed along with a set of other bundles that use your new bundle then some of the bundles in the framework will be wired to your old version and other newly installed/resolved bundles will get wired to the new version of your bundle. The only way the bundles wired to your old bundle will get wired to the new bundle is by forcing them to refresh. Is there a reason both versions are installed? It seems like core.update should have uninstalled your old version so the other bundles are forced to re-resolve to use the newer version of your bundle. Is this really a valid configuration? If so then core.update needs to be smarter to make sure everyone starts using the highest versions possible. This would involve them selectively refreshing bundles wired to older versions of the bundle. But this lead me to ask ... why do you want older versions of your bunlde installed if you do not want anyone to actually be wired to them? Just to clarify: does your comment only apply to a single run or is there a cache and subsequent runs are affected as well? Or in other words: if the workbench is restarted then the problem is gone (or not)?
>The only way the
>bundles wired to your old bundle will get wired to the new bundle is by forcing
>them to refresh.
How can I do that?
I guess another thing we should do is mark the plug-ins as singletons, right?
(In reply to comment #24) > Just to clarify: does your comment only apply to a single run or is there a > cache and subsequent runs are affected as well? Or in other words: if the > workbench is restarted then the problem is gone (or not)? We cache the resolution state of the bundles so we do not have to reparse and reresolve the state of the bundle wirings each startup. This is a must when loading a configuration with potentially 1000s of bundles. The problem should go away if you run with -clean after installing the new versions of the bundle. This would force the newest possible bundles to be picked for each wiring. > >The only way the > >bundles wired to your old bundle will get wired to the new bundle is by forcing > >them to refresh. > How can I do that? This is something the management agent would need to do (core.update). Unfortunately I'm not sure there is a one size fits all policy for selecting what bundles need refreshed. Instead I would like to focus on whether this is a valid configuration. To me it seems like core.update should have noticed that the old bundles are not really needed anymore and probably should have uninstalled them from the configuration. > I guess another thing we should do is mark the plug-ins as singletons, right? That is one possibility, but we need to answer the question of whether it is valid to have more than one version of the library bundles installed at a time. If it is and you make them singleton then you will prevent more than one version from ever being used at the same time in a configuration. >If it is and you make them singleton then you will prevent more than one
>version from ever being used at the same time in a configuration.
Well, almost all source plug-ins in the Eclipse SDK are marked as singletons (according to Jeff at least those that populate the plug-in registry should be) hence making org.eclipse.text shouldn't change much, should it? Note that org.eclipse.text is a source plug-in and not encapsulating a library.
Thomas, can you or some other equinox runtime expert please comment on comment 26. Thanks. ping. I'm not sure what you mean by "source plug-in". Changing org.eclipse.text to a singleton bundle should not effect too much other than preventing other org.eclipse.text bundles which are *also* singleton bundles from resolving. >I'm not sure what you mean by "source plug-in".
I meant plug-ins that not only wrap some (external) library but is written by us (eclipse).
Unless we find a better resolution for this critical bug for 3.2.2 I'll add the singleton statement into those plug-ins that are under my control. Moving to update for comment. I do not understand why more than one version of org.eclipse.text are being installed in this case. I thought update would uninstall the old version of the bundles when a feature is updated. Can some on the update team comment on what scenarios cause more than one version of a bundle to be installed? *** Bug 169593 has been marked as a duplicate of this bug. *** Created attachment 56499 [details] 3.3 patch for the framework See Bug 169593 comment 1 option 3 This patch changes the framework to force all old bundles to be refreshed when newly installed versions (with the same symbolic name) are installed. Before we only did this for singleton bundles. This patch will do this for all bundles that are being refreshed by update.configurator when it installs new bundles. This will force the old bundles to be refreshed which will then make all bundles depending on the old bundles to be refreshed in a transitive closure graph. Then when the bundles are resolved we will resolve them to the highest possible version of the bundles. This should help solve the issue by allowing all bundles to use the same version of the installed bundle. This patch is for 3.3. I will attach a separate patch for 3.2.x stream if we feel this fix is necessary for 3.2.2. Created attachment 56500 [details]
3.2.x patch for the framework
same fix for 3.2.x.
+1 for 3.2.2. Just to clarify, this is a Framework change no? Is there an Update bug at all in any of this? if not, the bug should be moved. Also, please be sure that there is a 3.2.2 bug for this. Patch reviewed, good to go. Moving to Equinox since we decided to fix this in the Framework for 3.2.2. Patch released to 3.2.2 and HEAD. *** Bug 181382 has been marked as a duplicate of this bug. *** |