For help with installation, bugs reports or feature requests, please head over to our new forums.
Genuitec Community on GitHub
- This topic has 16 replies, 5 voices, and was last updated 18 years, 6 months ago by
.
-
Posts
-
I’m getting warnings in my JSF files wherever I use keys from a loaded bundle. The warning is that the variable I used to access the bundle through JSF EL cannot be resolved.
E.g.
<f:loadBundle basename="#{bundleCtrl.bundle" var="msg" /> <h:outputText value="#{msg['some.key']" />In this case I would get the warning: msg cannot be resolved.
Of course this is not true, msg can certainly be resolved since the page runs perfectly.
My config is:
Windows XP SP2, Java 1.5.0 U6, Eclipse 3.2.0, MyEclipse 5.0.1, Tomcat 5.5.17henk,
While your notation might be valid, the notation the edtior is expecting is something along the lines of:<h:outputLabel value="#{msg.key}" />And the cool part is that it will even give you autocomplete for the .key part.
@support-rkalla wrote:
henk,
While your notation might be valid, the notation the edtior is expecting is something along the lines of:<h:outputLabel value="#{msg.key}" />This is the same problem I’m having. I’m not sure why any editor would make assumptions about how a variable is used. In the EL resolvers there is normally a strong distinction between resolving the variable itself (msg in this case) and applying an operation to it ( processing ‘key’ in this case).
If only the dot operator would be handled by the editor, then this surely would pose a problem to me. All our keys contains dots! This was done since editors such as resource bundle editor arranges keys in a hierarchical fasion, where the hierarchy tree branches at each dot found in a key.
Of course, “key.part1.part2” is not a valid right side argument for the dot operator in JSF EL. So, #{msg.key.part1.part2} would not work at all. This is the main reason why the [] operator was introduced into EL. Contrary to Java, its semantics in EL are identical to the dot operator, but it allows names with a dot into them.
And the cool part is that it will even give you autocomplete for the .key part.
Are you sure?
If the .key part doesn’t map to a getKey() method but resolves to a get(“key”) since msg was a Map, can the editor then still do autocomplete? It looks like this would be quite difficult to get right in a general situation. The editor would have to instantiate the Map and ask it about its keys. However, keys may be inserted at runtime or the map could be a custom type with special behaviour in its get method, etc etc.
@support-rkalla wrote:
henk,
While your notation might be valid, the notation the edtior is expecting is something along the lines of:<h:outputLabel value="#{msg.key}" />And the cool part is that it will even give you autocomplete for the .key part.
I tried your suggestion, but it didn’t work. In a way this was to be expected perhaps. The editor complains about not finding ‘msg’. If the [] notation was the problem, it probably would have complained about some invalid syntax, or perhaps about not finding “msg[key]”. Instead, it specifically complains about “msg”, so the [] syntax is recognized, but it just can’t find “msg”.
If I use #{msg.key}, I get the exact same warning. Therefore, the problem must be in the loadBunle tag. My guess is that the the editor just doesn’t know loadBundle introduces an EL variable to the scope. Could you verify this problem?
I did some more digging this morning and your original notation of msg[‘somekey’] is infact the preferred notation because of dot notations many people use in their properties. I filed this as a bug against the editor, I’m sorry for the inconvenience.
@support-rkalla wrote:
I did some more digging this morning and your original notation of msg[‘somekey’] is infact the preferred notation because of dot notations many people use in their properties. I filed this as a bug against the editor, I’m sorry for the inconvenience.
Well, it’s not such a big deal. As a programmer myself I often create this kind of little ‘inconveniences’ myself.
Nevertheless, I’m not sure how it’s possible that the dot notation seems to work with you, but doesn’t work with me either.
What I’m using now is:
<f:view locale="#{localeCtrl.loc}"> <f:loadBundle basename="#{bundleCtrl.bundle}" var="msg" /> <h:outputText value="#{msg.key}" />But I’m still getting the dreaded “msg cannot be resolved”. Since you said the editor should be able to auto-complete keys from the bundle, I thought it maybe fumbled with the basename (since it’s set programmatically instead of statically). So I also tried setting the basename directly:
<f:view locale="#{localeCtrl.loc}"> <f:loadBundle basename="com.mycompany.test.testbundle" var="msg" /> <h:outputText value="#{msg.key" />But this didn’t help; same message (and no auto-completion).
EL validation in general does work. The EL expression “#{localeCtrl.loc}” in the fragment above doesn’t give a warning. If I change the propery into a non existing one, e.g. “#{localeCtrl.locblabla}”, then the editor (correctly) flags this as “locblabla cannot be resolved as a member of localeCtrl”, which is correct.
I also tried to create a new .jsf file, one as simple as possible, but upon saving it I just got the “Save Failed:null” dialog that I saw other people reporting too! 🙁 🙁 The strange thing is that after this happened, all EL validation in this new file stopped. I can enter totally bogus EL expressions and there is no warning whatshowever. On the other hand, tag validation does still work (if I enter <blabla:tagbla /> then the editor correctly flags this as warning).
The only difference I see is that I’m using .jspx files in a web project with JSF capabilities added to it, see below (you can’t see in the image anymore, but my cursor is right after the dot after messageBundle and I invoked autocomplete and got that popup):
I created a brand new web project. Choose J2EE 1.4. After that I choose to add JSF capabilities from the MyEclipse menu. Choose the MyEclipse 1.1.1 option.
Created file src/test/bundle.properties with contents key=test
Created file WebRoot/test.jsf with this content:<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> <html> <body> <f:view> <f:loadBundle var="msg" basename="test.bundle" /> <h:outputText value="#{msg.key}" /> </f:view> </body> </html>To start with, JSF EL validation doesn’t flag warnings now at all. Whether I use #{msg.key} or #{msgabc.xyz} doesn’t make any difference.
If I tried to auto-complete in the EL context, it gives me a list that starts with FacesContext, view (with bean icon) and then applicationScope, cookie etc (with star icons). EL auto completion seems to work only partially, it doesn’t auto complete msg and it certainly doesn’t give me a list of keys.
I tried to restart, using -clean but it just doesn’t work. 🙁
The other day I did a clean install of Eclipse 3.2 and MyEclipse 5.0. It’s rather late a my place now so I’ve to call it a day and try again tomorrow. Maybe doing a clean install of 5.01 helps (instead of upgrading 5.0 to 5.01 which I did). I did take a quick glanch at the JSP documents of an other developper in our project. They’re true XML format JSPs, although they have the .jsp suffix instead of .jsp. They had the same warnings thoughs about msg which could not be found.
Riyad, first of all sorry for the long delay in replying. Of course I was a fool to use .jsf for the page name in the example project. I renamed it to test.jsp and I finally got the auto completion to work.
So, I started to hunt for differences between this example project and my real project (where auto completion still doesn’t work). One difference was that we weren’t using a default bundle. We only have a bundle_en, bundle_de, bundle_nl, etc. So, I renamed the example bundle.properties to bundle_en.properties and closed the editor on test.jsp. I then reopend the editor and tried to auto complete again. I then got a dialog saying: “Content Assist” did not complete normally. Please see the log for more information” and the lines below appeared in the error log (see bottom of this post).
After this I restarted eclipse, and in the example project auto completion on the keys didn’t work anymore. I then created an empty file called bundle.properties and it -still- didn’t work. Finally I inserted test keys in bundle.properties and auto completion worked again, but -only- for the keys present in bundle.properties, not for the ones in bundle_en.properties!
Now I’m not really too sure about this, but I think it’s legal for more specific bundles (i.e., language, country, culture) to have keys which are not present in a less specific (i.e. parent) bundle. Your editor seems to only take the default bundle into account.
The exception:
!ENTRY org.eclipse.ui 4 4 2006-08-31 22:14:28.625
!MESSAGE “Content Assist” did not complete normally. Please see the log for more information.!ENTRY org.eclipse.ui 4 0 2006-08-31 22:14:28.625
!MESSAGE java.lang.NullPointerException
!STACK 0
java.lang.NullPointerException
at org.eclipse.jst.jsf.designtime.internal.jsp.JSPDefaultSymbolFactory$ResourceBundleMapSource.entrySet(JSPDefaultSymbolFactory.java:317)
at java.util.AbstractMap$1$1.<init>(Unknown Source)
at java.util.AbstractMap$1.iterator(Unknown Source)
at org.eclipse.jst.jsf.context.symbol.internal.impl.IMapTypeDescriptorImpl.processSegments(IMapTypeDescriptorImpl.java:205)
at org.eclipse.jst.jsf.context.symbol.internal.impl.IMapTypeDescriptorImpl.getProperties(IMapTypeDescriptorImpl.java:190)
at org.eclipse.jst.jsf.designtime.internal.provisional.el.DefaultDTPropertyResolver.getAllPropertiesList(DefaultDTPropertyResolver.java:71)
at org.eclipse.jst.jsf.designtime.internal.provisional.el.DefaultDTPropertyResolver.getAllProperties(DefaultDTPropertyResolver.java:62)
at org.eclipse.jst.jsf.designtime.internal.provisional.resolver.SymbolContextResolver.getProperties(SymbolContextResolver.java:104)
at org.eclipse.jst.jsf.contentassist.internal.el.FunctionCompletionStrategy.getSymbols(FunctionCompletionStrategy.java:168)
at org.eclipse.jst.jsf.contentassist.internal.el.FunctionCompletionStrategy.getProposals(FunctionCompletionStrategy.java:120)
at org.eclipse.jst.jsf.contentassist.internal.el.JSFELContentAssistProcessor.computeCompletionProposals(JSFELContentAssistProcessor.java:110)
at org.eclipse.wst.sse.ui.internal.contentassist.CompoundContentAssistProcessor.computeCompletionProposals(CompoundContentAssistProcessor.java:233)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1612)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:473)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$17(CompletionProposalPopup.java:470)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:405)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:399)
at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1441)
at org.eclipse.wst.sse.ui.internal.StructuredTextViewer.doOperation(StructuredTextViewer.java:379)
at org.eclipse.ui.texteditor.TextOperationAction$1.run(TextOperationAction.java:131)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
at org.eclipse.ui.texteditor.TextOperationAction.run(TextOperationAction.java:129)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:499)
at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185)
at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:461)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:424)
at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:160)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:466)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:799)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:846)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:564)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:506)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:122)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:982)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:927)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:937)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:965)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:961)
at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1275)
at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:3346)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:3246)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4025)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1923)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2966)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
at org.eclipse.core.launcher.Main.run(Main.java:977)
at org.eclipse.core.launcher.Main.main(Main.java:952)My prelim analysis of this looks like a bug, I will file it for someone to look into. Sorry for thisi trouble.
Hi,
Just wondering, is this bug still on your radar?
Related to this bug, the [] syntax is also still not supported in the current version of MyEclipse. Any ETA for that?
I see, and 6.0 is still slated for end of Q3 2007?
That’s quite a long wait, although I understand that there must be a lot of subtleties to deal with…
It does seem long but when you factor in the milestones we will be pushing out before the final GA release, it’s much sooner. We are going to get 5.5 GA out the door at the end of April and then I think we have our file milstone for 6 planned for June or something… I think we get to sleep a couple days in between April and June 🙂
