https://issues.apache.org/bugzilla/show_bug.cgi?id=54764
--- Comment #4 from Nick Burch <[email protected]> --- As of r1615720, there are no issues with loading files at the OPC level with hand-crafted nested entities, on the default JVM xml parser. The affected part will be skipped, so if it was eg docProps/core.xml then you just won't see any core properties, but if it was ContentTypes then the whole OPCPackage will be rejected as invalid. XMLBeans is still an issue though. With XMLBeans 2.3 (the default we ship), it'll hang. With XMLBeans 2.6, the built-in entity expansion detection will trigger at 10,240 bytes expanded and halt parsing. The problem is that XMLBeans doesn't reset the state of the SaxHandler it uses, and that seems to be some sort of singleton. That means that once one naughty file has blown up, all subsequent files will fail to parse as it still thinks it's in the same too-large entity even though it isn't! It would seem that we need to either fix or workaround this xmlbeans 2.6 bug, then upgrade the xmlbeans runtime that we ship + recommend. (Because XMLBeans runtimes are happy with older generated classes, but not newer ones, and because some of our users are on platforms which ship + depend on older XMLBeans instances like 2.3, we shouldn't just upgrade the version of xmlbeans we use to compile the schemas with. Instead, once the problem is fixed, we should look to ship 2.3 for compiling but 2.6/fixed by default for running) If someone has some time to work on this, the thing to do would be to bump the xmlbeans runtime in your dev env up to 2.6, attach the xmlbeans sources, enable the commented out part of TestXSSFBugs.bug54764, then try to work out where the caching of the SaxHandler happens. From that, it'll hopefully be possible to find out if we can workout the lack of byte expansion count reset or not -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
