使用 dom4j DOMDocument 提供 validator.validate(DOMSource) 在 java 1.6 中失败(不允许 xsi:noNamespaceSchemaLocation),在 1.5 中有效

发布于 2024-10-18 09:00:21 字数 4044 浏览 1 评论 0原文

使用 dom4j DOMDocument 提供 validator.validate(DOMSource) 在 java 1.6 中失败(不允许 xsi:noNamespaceSchemaLocation 出现在根元素中),在 1.5 中有效

我发现以下问题非常棘手(好吧,这是轻描淡写)-任何见解将不胜感激。目前看来最好的想法是放弃 dom4j,转而使用 XOM (http://stackoverflow.com/questions/831865/what-java-xml-library-do-you-recommend-to-replace-dom4j)。

我一直在内存中验证从 dom4j 'new DOMDocument()' 创建的 XML - 但这不适用于 Java 6。

以下对 dom4j (1.6.1) DOMDocument 派生的 DOMSource 的 validate(source) 的调用适用于 Java 1.5 .x 但在 Java 1.6.x 中失败:

public void validate() throws Exception {
    SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
    schemaFactory.setErrorHandler(null);
    Schema schemaXSD = schemaFactory.newSchema(new URL(getSchemaURLString()));
    Validator validator = schemaXSD.newValidator();
    DOMSource source = new DOMSource(getDocument());
    validator.validate(source);
}

getSchemaURLString() 还用于将 xsi:noNamespaceSchemaLocation 属性添加到根节点,即: xsi:noNamespaceSchemaLocation="http://localhost:8080/integration/xsd/fqlResponseSchema-2.0.xsd"

异常如下:

Exception:  org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'xsi:noNamespaceSchemaLocation' is not allowed to appear in element 'specialfields'.;                
complex-type.3.2.2: Attribute 'xsi:noNamespaceSchemaLocation' is not allowed to appear in element 'specialfields'.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:417)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3182)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processAttributes(XMLSchemaValidator.java:2659)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2066)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.beginNode(DOMValidatorHelper.java:273)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:240)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:186)
at com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:104)
at javax.xml.validation.Validator.validate(Validator.java:127)

) 的调用后生成的 XML 的开头:

<?xml version="1.0" encoding="utf-8"?> 
<meetings xsi:noNamespaceSchemaLocation="http://localhost:8080/integration/xsd/fqlResponseSchema-2.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
.............
</meetings>

这是禁用对 validator.validate( source XSD:

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="meetings">
    <xs:complexType>
      <xs:choice>
    <xs:sequence>
          <xs:element minOccurs="0" maxOccurs="1" ref="summary" />
          <xs:element minOccurs="0" maxOccurs="unbounded" ref="meeting" />
        </xs:sequence>
        <xs:element ref="error" />
      </xs:choice>
    </xs:complexType>
  </xs:element>
  <xs:element name="summary">
................

所以我的根元素被拒绝,因为它包含 xsi:noNamespaceSchemaLocation 属性。并且架构本身没有将其指定为我的根元素的有效属性?

此时,在我看来,我需要放弃 dom4j 来完成此任务,并切换到其他解决方案之一,例如此处概述的:

但无论如何我想知道我做错了什么!

提前致谢。

Using dom4j DOMDocument to feed validator.validate(DOMSource) fails in java 1.6 (with xsi:noNamespaceSchemaLocation is not allowed to appear in root element), works in 1.5

I'm finding the following problem quite intractable (OK, that's an understatement) - any insights will be appreciated. Currently it seems like the best idea is to drop dom4j in favour of e.g. XOM (http://stackoverflow.com/questions/831865/what-java-xml-library-do-you-recommend-to-replace-dom4j).

I've been validating in memory XML created from dom4j 'new DOMDocument()' - but this will not work with Java 6.

The following call to validate(source) of a dom4j (1.6.1) DOMDocument derived DOMSource works with Java 1.5.x but fails with Java 1.6.x:

public void validate() throws Exception {
    SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
    schemaFactory.setErrorHandler(null);
    Schema schemaXSD = schemaFactory.newSchema(new URL(getSchemaURLString()));
    Validator validator = schemaXSD.newValidator();
    DOMSource source = new DOMSource(getDocument());
    validator.validate(source);
}

getSchemaURLString() is also used to add the xsi:noNamespaceSchemaLocation attribute to the root node, i.e.:
xsi:noNamespaceSchemaLocation="http://localhost:8080/integration/xsd/fqlResponseSchema-2.0.xsd"

The exception follows:

Exception:  org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'xsi:noNamespaceSchemaLocation' is not allowed to appear in element 'specialfields'.;                
complex-type.3.2.2: Attribute 'xsi:noNamespaceSchemaLocation' is not allowed to appear in element 'specialfields'.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:417)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3182)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processAttributes(XMLSchemaValidator.java:2659)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2066)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.beginNode(DOMValidatorHelper.java:273)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:240)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:186)
at com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:104)
at javax.xml.validation.Validator.validate(Validator.java:127)

