[ https://issues.jboss.org/browse/JBIDE-10572?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich updated JBIDE-10572: ------------------------------------------ Description: Now the exception can be obtained only in struts-config.xml, but faults in our code make it probable to appear more generally. EXECUTE: Create Struts KickStart project and open struts-config.xml EXECUTE: Create global exception {code} <exception className="/pages/greeting.jsp" key="a" path="/greeting.do" type="b"/> {code} where 'className' is deliberately assigned to an existing page path instead of a class name. EXECUTE: Call open-on options over word 'greeting' ASSERT: Two options appear: 1) open class 'greeting.jsp' 2) Open '/struts/WebContent/pages/greeting.jsp' with JBoss Tools JSP Editor EXECUTE: Call open-on options over symbol '/' FAILURE: null pointer exception; two options may still appear: 1) empty label 2) Open '/struts/WebContent/pages/greeting.jsp' with JBoss Tools JSP Editor I see the cause of the exception in difference of algorithm computing class name region in classes XMLClassHyperlinkPartitioner and ClassHyperlink. Partitioner returns attribute value with trimmed white spaces ant quote symbols. So, even if open-on is invoked over '/', partitioner reports XML_CLASS region and instance of ClassHyperlink is created for it. But ClassHyperlink computes region more strictly, so that text contains only qualified Java name symbols. When open-on is invoked over '/', ClassHyperlink sets region to open to null. If there is no other hyperlink option, that may pass, but when several hyperlinks are detected, MultipleHyperlinkPresenter requests each for hyperlink text, and ClassHyperlink fails. In this case the other option is WST's WorkspaceFileHyperlink, it detects in any attribute values resource paths; if it starts to detect them in text nodes (and why not?), this issue will take place in faces-config.xml and web.xml, where class names are assigned as text nodes. This issue cannot be fixed just by preventing NPE, because open-on option with empty label may appear all the same. Solution is to let partitioner report a region for a corresponding hyperlink only when the hyperlink accepts that region as relevant. was: Now the exception can be obtained only in struts-config.xml, but faults in our code make it probable to appear more generally. EXECUTE: Create Struts KickStart project and open struts-config.xml EXECUTE: Create global exception {code} <exception className="/pages/greeting.jsp" key="a" path="/greeting.do" type="b"/> {code} where 'className' is deliberately assigned to an existing page path instead of a class name. EXECUTE: Call open-on options over word 'greeting' ASSERT: Two options appear: 1) open class 'greeting.jsp' 2) Open '/struts/WebContent/pages/greeting.jsp' with JBoss Tools JSP Editor EXECUTE: Call open-on options over symbol '/' FAILURE: null pointer exception; two options may still appear: 1) empty label 2) Open '/struts/WebContent/pages/greeting.jsp' with JBoss Tools JSP Editor I see the cause of the exception in difference of algorithm computing class name region in classes XMLClassHyperlinkPartitioner and ClassHyperlink. Partitioner returns attribute value with trimmed white spaces ant quote symbols. So, even if open-on is invoked over '/', partitioner creates instance of ClassHyperlink. But ClassHyperlink computes region more strictly, so that text contains only qualified Java name symbols. When open-on is invoked over '/', ClassHyperlink sets region to open to null. If there is no other hyperlink option, that may pass, but when several hyperlinks are detected, MultipleHyperlinkPresenter requests each for hyperlink text, and ClassHyperlink fails. In this case the other option is WST's WorkspaceFileHyperlink, it detects in any attribute values resource paths; if it starts to detect them in text nodes (and why not?), this issue will take place in faces-config.xml and web.xml, where class names are assigned as text nodes. This issue cannot be fixed just by preventing NPE, because open-on option with empty label may appear all the same. Solution is to let partitioner create instance of hyperlink only when hyperlink is capable to do its job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10572?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-10572: ----------------------------------------------- I suggest: (1) Method IHyperlinkPartitioner.getChildPartitionType(IDocument, IHyperlinkRegion) should return IHyperlinkRegion instead of String; (2) All methods getPartitionTypes(IDocument, int) and method BaseHyperlinkDetector.getPartitionType(IDocument, int) should return IHyperlinkRegion instead of String; (3) Signature of method BaseHyperlinkDetector.getHyperlinks(ITextViewer, IRegion, String, String partitionType) should be modified as BaseHyperlinkDetector.getHyperlinks(ITextViewer, IRegion, String, IHyperlinkRegion hyperlinkRegion); in its implementation we will assign String partitionType = hyperlinkRegion.getType() and hyperlinkRegion is ready to be passed to AbstractHyperlink; (4) Add public method setRegion(IRegion) and protected field IRegion to AbstractHyperlink; in sub-classes that already have such field (in CDI) remove it. (5) In each implementation of abstract method AbstractHyperlink.doGetHyperlinkRegion(int) that realizes some non-trivial logic for retrieving region (about 30 of them) try to use that object; and if it is not ok, fix partitioner as it was done for this particular case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10572?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-10572: ----------------------------------------------- Ok, I will create new issue. When I created this issue two weeks ago, I was not sure that general problem was easy to solve. Now I am sure about that and new issue may also be fixed for 3.3.0.Beta1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10572?page=com.atlassian.jira.plugi... ] Victor Rubezhny commented on JBIDE-10572: ----------------------------------------- Vlado, In this test case there should be only one open-on. (The second one was causing NPE because is designed to open classes, but not pages). If you see more open-ons (some additional plug-ins, if exist, may add their own open-ons here) they must not throw exceptions (and especially exceptions with org.jboss.tools.* classes in stack trace, like ClassHyperlink class). So, if you see only one open-on and it used to open page specified as value of className attribute, then it's OK. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10572?page=com.atlassian.jira.plugi... ] Vlado Pakan closed JBIDE-10572. ------------------------------- Verified on JBT 2012-01-18_10-32-21-H4144. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira