Community
Participate
Working Groups
There's an interesting case coming up in Europa M4 that's kind of interesting. It may not occur in a pure update scenerio, so for now, I'll just describe what we are seeing. I'm initially opening this on "update", but could imagine the problem is elsewhere. To test our M4 version of WTP, we start off, for now, with downloaded versions of all pre-req zips ... platform, gef, emf, and DTP ... this latter zip includes a xerces plugin with following version ... org.apache.xerces_2.8.0.v200606131651 Now, we update for WTP, which installs following version, as it should. org.apache.xerces_2.8.0.v200612131415 But, upon the usual restart-after-update, we start getting weird class cast exceptions and others. So, the bug being, if you restart eclipse with -clean, it then works fine. I would have thought the update-restart cycle would do the equivalent of -clean?
This is very similar to bug 155996. I recommend we dup it. Can someone on the update team please outline the policy used when new versions of bundles are detected. In this bug and in bug 155996 it looks like update is detecting new versions of a bundle (xerces in this case) and installing it but it is not uninstalling the old bundle. Does update ever uninstall old versions of bundles. If so when? The issue here is we end up with more than one version of xerces RESOLVED in the system. Bundles that are already RESOLVED are not forced to resolve to the new version of xerces, but newly installed bundles are allowed to resolve to the new version of xerces. This can lead to inconsistent class spaces which will cause ClassCastExceptions. There are a few options we should consider to address this issue: 1) Add the "uses" directive to all Export-Package statements in all eclipse bundles. This will be next to impossible without tooling, see bug 167968. But with the uses directive the framework can ensure that bundles are using the same packages when they interact with eachother. One downside to this is that it will force bundles to resolve to older versions of xerces because others are using it already. 2) Investigate the policies used by update when new versions of bundles are installed. Should update uninstall the old versions of the bundles? 3) Force old bundles to be refreshed when new ones are installed. When update installs bundles it eventually calls PackageAdmin.refreshPackages. Currently it passes all the bundles it has installed and uninstalled (note that the old version of xercies did *not* get uninstalled). The framework currently is doing some special case processing for singleton bundles passed to refreshPackages (see bug 62260). This forces the old versions of the singleton bundles to be refreshed when new singleton bundles are installed. Maybe we should consider doing this for all bundles, not just singleton bundles. So, when a new version of xerces is installed we would force the old version of xerces to be refreshed. This would force all bundles depending on the old version to be re-resolved to the newest possible version. For the short term option 3 seem the most appealing to me. But I'm not sure where the processing should go. Currently the Framework does extra processing to refresh old versions of singleton bundles. We could easily update this code to handle all bundles (not just singletons). But this hardcodes the policy into the framework. Another option is to add the processing to update.configurator since it is the one calling PackageAdmin.refreshPackages. The downside here is that it only fixes the cases where update is used, other management agents may have a similar issue. Thoughts? P.S. For the long term we really need to add the "uses" directive to our exports, but that does not solve all of our problems.
Dup to bug 155996. I will attach a patch to bug 155996 for a possible framework fix discussed in option 2 of Bug 169593 comment 1. *** This bug has been marked as a duplicate of bug 155996 ***
