为什么泽西岛的 XmlRootElementJaxbProvider 使用 SAXSource答案

【问题标题】：Why does XmlRootElementJaxbProvider in Jersey use SAXSource为什么泽西岛的 XmlRootElementJaxbProvider 使用 SAXSource
【发布时间】：2016-04-04 14:11:27
【问题描述】：

阅读 Jersey 源代码后，我注意到 one of the default MessageBodyReader implementations 创建了一个 SAXSource，然后将其传递给 Unmarshaller。

@Override
protected Object readFrom(Class<Object> type, MediaType mediaType,
        Unmarshaller u, InputStream entityStream)
        throws JAXBException {
    final SAXSource s = getSAXSource(spf.provide(), entityStream);
    if (type.isAnnotationPresent(XmlRootElement.class)) {
        return u.unmarshal(s);
    } else {
        return u.unmarshal(s, type).getValue();
    }
}

我的问题：为什么InputStream 包裹在SAXSource 中？

Unmarshaller.unmarshal 可以自己接受InputStream，com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl 似乎使用相同的内部方法来解组是否提供了SAXSource 或InputStream。唯一的区别似乎是XmlRootElementJaxbProvider 使用依赖注入来提供一个Factory<SAXParserFactory>，该Factory<SAXParserFactory> 用于获取SAXParserFactory，而在UnmarshallerImpl 的内部，方法SAXParserFactory.newInstance() 被直接调用。是否希望能够注入自定义 SAXParserFactory 是使用 unmarshaller.unmarshal(SAXSource) 而不是 unmarshaller.unmarshal(InputStream) 的唯一原因？

【问题讨论】：

标签： java jaxb jersey jersey-2.0

【解决方案1】：

Git 责备是你的朋友。最初的实现（早在 2009 年）使用 StreamSource。更改的原因是一个错误，https://java.net/jira/browse/JERSEY-323。

当时，是的，SAXParserFactory.newInstance() 被直接调用，但是代码随后在解析器上设置了各种特性（大概这些特性当时不是由 JAXB 设置的）。你可以在这里看到这个：https://github.com/jersey/jersey-1.x/blob/2057807f211958860a7557abf49ac4cd6a5ef1fb/jersey-core/src/main/java/com/sun/jersey/core/impl/provider/xml/SAXParserContextProvider.java

我不确定该更改是否仍然必要，但这是更改的最初动机。从那以后，代码似乎一直相对未经修改。

更改的完整差异是here，虽然不是很明显。 XmlRootElementProvider 中增加了 readFrom 方法，用于覆盖 AbstractRootElementProvider 中使用 StreamSource 的方法。

【讨论】：

谢谢，我应该更深入地了解SAXParserFactory 的来源。设置FEATURE_SECURE_PROCESSING 属性似乎是一种迂回的方式。我本来希望在getSAXSource 方法中找到该属性集。我猜工厂确保所有SAXParserFactory 实例都有安全处理，而不是每次使用newInstance 时都需要设置安全处理。