问题描述
我在github上设置了一个测试单元。有人可以检查为什么这不起作用虽然XML解组看起来不错?
I have set up a test unit at github. Could someone please check why this is not working though the XML to unmarshal looks good?
"<?xml version=\"1.0\" encoding=\"UTF-8\"?><message:GenericData xmlns:message=\"http://www.sdmx.org/resources/sdmxml/schemas/v2_1/message\" xmlns:common=\"http://www.sdmx.org/resources/sdmxml/schemas/v2_1/common\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:generic=\"http://www.sdmx.org/resources/sdmxml/schemas/v2_1/data/generic\" xsi:schemaLocation=\"http://www.sdmx.org/resources/sdmxml/schemas/v2_1/message https://sdw-wsrest.ecb.europa.eu/vocabulary/sdmx/2_1/SDMXMessage.xsd http://www.sdmx.org/resources/sdmxml/schemas/v2_1/common https://sdw-wsrest.ecb.europa.eu/vocabulary/sdmx/2_1/SDMXCommon.xsd http://www.sdmx.org/resources/sdmxml/schemas/v2_1/data/generic https://sdw-wsrest.ecb.europa.eu/vocabulary/sdmx/2_1/SDMXDataGeneric.xsd\">\n"
+ "<message:Header>\n" ...
最外层元素GenericDataType被正确实例化。我使用调试器检查了这一点并将断点设置为手工制作的公共构造函数。但是,消息:Header元素导致BaseHeaderType类的实例化,这是抽象的。
The most outer element GenericDataType gets instantiated correctly. I checked that using the debugger and setting a breakpoint into a hand-crafted public constructor. However, the message:Header element leads to instantiation of BaseHeaderType class which is abstract.
在SDMXMessage.xsd中,明确指出GenericDataType的标头仅限于GenericDataHeaderType:
In SDMXMessage.xsd there is clearly stated that the GenericDataType's header is restricted to GenericDataHeaderType:
<xs:complexType name="GenericDataType">
<xs:annotation>
<xs:documentation>GenericDataType defines the contents of a generic data message.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:restriction base="MessageType">
<xs:sequence>
<xs:element name="Header" type="GenericDataHeaderType"/>
<xs:element name="DataSet" type="data:DataSetType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="footer:Footer" minOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
为什么xjc会在代码生成期间忽略它?
Why does xjc ignore that during code generation?
public abstract class MessageType {
@XmlElement(name = "Header", required = true)
protected BaseHeaderType header;
@XmlAnyElement(lax = true)
protected List<Object> any;
@XmlElement(name = "Footer", namespace = "http://www.sdmx.org/resources/sdmxml/schemas/v2_1/message/footer")
protected FooterType footer;
public class GenericDataType
extends MessageType {
}
Is there anything I can do about that? Any automatic alternative for creating a Java domain model from XSD files that is actually working?
推荐答案
好的,我会将此发布为答案。
Ok, I'll post this as an answer.
由于这种类型的构造,你遇到了这个问题:
You run into this problem because of this type of the construct:
<xs:complexType name="MessageType" abstract="true">
<xs:annotation>
<xs:documentation>MessageType is an abstract type which is used by all of the messages, to allow inheritance of common features. Every message consists of a mandatory header, followed by optional payload (which may occur multiple times), and finally an optional footer section for conveying error, warning, and informational messages.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="Header" type="BaseHeaderType"/>
<xs:any namespace="##targetNamespace" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="footer:Footer" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
...
<xs:complexType name="GenericDataType">
<xs:annotation>
<xs:documentation>GenericDataType defines the contents of a generic data message.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:restriction base="MessageType">
<xs:sequence>
<xs:element name="Header" type="GenericDataHeaderType"/>
<xs:element name="DataSet" type="data:DataSetType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="footer:Footer" minOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
一个元素仅限于更具体的元素/类型( DataSet
)。由于所有属性都已在super classe上定义,因此XJC不会在继承类上生成它们
One element is restricted to a more specific element/type (DataSet
). Since all the properties are already defined on the super classe, XJC does not generate them on the "inheriting class"
据我所知,存在许多问题。通过限制推导似乎是JAXB的一个难题。
To my knowledge, there is a number of issues reported on restrictions in JAXB RI. Derivation by restriction seems to be a hard concept for JAXB.
例如,在这种情况下 - 您如何看待 GenericDataType
应该是什么样的?您基本上需要覆盖标头
属性以使用更具体的类型。由于XJC在字段而不是getter / setter上放置注释,我想知道如何覆盖这样的属性。您可以添加另一个标题属性来处理标题
,但是覆盖?
For instance, in this case - how do you think GenericDataType
should look like? You basically need to override the header
property to use a more specific type. Since XJC places annotations on fields rather than getters/setter, I wonder how you could override such a property. You can add another header property to handle your header
, but override?
尝试写这样一个类 - 手动并使用 jaxb:class / @ ref
-binding。如果你使它工作,这将给出应该生成什么的想法。
Try writing such a class - manually and use jaxb:class/@ref
-binding. If you make it work, this would give an idea of what should be generated.
接下来,如果通过XJC插件是否可行。
Next, if it is feasible via an XJC plugin or not.
您在此报告的问题实际上是XJC的核心业务。如果某些东西在那里不起作用,那么好的事情就是报告(或找到已报告的问题)并在XJC中解决问题。
The issue you report here is actually XJC's core business. If something don't work there then the "good" thing would be to report (or find an already reported issue) and fix the problem in XJC.
XJC插件可以做了很多事。您可以完全重组模型并自定义生成。通过适当的努力,一切皆有可能。
XJC plugins can do really a lot of things. You can completely restructure the model and customize the generation. With the appropriate effort, everything is possible.
但在这种情况下,这可能是一项冒险的尝试。编写高级XJC插件并不容易。
But in this case this might be a risky endeavour. Writing advanced XJC plugins is not easy.
如果你对插件应该做什么以及如何在模式派生类中修复这个特定问题有一个很好的概念发表您的想法,也许我们将能够提供一些指导。我个人而言,我可能写的XJC插件比其他任何人都多。
If you have a good concept on what exactly the plugin should do and how this particular issue could be fixed in the schema-derived classes, post your thoughts, maybe we'll be able to provide some guidance. Me personally, I've probably written more XJC plugins than anyone else.
我希望这会有所帮助。
这篇关于JAXB2类型限制不起作用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!