Saxon

Legacy ID: #4302528 Legacy Poster: Michael Kay (mhkay)

Saxon attempts to reuse the same parser for multiple documents because this gives a significant performance advantage. SAX parsers are supposed to be serially reusable so this looks like a TagSoup bug to me. It is triggered by a Saxon change, however, because in the past Saxon didn't attempt to reuse the parser. I think your easiest workaround is probably to write a URIResolver to handle the input documents rather than relying on the -x switch. You can then create a new SAXSource with a newly allocated parser for each document. Michael Kay

Legacy ID: #4302586 Legacy Poster: iWantToKeepAnon (iwanttokeepanon)

Thanks Dr. Kay! You truly do spend a lot of time helping people. I wonder sometimes that there is any new development on Saxon at all! <g> This is just for personal 'hacking' around. Thanks for the tips. I'll crosspost this over to the tagsoup-friends. Thx again, -- Rodman

Legacy ID: #4303667 Legacy Poster: John Cowan (johnwcowan)

I don't think parser reuse can be the problem. My regression tests run several hundred documents through a single TagSoup parser object. I've just downloaded the latest Saxon-B to see if I can figure out what the problem is. Note to iWantToKeepAnon: It's a really really bad idea to use two dynamically changing documents when sending in a test case.

Legacy ID: #4305209 Legacy Poster: John Cowan (johnwcowan)

Okay, I've nailed the problem. The NullPointerException arises because the value of the instance variable that holds the entity resolver in TagSoup is null, and it's null because net.sf.saxon.Configuration.reuseSourceParser (Configuration.java:1,445) sets it to null explicitly. There's nothing in the Javadoc at http://www.saxproject.org/apidoc/org/xml/sax/XMLReader.html#setEntityResolver(org.xml.sax.EntityResolver) which justifies calling setEntityResolver with a null argument, though getEntityResolver does return null if no entity resolver has been set.

Legacy ID: #4305605 Legacy Poster: Michael Kay (mhkay)

Thanks for the diagnostics. Are you going to fix it? Although the spec might have a gap, I think that since the parser is supposed to be reusable, and since it is supposed to be able to operate without a user-supplied EntityResolver, and since there's no explicit "@throws NullPointerException" in the Javadoc, it's a reasonable expectation that one should be able to revert the setting to its initial state by passing null. I don't think it's essential here for Saxon to unset the EntityResolver, it's more of a safety measure: since the application that's using the parser the second time might be quite unrelated to the application that used it the first time, I think the parser it gets should be a clean one. It also has memory benefits since parsing tends to happen early in the life of the application and hanging on to the EntityResolver might lock a lot of stuff into memory for the rest of the application's life. Michael Kay

Legacy ID: #4306197 Legacy Poster: John Cowan (johnwcowan)

TagSoup 1.1.3 now accepts null as the argument to setEntityResolver, set*Handler, and as a lexical handler set by setProperty, with the effect of restoring default behavior.

Legacy ID: #4311081 Legacy Poster: iWantToKeepAnon (iwanttokeepanon)

Thanks John and Michael, tagsoup works in my stylesheet now. John writes: Note to iWantToKeepAnon: It's a really really bad idea to use two dynamically changing documents when sending in a test case. You are correct of course, but it was the shortest and simplest stylesheet demonstrating the problem. I've found bug reports are more likely to be investigated when the reporter boils down the problem into the shortest amount of code that still demonstrates the issue. Thanks for the quick turn around!