Bugzilla – Full Text Bug Listing
| Summary: | ClassCastException received when System.getProperties().store() runs on 4.4.1 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Hugo Herrera <jhugohr> | ||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aaron, aboyko, adietish, andrei.ilie, artur, a_mergey, bancharel.fabien, daniel_megert, david_williams, declan, dominik.stadler, garydgregory, glen.a.ritchie, gregory.amerson, ignacio, jarek.przygodzki, jed.anderson, Johannes.Ahlers, joseph.witthuhn, kdevolder, khiremandar, knst.kolinko, levon.sa, manderse, mark, markus.kell.r, martin.rust, mauromol, monsieurrigsby, radim.kubacki, rahul083, sciccarelli, snicolai, stumc68, thomas, tigerjack89, tim, tjwatson, udo.hafermann, vl65 | ||||
| Version: | 3.10.0 Luna | ||||||
| Target Milestone: | Luna SR2 | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 445963 | ||||||
| Attachments: |
|
||||||
|
Description
Hugo Herrera
Since org.eclipse.osgi.internal.framework.EquinoxConfiguration$ is an equinox framework object I am moving to Equinox. Note that this is also a cause of https://issuetracker.springsource.com/browse/STS-3922 - a serious problem breaking Gradle / Eclipse (or STS) integration. Is there a chance to bump the priority? Marking for Luna SR2. Will look to fix in M3 for Mars. org.eclipse.osgi.internal.framework.EquinoxConfiguration class has a NULL_CONFIG object added.
private final static Object NULL_CONFIG = new Object() {
public String toString() {
return "null"; //$NON-NLS-1$
}
};
This is not serializable.
Can't we simply remove the key from the configuration object (of type Properties) instead of setting the value to NULL_CONFIG?
(In reply to Alex Boyko from comment #4) > org.eclipse.osgi.internal.framework.EquinoxConfiguration class has a > NULL_CONFIG object added. > private final static Object NULL_CONFIG = new Object() { > public String toString() { > return "null"; //$NON-NLS-1$ > } > }; > > That is the root cause of this issue. > This is not serializable. Making it serializable is not going to fix this since Properties makes assumptions on values being String when doing a store() which cause the cast exception. > > Can't we simply remove the key from the configuration object (of type > Properties) instead of setting the value to NULL_CONFIG? Unfortunately no because in typical OSGi configurations the framework configuration is backed by the system properties. If we removed the key then the value of things like BundleContext.getProperty would fall back to values in the system properties. We needed a marker object in the configuration to know to not fall back to the system properties. This was to fix bug 441377. The framework configuration Map can contain null values which indicate that null must be used for the configuration property regardless of what is contained in the system properties. The issue with Eclipse is that we have, since Eclipse 3.0, used the system properties as THE framework configuration properties. There is a flag we use to tell Equinox to just use the system properties for the framework configuration. It is in this scenario where we will set the value to our marker object in the system properties. There are two ways I see fixing this. 1) Instead of using a marker object use a marker string set to some random value (for example, the framework-UUID + "-null-marker") which should have a low probability of being used as a configuration value. 2) Detect that the framework configuration properties are THE system properties, if so then simply remove the key instead of placing the marker object in the properties object. Fixed in master with: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=341891705cb0f38ea99706755e998f27853f183e Leaving open for SR2. Please test with the next I-Build (missed today's build) to make sure if fixes the issue in your scenario. It is great this will be fixed in nighly shortly but for people that use Eclipse 4.1.1 RELEASE we need a workaround. This bug breaks many things. These are just the ones that I know about (two of them are our stuff :-) - Groovy Eclipse (via dependency on Ivy) - Gradle Tooling in STS (via dependency on Gradle) - IvyDE Thomas, we've got a workaroung that seems to work for us, but we are wondering what you (or anyone else reading this), who are more expert on osgi/equinox, than us, think about this workaround? Workaround is, we put these p2.inf instructions into our 'broken' bundles: instructions.configure = \ addJvmArg(jvmArg:-Dosgi.configuration.area.default=null); \ addJvmArg(jvmArg:-Dosgi.user.area.default=null); \ addJvmArg(jvmArg:-Dosgi.user.area=@user.home); \ addJvmArg(jvmArg:-Dosgi.instance.area.default=null); instructions.unconfigure = \ removeJvmArg(jvmArg:-Dosgi.configuration.area.default=null); \ removeJvmArg(jvmArg:-Dosgi.user.area.default=null); \ removeJvmArg(jvmArg:-Dosgi.user.area=@user.home); \ removeJvmArg(jvmArg:-Dosgi.instance.area.default=null); The effect is that these lines are added to eclipse.ini when these bundle(s) get installed. -Dosgi.configuration.area.default=null -Dosgi.user.area.default=null -Dosgi.user.area=@user.home -Dosgi.instance.area.default=null The values we put in these props are based on what they used to be in Eclipse 4.4.0. This makes our problems with 'unserializable' or 'can not be cast to String' properties go away. Still we are a bit apprehensive whether this workaround may have unintended side effects (confuse equinox). Any thoughts on this workaround? Got a better idea? FYI: Found something else broken by this bug: java.lang.ClassCastException: org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String at org.eclipse.m2e.logback.configuration.LogHelper.logJavaProperties(LogHelper.java:26) at org.eclipse.m2e.logback.configuration.LogPlugin.loadConfiguration(LogPlugin.java:189) at org.eclipse.m2e.logback.configuration.LogPlugin.configureLogback(LogPlugin.java:144) at org.eclipse.m2e.logback.configuration.LogPlugin.access$2(LogPlugin.java:107) at org.eclipse.m2e.logback.configuration.LogPlugin$1.run(LogPlugin.java:62) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) Follow up on the workaround. Already we found out the suggested workaround is a bad idea. Adding the p2.inf makes it impossible to upgrade/uninstall bundles. Also while we probably want to set props to null (pointer) or remove them from the system properties, in actuallity it is setting them to 'null' (String). It isn't really possible to remove system properties via commandline argument as far as I know. So we need a different workaround. Created attachment 247605 [details]
Workaround system bundle fragment
Its a shame the trouble this has caused. I thought I had seen the trick of putting non-String values in the system properties before. I never would have anticipated so many folks iterating over the values of the props like this.
Here is a possible workaround. If you install this system bundle fragment with your bundles it should help clear out the non-String values from the system properties before anyone else gets to them.
Thanks for the workaround. We didn't end up using the bundle fragment, instead we just put a similar bit of code as contained in your fragment into one our own Bundle activator's start method. (In reply to Kris De Volder from comment #11) > Thanks for the workaround. We didn't end up using the bundle fragment, > instead we just put a similar bit of code as contained in your fragment into > one our own Bundle activator's start method. That is fine, but it has a drawback that you must ensure your bundle code with the workaround is executed before any other code in the system tries to read the system properties in such a way that is causing the cast exception. *** Bug 446161 has been marked as a duplicate of this bug. *** (In reply to Markus Keller from comment #13) > *** Bug 446161 has been marked as a duplicate of this bug. *** Add in Eclipse 4.4.1 pligin org.eclipse.equinox.workaround.nullproperties_1.0.0.201410030808.jar attachment in comment_10 Run as -> Eclipse Application no error "!MESSAGE Exception while setting up logging:org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String" in log-file But the example of plugin doesn't work Error in View IDE "console" - Error: Could not find or load main class Likhovskikh *** Bug 446173 has been marked as a duplicate of this bug. *** Is this issue not serious enough to consider doing an emergency hotfix release ? i.e. storing non-string objects into system properties might technically be possible but it is against the implicit API contract of System.get/set property only handles strings. Without a fix to SR1 it will be 3+ months before popular plugins will work on eclipse latest release. Same problem here, this is the output java.lang.ClassCastException: org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String at org.eclipse.m2e.logback.configuration.LogHelper.logJavaProperties(LogHelper.java:26) at org.eclipse.m2e.logback.configuration.LogPlugin.loadConfiguration(LogPlugin.java:189) at org.eclipse.m2e.logback.configuration.LogPlugin.configureLogback(LogPlugin.java:144) at org.eclipse.m2e.logback.configuration.LogPlugin.access$2(LogPlugin.java:107) at org.eclipse.m2e.logback.configuration.LogPlugin$1.run(LogPlugin.java:62) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) I agree with Max this bug is really quite serious in how broadly it affects many potential things. A 'hotfix' release seems like a good idea. If that seems too radical... A somewhat less drastic solution, the bundle-fragment workaround that Thomas attached in this bug might be enough *if* it was made easy enough to install (i.e. provided via some update site a user can easily install from rather than a bundle jar that most people probably don't know what to do with. Even so, assuming there's a update site, a lot of people are likely to be inconvenienced. They will have to find this bug report, the update site, and install the fix. (In reply to Thomas Watson from comment #6) > Fixed in master with: [..] This fix still keeps the dangerous "NULL_CONFIG = new Object() {..}". While the fix looks OK, a safer solution that doesn't use this strongly discouraged hack would be to just create a new private String object and compare it with == where necessary. That ensures you never have a problem with real configuration values. E.g.: /** * Value of {@link #configuration} properties that should be considered * <code>null</code> and should not fall back to * {@link System#getProperty(String)}. */ private final static String NULLED_PROPERTY = new String("nulled property"); //$NON-NLS-1$ ... public String getConfiguration(String key) { String property = configuration.getProperty(key); return property != NULLED_PROPERTY ? property : null; } (In reply to Markus Keller from comment #20) > (In reply to Thomas Watson from comment #6) > > Fixed in master with: [..] > > This fix still keeps the dangerous "NULL_CONFIG = new Object() {..}". While > the fix looks OK, a safer solution that doesn't use this strongly > discouraged hack would be to just create a new private String object and > compare it with == where necessary. That ensures you never have a problem > with real configuration values. > > E.g.: > /** > * Value of {@link #configuration} properties that should be considered > * <code>null</code> and should not fall back to > * {@link System#getProperty(String)}. > */ > private final static String NULLED_PROPERTY = > new String("nulled property"); //$NON-NLS-1$ > ... > public String getConfiguration(String key) { > String property = configuration.getProperty(key); > return property != NULLED_PROPERTY ? property : null; > } I had thought of doing that but was concerned about the interning behavior of string constants. Perhaps someone would use the same value as us for the value. I guess if we used something obscure enough that would not be a big concern. FWIW I released the fix from master to the R4_4_maintenance branch with: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=5e48a84c3ab338b20065173e4a572e34a427642b I will look at using Markus's suggestion for improving this fix for both Mars and Luna SR2. (In reply to Thomas Watson from comment #21) > I had thought of doing that but was concerned about the interning behavior > of string constants. Perhaps someone would use the same value as us for the > value. No, that can't possibly happen if you use the new String("...") constructor and don't call String#intern() on the constant yourself. Since you don't hand out the constant to anybody, you can be sure you're the only one who can have a reference to that object. Only the Properties class of the EquinoxConfiguration#configuration field could theoretically play games, but it doesn't. And also in the future, it's less likely to use #intern() than to cause problems with discouraged non-String values. "hello".equals(new String("hello")) is true, but the JLS guarantees that "hello" == new String("hello") is false, so any value (including "" or "null") is safe if you don't use the String literal but the String(String) constructor. BTW: Bug 441377 was actually not a bug but an enhancement request (without an actual use case). I don't see any documentation on FrameworkFactory#newFramework(Map<String, String>) nor on EnvironmentInfo#setProperty(String, String) that would allow null values. Only EclipseStarter#setInitialProperties(Map<String, String>) seems to allow them. An even simpler solution: Change EquinoxConfiguration#configuration to HashMap, just use null for null values, and synchronize access manually. (In reply to Markus Keller from comment #23) > (In reply to Thomas Watson from comment #21) > > I had thought of doing that but was concerned about the interning behavior > > of string constants. Perhaps someone would use the same value as us for the > > value. > > No, that can't possibly happen if you use the new String("...") constructor > and don't call String#intern() on the constant yourself. Since you don't > hand out the constant to anybody, you can be sure you're the only one who > can have a reference to that object. Only the Properties class of the > EquinoxConfiguration#configuration field could theoretically play games, but > it doesn't. And also in the future, it's less likely to use #intern() than > to cause problems with discouraged non-String values. > > "hello".equals(new String("hello")) is true, but the JLS guarantees that > "hello" == new String("hello") is false, so any value (including "" or > "null") is safe if you don't use the String literal but the String(String) > constructor. Understood. Thanks Markus! > > BTW: Bug 441377 was actually not a bug but an enhancement request (without > an actual use case). It was a regression in behavior from previous releases > I don't see any documentation on > FrameworkFactory#newFramework(Map<String, String>) nor on > EnvironmentInfo#setProperty(String, String) that would allow null values. > Only EclipseStarter#setInitialProperties(Map<String, String>) seems to allow > them. I don't see where it disallows them either, but there are real usecases for the null value. It involves embedding cases where you have to protect the embedded configuration from system properties controlled by an outside container. This would be something like WebSphere (built on Equinox) running a WAR with Equionox embedded (e.g. using the servlet bridge: orion, Jazz, etc.). > > An even simpler solution: Change EquinoxConfiguration#configuration to > HashMap, just use null for null values, and synchronize access manually. I agree, except for the fact that Eclipse configuration historically was based on system properties. Unfortunately when using the eclipse launcher we need to default to using the system Properties object to back our configuration. Here is a review for using Markus's suggestion for an internal String: https://git.eclipse.org/r/34947 (In reply to Markus Keller from comment #20) An idea for an alternative safe solution: Instead of using a sentinel value such as NULL_CONFIG, add a Set<String> field to keep track of null-valued keys. Essentially, looking at issue 441377 fix [1] the idea is to replace "!this.configuration.containsKey(key)" lookup with looking into this new Set<String>. [1] http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=6518be6daad51538b7124f49a889a4a762b63a07 Confirming for Linux 64 bit. On startup, eclipse 4.4.1 throws the string-casting backtrace and basic things simply don't work (eg clicking "Window > Preferences > Install/Update > Automatic Update" crashes Eclipse, everytime). This release is unusable, had to switch back to 4.3.2. (In reply to Andrei ILIE from comment #27) > Confirming for Linux 64 bit. On startup, eclipse 4.4.1 throws the > string-casting backtrace and basic things simply don't work (eg clicking > "Window > Preferences > Install/Update > Automatic Update" crashes Eclipse, > everytime). I'm unsure how that crash is related to this bug. I think you should open a separate bug if automatic updates are crashing all of eclipse. > > This release is unusable, had to switch back to 4.3.2. Revised fix in Master with: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=38ccd9f806fec0b030e60eb774601576299b9899 In Luna with: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=e14bec5a26b2ddfc54346190328a6acc738c720c We will also be working on a patch fix for Luna SR1 Are there any p2 repository with this fix available ? otherwise Luna SR1 is probably completely useless I agree this is bad bug but lets please be precise in stating where it is not working. For now this issue *only* affects plugins that are trying to iterate/save *all* system properties without checking for null. So far I've only heard about the Groovy and Gradle plugin having this issue. That is in itself a problem but it does not make SR1 completely useless. If there are other plugins affected by it, it would be great to know. And yes, I'm very much for we get an update up available asap - knowing who/what is affected by it will help expedite it. I can confirm IvyDE is affected too - that is why I'm watching this issue. I think severity of this bug is underestimated As this bug is occurring in equinox itself, not only Eclipse is impacted, but potentially also all runtime or server side application running on equinox Any osgi application that is using a third party bundle iterating over the values of the properties can suffer of this For example pax-logging-service a quite often used bundle in osgi world is impacted. So maybe it does not make SR1 completely useless for Eclipse IDE, but for equinox it probably does (In reply to Arnaud MERGEY from comment #33) > I think severity of this bug is underestimated > > As this bug is occurring in equinox itself, not only Eclipse is impacted, > but potentially also all runtime or server side application running on > equinox > > Any osgi application that is using a third party bundle iterating over the > values of the properties can suffer of this > > For example pax-logging-service a quite often used bundle in osgi world is > impacted. > > So maybe it does not make SR1 completely useless for Eclipse IDE, but for > equinox it probably does Can folks on the bug state what the impact is. Useless to me indicates that the application is non-functional or does not launch or crashes and exits. Some exception during logging does not seem like it should cause immediate failure and crash. I'm not saying this is not a horrible issue, it is, but I want to understand how it is effecting the overall stability of an application running on Equinox. All that being said, we are working on a patch feature repository to patch SR1 until SR2 becomes available. In the meantime if you want to test the fix please do so with the latest M-Build: http://download.eclipse.org/eclipse/downloads/drops4/M20141022-0800/ You could try to do an update using our M-Build repo: http://download.eclipse.org/eclipse/updates/4.4-M-builds But we are still working out the feature version increases in the branch so it may not update cleanly. If you use the IvyDE plug-in, the impact is that this version of Eclipse is completely unusable for development. Project teams where I work are being instructed not to use this release. I can only speak to the impact on IvyDE though. (In reply to Joseph Witthuhn from comment #35) > If you use the IvyDE plug-in, the impact is that this version of Eclipse is > completely unusable for development. Project teams where I work are being > instructed not to use this release. > > I can only speak to the impact on IvyDE though. That means the IveDE crashes and exits or is non-functional I assume? IvyDE in combination with this bug has a real weird influence on Eclipse. Menu points of the context menu randomly disappear if you rightclick Ivy-Projects. Also Ant-Builds with Ivy do not work. There is a new (developer) version of Ivy that works with 4.4.1 version of Eclipse. See https://issues.apache.org/jira/browse/IVY-1487 for more information. All Buckminster builds crashes immediately due to this bug (this bug blocks bug 445963 and duplicate reports has started to come in). Thanks for the concrete issues listed. Keep them coming. They all help. I see this same problem when using the Gradle integration in Eclipse (on OSX). It happens when I choose "Build model" in the import dialog. Is there a way I can install a patch/upgrade? (In reply to Levon Saldamli from comment #40) > I see this same problem when using the Gradle integration in Eclipse (on > OSX). It happens when I choose "Build model" in the import dialog. Is there > a way I can install a patch/upgrade? Try updating your Gradle Eclipse Integration plugin to the 3.6.2 version from this update site: http://dist.springsource.com/release/TOOLS/update/e4.4/ A workaround for this Eclipse issue has been added to the Gradle Eclipse plugin for the 3.6.2 release. We have created a feature patch for this problem, for 4.1.1 release. Currently it is in a temporary location, for testing only, but would like to get "community confirmation" that it fixes the original problems, before putting it in our "real" 4.4 repo, on downloads. I put the "temp test" repository on build machine ... it is a composite, and should look just like it will look once we but the patch in "the real" repository: http://build.eclipse.org/eclipse/updates/4.4/ (This repo is temporary, and will be removed, shortly after we move it to downloads -- do, don't publish this to 100s of users saying it is where to get the fix :) It did pass my meager testing: Tested if it will install into "mars" (it successfully did not). Tested if it will install into "4.4.1 SDK" (it successfully did). Tested if it will install into "4.4.1 Platform (only)" (it successfully did). Tested if it will install into "4.4.1 JEE package)" (it successfully did). Tested it can be un-installed, once installed, (using JEE). (It successfully could). In all cases, there was no "automatic update" (not surprisingly) but had to "install new software". In all these cases, only the "E4 RCP Patch" applied ... not the other three (again, not surprising, for IDE -- the others being more relevant to "server only" or "p2 director" only type of installs). In no case did I actually test if it solved the original problem ... I was just testing that the "site worked". If those of you having problems, can apply the feature patch appropriate for what you need, and confirm here explicitly that it solves your original problem, then we can update the "real" repository on downloads server. Note: we have noted a few minor issues that I don't think should hold things up ... we'll just have to fix if/when there is ever a second patch, such as that the patch features have no qualifier (just "1.0.0"). Thanks for your prompt help. (In reply to David Williams from comment #42) Thanks, that solved the issue of the blank menu items that I was having when right clicking on an IvyDE project, similar to what Wolfgang mentioned in comment 37. (In reply to David Williams from comment #42) With the patch, some error disappear in ".log" file, like this one : Exception while setting up logging:org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String java.lang.ClassCastException: org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String at org.eclipse.m2e.logback.configuration.LogHelper.logJavaProperties(LogHelper.java:26) And m2e seems to be less verbose in ".log" file. With Spring Tools 3.6.1, I now see some new NullPointerException in ".log" like : Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". !STACK 0 java.lang.IllegalArgumentException: null source at java.util.EventObject.<init>(EventObject.java:56) at org.springframework.ide.eclipse.core.model.ModelChangeEvent.<init>(ModelChangeEvent.java:43) I will try to update to Spring Tools 3.6.2, since it is based on Luna SR1. (In reply to Fabien Bancharel from comment #44) > (In reply to David Williams from comment #42) > > With the patch, some error disappear in ".log" file, like this one : > > Exception while setting up > logging:org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be > cast to java.lang.String > > java.lang.ClassCastException: > org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to > java.lang.String at > org.eclipse.m2e.logback.configuration.LogHelper.logJavaProperties(LogHelper. > java:26) > > And m2e seems to be less verbose in ".log" file. Thanks for reporting back. > > > With Spring Tools 3.6.1, I now see some new NullPointerException in ".log" > like : > Problems occurred when invoking code from plug-in: > "org.eclipse.core.resources". > !STACK 0 > java.lang.IllegalArgumentException: null source > at java.util.EventObject.<init>(EventObject.java:56) > at > org.springframework.ide.eclipse.core.model.ModelChangeEvent. > <init>(ModelChangeEvent.java:43) > > I will try to update to Spring Tools 3.6.2, since it is based on Luna SR1. This issue does not look to be related to this bug report. I'm not sure what the source is supposed to be for their ModelChangeEvent, but I have doubts it is related to the configuration properties of Equinox. The E4 RCP Patch (bugzillas 445122) resolves issues with IvyDE 2.2.0 not resolving dependencies and failing builds. (In reply to David Williams from comment #42) > We have created a feature patch for this problem, for 4.1.1 release. {...} > If those of you having problems, can apply the feature patch appropriate for > what you need, and confirm here explicitly that it solves your original > problem, then we can update the "real" repository on downloads server. The "E4 RCP Patch" works: ivy/maven/team contextual menus reappeared. Tnx :) (In reply to Thomas Watson from comment #45) Regarding the error log I had reported about org.springframework.ide, after applying the RCP patch : - it happened only once - it did not happened since, both with Spring STS 3.6.1 and after upgrading to 3.6.2 So yes, it is reasonable to think it was not related to the RCP patch. Buckminster has confirmed the fix (in bug 445963) and while I have not kept a careful tabulation ... I think that's confirmation from all the primary cases? I will plan on "rolling out" the patched feature to the primary update site this afternoon (Friday, October 31) -- unless I hear differently. (In reply to David Williams from comment #49) > Buckminster has confirmed the fix (in bug 445963) and while I have not kept > a careful tabulation ... I think that's confirmation from all the primary > cases? > > I will plan on "rolling out" the patched feature to the primary update site > this afternoon (Friday, October 31) -- unless I hear differently. +1 Yes please do. Thanks all for confirming the fix. Thanks David for promoting the patch feature. The patch is now available from the normal 4.4 update site: http://download.eclipse.org/eclipse/updates/4.4/ Note that in no cases (that I know of) will the "check for updates" find this patch, (due to the nature of "root features", etc.) but it should be installable into any project or EPP package that is based on Eclipse Platform 4.4.1. The majority of users simply need to use "Install new software" and pick the category named Eclipse 4.4.1 patches for bug 445122 p2 will automatically pick the the relevant "feature patch", which for nearly all users will be named E4 RCP Patch (bugzilla 445122) (There are 3 other "feature patches", which are normally not relevant, but might be for "server products" and similar). For some products, say if they are "built from bundles only" ... and not features ... they may need to build using the new bundle that has been fixed, by specifying it's IU directly, which has Id equal to org.eclipse.osgi and a version of 3.10.2.v20141020-1740 (The version that shipped with Eclipse 4.4.1 was 3.10.1.x). Thanks to all for reporting the issue, making suggestions to fix, and verifying the fix and temporary patch repo. [Speaking of which, I will remove the temporary repo on Monday, 11/3, around noon Eastern time ... in case anyone is using it for builds, or something, you will need to migrate to the permanent repo.] Thanks again, BTW, I wanted to publically thank, by name, Steve Francisco, who is the one that created these "feature patches" for us. (I think the bundle simply came from an early "M-build" for Luna SR2, where the fix was the only change made.) Also, I opened bug 449509 as a reminder of some things to do differently next time -- if there is a next time! :/ Thanks again, Steve. *** Bug 446659 has been marked as a duplicate of this bug. *** The fix doesn't seem to work for me (Luna SR 1a on Ubuntu 12.04 x64). I can install the E4 RCP Patch but the m2e Logback errors remain at startup (I don't use Gradle or Ivy): org.eclipse.m2e.logback.configuration: The org.eclipse.m2e.logback.configuration bundle was activated before the state location was initialized. Will retry after the state location is initialized. org.eclipse.m2e.logback.configuration: Logback config file: /home/rigsby/Working/EclipseWorkspace/.metadata/.plugins/org.eclipse.m2e.logback.configuration/logback.1.5.0.20140606-0033.xml org.eclipse.m2e.logback.configuration: Initializing logback java.lang.ClassCastException: org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String at org.eclipse.m2e.logback.configuration.LogHelper.logJavaProperties(LogHelper.java:26) at org.eclipse.m2e.logback.configuration.LogPlugin.loadConfiguration(LogPlugin.java:189) at org.eclipse.m2e.logback.configuration.LogPlugin.configureLogback(LogPlugin.java:144) at org.eclipse.m2e.logback.configuration.LogPlugin.access$2(LogPlugin.java:107) at org.eclipse.m2e.logback.configuration.LogPlugin$1.run(LogPlugin.java:62) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) This doesn't *seem* to influence anything I'm using in Eclipse (maybe it's just Eclipse's internal logging that is affected?); can anyone confirm the impact and whether these msgs still occur after applying the patch? It may be a coincidence or as intended(?!) for my configuration, but I also now have errors trying to install anything else from that 4.4 Updates site talking about being unable to "acquire the framework manipulator service". An error occurred while installing the items session context was:(profile=epp.package.java, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]org.eclipse.cvs.source.feature.jar 1.4.100.v20140925-0400, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallFeatureAction). Could not acquire the framework manipulator service. Could not acquire the framework manipulator service. Hi, I am using eclipse in Centos 5.4. I got following exception when i start eclipse Luna. If it is RESOLVED FIXED then how i can get this exception? at which location i should keep 'org.eclipse.equinox.workaround.nullproperties_1.0.0.201410030808.jar'?' I paste here what i got in .log file! !SESSION 2015-02-24 15:19:51.227 ----------------------------------------------- eclipse.buildId=4.4.1.M20140925-0400 java.version=1.7.0_65 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.epp.package.java.product Command-line arguments: -os linux -ws gtk -arch x86 -product org.eclipse.epp.package.java.product !ENTRY org.eclipse.m2e.logback.configuration 2 0 2015-02-24 15:19:54.590 !MESSAGE Exception while setting up logging:org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String !STACK 0 java.lang.ClassCastException: org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String at org.eclipse.m2e.logback.configuration.LogHelper.logJavaProperties(LogHelper.java:26) at org.eclipse.m2e.logback.configuration.LogPlugin.loadConfiguration(LogPlugin.java:189) at org.eclipse.m2e.logback.configuration.LogPlugin.configureLogback(LogPlugin.java:144) at org.eclipse.m2e.logback.configuration.LogPlugin.access$2(LogPlugin.java:107) at org.eclipse.m2e.logback.configuration.LogPlugin$1.run(LogPlugin.java:62) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) (In reply to Mandar Khire from comment #55) > Hi, > I am using eclipse in Centos 5.4. I got following exception when i start > eclipse Luna. > If it is RESOLVED FIXED then how i can get this exception? > at which location i should keep > 'org.eclipse.equinox.workaround.nullproperties_1.0.0.201410030808.jar'?' > I paste here what i got in .log file! > > !SESSION 2015-02-24 15:19:51.227 > ----------------------------------------------- > eclipse.buildId=4.4.1.M20140925-0400 This is fixed in 4.4.2 (Luna SR2). This version has not been officially released yet. You can find the latest release candidates at http://www.eclipse.org/downloads/index-developer.php?release=luna The stacktrace you provided is from an old version of 4.4.1 which has the bug. I can confirm that upgrading to Luna SR2 seems to have fixed the problem for me, though I still don't understand why the E4 RCP Patch (bugzilla 445122) didn't fix it (i.e., it would appear that that is not quite the same fix as in Luna SR2, though nothing in this bug report I can see talks about this). (In reply to Stuart Rossiter from comment #57) > I can confirm that upgrading to Luna SR2 seems to have fixed the problem for > me, though I still don't understand why the E4 RCP Patch (bugzilla 445122) > didn't fix it (i.e., it would appear that that is not quite the same fix as > in Luna SR2, though nothing in this bug report I can see talks about this). Thanks for confirming. Maybe the patch only worked on the original Luna SR1, but it didn't work on SR1a (with the JGit fix) -- i.e. although it was installed, it maybe didn't get activated since there were newer versions of the features that it wanted to patch. (In reply to Markus Keller from comment #58) > ... Maybe the patch only worked on the original Luna SR1, > but it didn't work on SR1a (with the JGit fix) -- i.e. although it was > installed, it maybe didn't get activated since there were newer versions of > the features that it wanted to patch. Normally, I'd agree, but looked closely to "confirm" this was the case, but, what I found was that "the patch" was for following four features (specific to the specific versions of the features): <import feature="org.eclipse.e4.rcp" version="1.3.100.v20140909-1633" <import feature="org.eclipse.equinox.core.feature" version="1.2.0.v20140909-1633" patch="true"/> <import feature="org.eclipse.equinox.core.sdk" version="3.10.0.v20140909-1633" patch="true"/> <import feature="org.eclipse.equinox.server.core" version="1.3.0.v20140909-1633" patch="true"/> But, seems to me these same features are in both SR1 and SR1a: org.eclipse.e4.rcp_1.3.100.v20140909-1633.jar org.eclipse.equinox.core.feature_1.2.0.v20140909-1633.jar org.eclipse.equinox.core.sdk_3.10.0.v20140909-1633.jar org.eclipse.equinox.server.core_1.3.0.v20140909-1633.jar So, I don't know if you have enough "record" of what you did have installed, but would be interesting to know if you had some other version of these features installed when the "patch didn't work" (for example, would you have upgraded to some "M-build", after SR1? If so, that would explain it. If not (i.e. you had same features installed when "the patch didn't work", then it's something more subtle, that would be interesting to understand. Though, obviously, you are all set and running now, so is sort of "academic", but ... might be important for us to understand for the future? > So, I don't know if you have enough "record" of what you did have installed,
> but would be interesting to know if you had some other version of these
> features installed when the "patch didn't work" (for example, would you have
> upgraded to some "M-build", after SR1?
I double-checked. It was an absolute vanilla SR1a installation:
Version: Luna Service Release 1a (4.4.1)
Build id: 20150109-0600
As I said in my first comment though, I get the error at startup with no visible effect on the vanilla Eclipse functionality (or at least basic Java development stuff). Not sure if this is a slightly different variant of the problem, though SR2 fixing it would suggest that it's the same root cause...
Environment info that might be of interest was that it was on Ubuntu 12.04 x64 with Oracle Java 8 installed (1.8.0_40 when I retested).
*** Bug 463440 has been marked as a duplicate of this bug. *** |