SaxonEE:9.8 ClassNotFoundException:执行时的 AtomicTypeValidator saxonValidator.validate
SaxonEE: 9.8 ClassNotFoundException: AtomicTypeValidator while executing saxonValidator.validate
我使用 Saxon EE API 通过 XSD 验证 XML 有效负载。我的环境是OSGi。
对于特定的 XSD,我遇到了一个奇怪的错误。
java.lang.NoClassDefFoundError: com/saxonica/ee/bytecode/simtype/AtomicTypeValidator
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:858)
at java.lang.ClassLoader.defineClass(ClassLoader.java:704)
at net.sf.saxon.java.JavaPlatform$MyClassLoader.registerClass(JavaPlatform.java:441)
at com.saxonica.ee.bytecode.util.CompilerService.makeClass(CompilerService.java:1067)
at com.saxonica.ee.bytecode.util.CompilerService.compileAtomicValidator(CompilerService.java:1241)
at com.saxonica.ee.schema.UserAtomicType.validateContent(UserAtomicType.java:373)
at com.saxonica.ee.validate.SimpleContentValidator.endElement(SimpleContentValidator.java:239)
at com.saxonica.ee.validate.ValidationStack.endElement(ValidationStack.java:412)
at net.sf.saxon.event.ProxyReceiver.endElement(ProxyReceiver.java:182)
at net.sf.saxon.event.StartTagBuffer.endElement(StartTagBuffer.java:290)
at com.saxonica.ee.validate.StartTagBufferEE.endElement(StartTagBufferEE.java:58)
at net.sf.saxon.event.PathMaintainer.endElement(PathMaintainer.java:62)
at net.sf.saxon.event.DocumentValidator.endElement(DocumentValidator.java:68)
at net.sf.saxon.event.ReceivingContentHandler.endElement(ReceivingContentHandler.java:459)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2967)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:427)
at net.sf.saxon.event.Sender.send(Sender.java:164)
at com.saxonica.ee.s9api.SchemaValidatorImpl.validate(SchemaValidatorImpl.java:587)
观察:如果我们限制有效负载大小,即在 xml 个元素中,具有相同 XSD 和有效负载的场景工作正常;如果我们减少到少于 80 个元素,它会起作用,而超过 80 个元素我们会得到以下错误。
有什么帮助吗?
我们在使用 OSGi 的环境中遇到了一些涉及 Saxon 字节码生成的类似问题,请参阅
https://saxonica.plan.io/issues/4036
https://saxonica.plan.io/issues/3814
在这些情况下,用户可以通过在 Saxon 配置上设置不同的 classloader 来解决问题。
我一直有点不愿意更改这方面的产品代码,因为它很难测试。使用自定义 class 加载的环境(例如 Websphere 和 Eclipse)往往是我们没有安装的东西 "in the lab",这使得很难确定我们所做的任何更改都没有导致其他工作负载失败。
只有当文件达到一定大小时才会出现问题的原因是字节码生成只对执行了一定次数的代码片段进行,以确保生成代码的成本不高在没有带来好处的情况下发生。 (在这种情况下,通过模式验证,字节码针对特定的用户定义 XSD 简单类型执行验证)。
当然,您可以通过配置中的适当设置完全禁用字节码生成。
我使用 Saxon EE API 通过 XSD 验证 XML 有效负载。我的环境是OSGi。
对于特定的 XSD,我遇到了一个奇怪的错误。
java.lang.NoClassDefFoundError: com/saxonica/ee/bytecode/simtype/AtomicTypeValidator
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:858)
at java.lang.ClassLoader.defineClass(ClassLoader.java:704)
at net.sf.saxon.java.JavaPlatform$MyClassLoader.registerClass(JavaPlatform.java:441)
at com.saxonica.ee.bytecode.util.CompilerService.makeClass(CompilerService.java:1067)
at com.saxonica.ee.bytecode.util.CompilerService.compileAtomicValidator(CompilerService.java:1241)
at com.saxonica.ee.schema.UserAtomicType.validateContent(UserAtomicType.java:373)
at com.saxonica.ee.validate.SimpleContentValidator.endElement(SimpleContentValidator.java:239)
at com.saxonica.ee.validate.ValidationStack.endElement(ValidationStack.java:412)
at net.sf.saxon.event.ProxyReceiver.endElement(ProxyReceiver.java:182)
at net.sf.saxon.event.StartTagBuffer.endElement(StartTagBuffer.java:290)
at com.saxonica.ee.validate.StartTagBufferEE.endElement(StartTagBufferEE.java:58)
at net.sf.saxon.event.PathMaintainer.endElement(PathMaintainer.java:62)
at net.sf.saxon.event.DocumentValidator.endElement(DocumentValidator.java:68)
at net.sf.saxon.event.ReceivingContentHandler.endElement(ReceivingContentHandler.java:459)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2967)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:427)
at net.sf.saxon.event.Sender.send(Sender.java:164)
at com.saxonica.ee.s9api.SchemaValidatorImpl.validate(SchemaValidatorImpl.java:587)
观察:如果我们限制有效负载大小,即在 xml 个元素中,具有相同 XSD 和有效负载的场景工作正常;如果我们减少到少于 80 个元素,它会起作用,而超过 80 个元素我们会得到以下错误。
有什么帮助吗?
我们在使用 OSGi 的环境中遇到了一些涉及 Saxon 字节码生成的类似问题,请参阅
https://saxonica.plan.io/issues/4036
https://saxonica.plan.io/issues/3814
在这些情况下,用户可以通过在 Saxon 配置上设置不同的 classloader 来解决问题。
我一直有点不愿意更改这方面的产品代码,因为它很难测试。使用自定义 class 加载的环境(例如 Websphere 和 Eclipse)往往是我们没有安装的东西 "in the lab",这使得很难确定我们所做的任何更改都没有导致其他工作负载失败。
只有当文件达到一定大小时才会出现问题的原因是字节码生成只对执行了一定次数的代码片段进行,以确保生成代码的成本不高在没有带来好处的情况下发生。 (在这种情况下,通过模式验证,字节码针对特定的用户定义 XSD 简单类型执行验证)。
当然,您可以通过配置中的适当设置完全禁用字节码生成。