Community
Participate
Working Groups
I20101208-1300 (3.7M4) 1. Install 'Eclipse XSL Developer Tools' from the Indigo site. 2. Restart when prompted. 3. Window > Open Perspective > Other... > XML 4. Activate the 'XPath' view. 5. Ctrl+F10 > Edit Namespace Prefixes 6. Nothing happens. An NPE is logged. The code assumes that there is an active editor around (not always true). Perhaps the menu item should not be enabled if there isn't an active editor? Or maybe completely hidden? java.lang.NullPointerException at org.eclipse.wst.xml.xpath.ui.internal.handler.PrefixHandler.execute(PrefixHandler.java:51) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169) at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241) at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241) at org.eclipse.ui.menus.CommandContributionItem.handleWidgetSelection(CommandContributionItem.java:824) at org.eclipse.ui.menus.CommandContributionItem.access$19(CommandContributionItem.java:810) at org.eclipse.ui.menus.CommandContributionItem$5.handleEvent(CommandContributionItem.java:800)
Created attachment 187068 [details] Double fix for this bug, against 3.2.x branch Fixes this bug by adding an enabledWhen rule on the command, as well as making a null check if the SSE modelManager cannot somehow build us a model.
(Great to see actual bug reports for this component, there hasn't been that many, thanks Remy) Requesting a PMC approval for this trivial fix to an annoying NPE. * Explain why you believe this is a stop-ship defect. I wouldn't call it stop ship, but I do think that every exception in the log is one too many. * Is there a work-around? If so, why do you believe the work-around is insufficient? Obviously, the user could just refrain from choosing this command, but since the XML namespaces are tracked per-file, it's confusing that the menu item is available. * How has the fix been tested? Tested manually against current WTP 3.2.x, with no editor, Java editor (disabled) and XML, XSD, XSL editors (with no problems). No test case as this is mainly a declarative fix in plugin.xml. * Give a brief technical overview. Use an <enabledWhen> construct to check that an XML-oriented editor is active in order to allow the Dialog. * Who has reviewed this fix? I've assigned Dave Carver to do a review, but it is really trivial. * What is the risk associated with this fix? Worst case would be that a bug in the rule set disabled the dialog for all editors. That was specifically tested against. I am seeing this as a very low risk fix.
(In reply to comment #2) > (Great to see actual bug reports for this component, there hasn't been that > many, thanks Remy) No problem, I was just testing compatibility with 4.1 and found this while I was clicking on things randomly. Of course I then realized after a bit of testing that this was not a compatibility problem. ;)
Looks good.
I'm sorry, I forgot to resolve this one, it was committed and tagged last week.
Um, this is still broken in 3.3. :) I see a fix went in for R3_2_maintenance but not for HEAD. Should I reopen this bug or should I open a new bug?
