Bugzilla – Full Text Bug Listing
| Summary: | [nls tooling] Hover NLS message declaration displays message from bad message bundle. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Kamil Fejfar <comediant> | ||||
| Component: | Text | Assignee: | Deepak Azad <deepakazad> | ||||
| Status: | RESOLVED INVALID | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P5 | CC: | daniel_megert, deepakazad | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Can you please attach a test case? 1. Create two plugins A, B.
2. In these plugins create packages with the same name (cz.x).
3. In these packages create message bundles with the same bundle name (cz.x.messages).
plugin A
--------
public class AMessages extends NLS {
static {
// initialize resource bundle
NLS.initializeMessages("cz.x.messages", AMessages.class);
}
private AMessages() {
}
public static String a;
}
define appropriate message.properties
plugin B
--------
public class BMessages extends NLS {
static {
// initialize resource bundle
NLS.initializeMessages("cz.x.messages", BMessages.class);
}
private BMessages() {
}
public static String b;
}
define appropriate message.properties
4. Plugin B should depend on plugin A
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
<classpathentry kind="src" path="src"/>
<classpathentry kind="output" path="bin"/>
</classpath>
Important: classpathentry "org.eclipse.pde.core.requiredPlugins" must precede classpathentry "src"
5. Hover BMessages.b, it will return "The key is missing" because it will search b message in AMessages.
Created attachment 176454 [details]
Two project where you can reproduce this bug.
I have created two simple projects. Put these projects to your workspace, hover messageB in BMessages.java. You will get result from AMessages (bug).
The hover indeed shows the wrong message. I will take a look. At runtime the properties files are loaded by the classloader of the Accessor class. Now each plugin has its own classloader which means that both the properties file and the Accessor class have to be in the same plugin. However for plain Java projects this is not true, the Accessor class can be one project and the properties file can be in another project - as long as the classloader is same, things will work just fine at runtime. (In short, if the projects you created were plain Java projects then the hover behavior is correct.) In JDT we dont know if the project is a plugin project or a plain java project. Hence I do not have an easy solution in mind. (Plus the situation you describe looks kind of rare to me) This works as expected. The Java build (& class) path order is respected and because the PDE container comes before the source, it first resolves x.message from A. |
Build Identifier: M20100211-1343 If I have two (or more) message bundles with same name in different plugins it may cause problem. Initializing works fine: NLS.initializeMessages("cz.x.messages", AMessages.class) in plugin A NLS.initializeMessages("cz.x.messages", BMessages.class) in plugin B But when I hover some messge from BMessages (plugin B) and plugin A is in class path defined before plugin B, then org.eclipse.jdt.internal.corext.refactoring.nls.NLSHintHelper.getResourceBundle(IJavaProject, String, String) returns messages bundle from plugin A (it returns the first messages bundle no mather where it is defined). Reproducible: Always Steps to Reproduce: Look details.