脚轮和插座
总的来说，我对 Castor 和数据绑定很陌生。我正在开发一个应用程序，该应用程序部分需要从套接字中取出数据并解组数据以生成 POJO。现在，我已经搞定了套接字的内容，而且借助 Ant 和 Castor，我什至还生成并编译了 java 文件。
问题是：我将收到的数据流可能是大约 9 个不同对象之一。也就是说，我收到一个文本流 (XML)，它表示一个包含我要操作的内容的对象；再次，取决于对象类型。如果它只是一个对象，那就很容易了：对其调用 unmarshall 命令并继续我的快乐之路。但是，由于它可能是多种对象之一，我谁知道要解组什么？我阅读了有关映射的内容，但要么我没有理解它，要么它看起来像是静态映射，而不是动态映射。
有什么帮助吗？
I'm new to Castor and data binding in general. I'm working on an application that, in part, needs to take data off of a socket and unmarshall the data to make POJOs. Now, I've got the socket stuff down, and I've even generated and compiled java files thanks to Ant and Castor.
Here's the problem: the data stream that I'll receive could be one of about 9 different objects. That is, I receive a stream of text (XML) that represents an object with stuff that I'll operate on; again, depending on the object type. If it were just one object, it'd be easy: call the unmarshall commands on it and go on my merry way. But, since it could be one of many kinds of objects, who do I know what to unmarshall? I read up on mapping, but either I didn't get it, or it seems like a static mapping, not a dynamic mapping.
Any help out there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你是对的，Castor 期望静态映射。但你可以使用它。您可以编写一些代码来修改传入的 xml，以便在您这边，Castor 可以使用一种模式，而在您的客户端方面，他们不必更改其模式。
更改 Castor 期望获得具有公共根元素的模式，在该模式下为不同的对象提供九种不同的替代方案（我认为您可以限制它，因此模式将只允许九种中的一种，如果不允许的话）不知道你可以将所有子元素设为可选）。
然后，您可以编写代码来修改传入的 xml，以使用该公共根元素包装传入的 xml，然后将包装的 xml 提供到由 Castor 解组器读取的流中。
至少有 3 种不同的方法来实现 xml 包装部分：SAX、XSLT 和 XML 库（如 JDOM、DOM4J 和 XOM——我更喜欢 XOM，但它们中的任何一个都可以工作）。
如果您已经熟悉 SAX 或者其他方法之一有效但性能不佳，那么 SAX 方法可能是最好的。如果我必须实现这一点，那么我将创建一个 XMLFilter，它接收 xml 并写出 xml，将其堆叠在将 xml 写入 OutputStream 的另一块之上，并在解组内容周围编写一个包装器方法以将传入流提供给xmlreader，将OutputStream复制到另一个InputStream（一个简单的方法是使用commons-io），并将新的InputStream提供给Castor解组器。
对于 XSLT，SAX 是无法愚弄的，虽然 XSLT 有时会带来痛苦，但在我看来，这可能是一个相对简单的转换，但我也没有尝试过。我已经很长时间没有使用 XSLT 来做任何事了。我也不确定性能，但我不会立即将其注销。
使用 XOM 或 JDOM 或 DOM4J 来包装 XML 也是可能的，并且学习曲线比 SAX 或 XSLT 低很多。缺点是整个 XML 文档往往会立即被吸入内存，因此如果您处理足够大的文档，则可能会耗尽内存。
You are right, Castor expects a static mapping. But you can work with that. You can write some code that will modify the incoming xml so that, on your side, Castor can use one schema, and on your clients' side they don't have to change their schemas.
Change the schema that Castor expects to get to something with a common root-element, with under that your nine different alternatives for your different objects (I think you can restrict it so the schema will allow only one of the nine, if that doesn't work out you could just make all the sub-elements optional).
Then you can write code that modifies the incoming xml to wrap your incoming xml with that common root-element, then feeds the wrapped xml into a stream that gets read by the Castor unmarshaller.
There are at least 3 different ways to implement the xml-wrapping part: SAX, XSLT, and XML libraries (like JDOM, DOM4J, and XOM--I prefer XOM but any of them will work).
The SAX way is probably best if you're already familiar with SAX or if one of the other ways has worked but come up short on performance. If I had to implement that then I would create an XMLFilter that takes in xml and writes xml out, stacking that on top of another piece that writes xml to an OutputStream, and writing a wrapper method around the unmarshalling stuff to feed the incoming stream to the xmlreader, copy the OutputStream to another InputStream (an easy way is to use commons-io), and feed the new InputStream to the Castor unmarshaller.
With XSLT there is no fooling with SAX, although XSLT has a reputation for pain sometimes, it seems to me like this might be a relatively straightforward transformation, but I haven't taken a stab at it either. It is a long time since I used XSLT for anything. I am not sure about performance either, though I wouldn't write it off out of hand.
Using XOM or JDOM or DOM4J to wrap the XML is also possible, and the learning curve is a lot lower than for SAX or XSLT. The downside is the whole XML document tends to get sucked into memory at once so if you deal with big enough documents you could run out of memory.
我在 Jibx 中有类似的东西，其中所有传入消息对象都实现一个基本接口，该接口有一个表示消息类型的字段。
text/xml 被序列化到基本接口中，然后我使用命令模式根据基本接口中定义的消息类型来调用相应的业务逻辑。
不确定使用 Castor 是否可以做到这一点，但看看 Jibx，因为性能非常棒。
http://jibx.sourceforge.net/
I have a similar thing in Jibx where all of the incoming message objects implement a base interface which has a field denoting the message type.
The text/xml is serialized into the base interface and I then used the command pattern to call the respective business logic depending upon the message type which is defined in the base interface.
Not sure if this is possible using castor but take a look at Jibx as the performance is fantastic.
http://jibx.sourceforge.net/
我很欣赏你的见解。你们都给了我一些很好的信息和我没有的新知识。最后，我通过 hack 使该过程得以运行。我抓取文本流，解析出消息的根标签，然后打开它以确定要创建的正确对象。我正在独立整理我的所有对象，每个人都对我们感到满意。
I appreciate your insights. You both have given me some good information to go on and new knowledge that I didn't have. In the end, I got the process to work via a hack. I grab the text stream, parse out the root tag of the message, and then switch on it to determine the right object to create. I'm unmarshalling all of my objects independently and everyone is happy on our end.