Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 333685

Summary: NPE thrown when selecting 'Edit Namespace Prefixes' from the 'XPath' view's view menu with no editors open
Product: [WebTools] WTP Source Editing Reporter: Remy Suen <remy.suen>
Component: wst.xpathAssignee: Jesper Moller <jesper>
Status: RESOLVED FIXED QA Contact: Jesper Moller <jesper>
Severity: normal    
Priority: P3 CC: david_williams, d_a_carver, raghunathan.srinivasan, thatnitind
Version: 3.2Flags: d_a_carver: review+
Target Milestone: 3.2.3   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on:    
Bug Blocks: 348768    
Attachments:
Description Flags
Double fix for this bug, against 3.2.x branch none

Description Remy Suen CLA 2011-01-06 14:31:47 EST 
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)
Comment 1 Jesper Moller CLA 2011-01-18 20:35:52 EST 
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.
Comment 2 Jesper Moller CLA 2011-01-18 20:51:13 EST 
(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.
Comment 3 Remy Suen CLA 2011-01-18 20:59:25 EST 
(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. ;)
Comment 4 David Carver CLA 2011-01-19 12:45:51 EST 
Looks good.
Comment 5 Jesper Moller CLA 2011-02-03 14:18:02 EST 
I'm sorry, I forgot to resolve this one, it was committed and tagged last week.
Comment 6 Remy Suen CLA 2011-06-08 11:30:36 EDT 
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?