This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 227660

Summary: NullPointerException at org.openide.xml.XMLUtil.findElement
Product: projects Reporter: bsbc99 <bsbc99>
Component: Ant FreeformAssignee: Martin Kozeny <mkozeny>
Status: RESOLVED WORKSFORME    
Severity: normal    
Priority: P3    
Version: 7.3   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter: 199720
Attachments: stacktrace

Description bsbc99 2013-03-19 10:43:09 UTC
Build: NetBeans IDE 7.3 (Build 201302132200)
VM: Java HotSpot(TM) Client VM, 23.7-b01, Java(TM) SE Runtime Environment, 1.7.0_17-b02
OS: Windows 7

Stacktrace: 
java.lang.NullPointerException
   at org.openide.xml.XMLUtil.findElement(XMLUtil.java:972)
   at org.netbeans.modules.ant.freeform.Actions$1.run(Actions.java:379)
   at org.netbeans.modules.ant.freeform.Actions$1.run(Actions.java:354)
   at org.openide.util.Mutex.readAccess(Mutex.java:290)
   at org.netbeans.modules.ant.freeform.Actions.runConfiguredAction(Actions.java:354)
   at org.netbeans.modules.ant.freeform.Actions.access$100(Actions.java:109)
Comment 1 bsbc99 2013-03-19 10:43:19 UTC
Created attachment 132786 [details]
stacktrace
Comment 2 Milos Kleint 2013-07-10 11:57:12 UTC
there must be some kind of data inconsistency in the dom tree or some error in jdk sources?

The freeform code calls:
XMLUtil.findElement(actionEl, "context", FreeformProjectType.NS_GENERAL);
which was repeatedly called before on the same data structures right before this call, only difference being different "context" parameter.

in XMLUtil the code looks like this:

        NodeList l = parent.getChildNodes();
        int nodeCount = l.getLength();
        for (int i = 0; i < nodeCount; i++) {
            if (l.item(i).getNodeType() == Node.ELEMENT_NODE) {

the NPE is thrown on the last line. Assuming that parent.getChildNodes() can never be null, then null can only occur when one of the items in the list null. but as was said before any of the 2 possibilities should have been thrown in the previous invokations of the methods with the same parent element. So apparently the data structure changed or the jdk implementation of the nodelist. I've double checked our codebase and we appear to always clone entire dom trees within the AuxiliaryConfiguration methods, so the dom trees should be immutable.
Comment 3 Quality Engineering 2015-02-04 03:34:38 UTC
Reported for 7.3.x or earlier, no new info since then -> closing as worksforme, please reopen in case you see it.