Here's the start of the XML - generated after disabling the call to validator.validate(source):

<?xml version="1.0" encoding="utf-8"?> 
<meetings xsi:noNamespaceSchemaLocation="http://localhost:8080/integration/xsd/fqlResponseSchema-2.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
.............
</meetings>

And of the XSD:

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="meetings">
    <xs:complexType>
      <xs:choice>
    <xs:sequence>
          <xs:element minOccurs="0" maxOccurs="1" ref="summary" />
          <xs:element minOccurs="0" maxOccurs="unbounded" ref="meeting" />
        </xs:sequence>
        <xs:element ref="error" />
      </xs:choice>
    </xs:complexType>
  </xs:element>
  <xs:element name="summary">
................

So my root element is being rejected because it contains a xsi:noNamespaceSchemaLocation attribute. And the schema itself does not specify that as a valid attribute of my root element?

At this point it seems to me that I need to give up on dom4j for this task and switch to one of the other solutions, for example as outlined here:

But I'd like to know what I've done wrong at any rate!

Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

2024-10-25 09:00:21

我遇到了同样的问题,我在 http 中找到了以下文档

: //www.ibm.com/developerworks/xml/library/x-javaxmlvalidapi/index.html

根据文档指定的架构进行验证

一些文档指定了他们希望验证的模式,
通常使用 xsi:noNamespaceSchemaLocation 和/或
xsi:schemaLocation 属性如下:

<document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="http://www.example.com/document.xsd">  
 ...

如果您创建架构时未指定 URL、文件或源,则
Java 语言创建一个在文档中查找的语言
进行验证以找到它应该使用的模式。例如:

SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema"); 
Schema schema = factory.newSchema();

但是,通常这不是您想要的。通常是文档
消费者应该选择模式,而不是文档生产者。
此外,此方法仅适用于 XSD。所有其他架构
语言需要明确指定的架构位置。

I had the same issue, and I found the following documentation at

http://www.ibm.com/developerworks/xml/library/x-javaxmlvalidapi/index.html

Validate against a document-specified schema

Some documents specify the schema they expect to be validated against,
typically using xsi:noNamespaceSchemaLocation and/or
xsi:schemaLocation attributes like this:

<document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="http://www.example.com/document.xsd">  
 ...

If you create a schema without specifying a URL, file, or source, then
the Java language creates one that looks in the document being
validated to find the schema it should use. For example:

SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema"); 
Schema schema = factory.newSchema();

However, normally this isn't what you want. Usually the document
consumer should choose the schema, not the document producer.
Furthermore, this approach works only for XSD. All other schema
languages require an explicitly specified schema location.

棒棒糖 2024-10-25 09:00:21

原因似乎是正在创建和使用非命名空间感知的 JAXP SAXParser (请参阅

我在 www.edankert.com 找到了不同库的解决方案。

The reason seems to be that non-namespace aware JAXP SAXParser is being created and used (see Link).

And solution for different libs I found at www.edankert.com.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文