SaxonEE:9.8 ClassNotFoundException:执行saxonValidator.validate

时间:2019-01-16 09:26:45

标签: xml xsd saxon xml-validation

我使用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个元素,我们将出现以下错误。

有帮助吗?

1 个答案:

答案 0 :(得分:1)

在使用OSGi的环境中,我们还遇到了一些涉及Saxon字节码生成的类似问题,请参见

https://saxonica.plan.io/issues/4036

https://saxonica.plan.io/issues/3814

在这些情况下,用户可以通过在Saxon配置上设置其他类加载器来解决此问题。

我一直不太愿意在此区域更改产品代码,因为这很难测试。使用自定义类加载的环境(例如Websphere和Eclipse)往往是我们在“实验室”中尚未安装的东西,这使得很难确定我们所做的任何更改不会导致其他工作负载失败。

该问题仅在文件达到一定大小时才出现的原因是,字节码生成仅针对已执行一定次数的代码片段进行,以确保不会在以下位置产生代码生成成本它没有带来任何好处。 (在这种情况下,通过模式验证,字节码将针对特定的用户定义的XSD简单类型执行验证。)

您当然可以在“配置”上通过适当的设置完全禁用字节码生成。