Community
Participate
Working Groups
It looks like the exception occurs inside internal implementation of SAX parser. The part of stack looks like this: java.lang.NullPointerException at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:558) at org.apache.crimson.parser.Parser2.parse(Parser2.java:318) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:442) at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) at javax.xml.parsers.SAXParser.parse(SAXParser.java:281) at com.samsung.oslc.common.OSLCSaxBase.Start(OSLCSaxBase.java:78) Where com.samsung.oslc.common.OSLCSaxBase.Start(OSLCSaxBase.java:78) is our methode. We have added System.out.println calls in our function OSLCSaxBase.Start to see what is passed in file structure to the parser. The string returned from file.getAbsolutePath() looks right. The SAXParser.parse(File f, DefaultHandler dh) function called from OSLCSaxBase.Start is a wrapper which builds InputSource object using path returned from file.getAbsolutePath() and calls SAXParser.parse(InputSource is, DefaultHandler dh) function. We have modified our OSLCSaxBase.Start function to build itself the InputSource object and call SAXParser.parse(InputSource is, DefaultHandler dh) directly. There is no exception when building InputSource object, this object looks right and InputSource.getSystemId() returns the right path. But there is an exception in call to SAXParser.parse(InputSource is, DefaultHandler dh) at the same place as usually. In Motif-based and Windows Eclipse both variants work properly. We have tried to use the last release of XML parser from apache. We have downloaded the latest xerses 2.6.0 from apache (http://xml.apache.org/xerces2-j/index.html) and install it instead of xerses plug-in shipped with eclipse installation. Again, there is exception when we run our plug-in GUI under eclipse-GTK. We think that there is the problem not with plug-ins jar libraries. We see the bug somewhere in the binary core of Eclipse. Properly working of SAX parser in command line tool (without GUI), which uses the same our classes, for both variants of Eclipse (GTK and Motif versions) proves that our version is correct. We see this bug as soon as our product starts working with GUI. It seems that there is a problem inside GTK-based Eclipse platform which results in some memory corruption in low-level parser's implementation.
We don't ship with a crimson parser, this comes from the JDK
Reopening at the originator's request. The code works fine in Eclipse under Windows and Motif, but fails when run under Eclipse GTK. Please tell us what VM vendor and version you are using. If you can try again with the latest available VM that would also be useful data for us.
We use Java VM from Sun Microsystems, versions 1.4.1_05 and 1.4.2_03. With both VMs the code fails under eclipse-GTK versions 2.1.1 and 2.1.2. The code fails also under eclipse-GTK 3.0 (3.0M6) with Java VM 1.4.2_03.
Closing. Likely a VM bug.