现在参与的项目是一个纯 Application Server ，整个 Server 都是自己搭建的，使用 JMS 消息实现客户端和服务器的交互，交互的数据格式采用 XML 。说来惭愧，开始为了赶进度，所有 XML 消息都是使用字符串拼接的，而 XML 的解析则是使用 DOM 方式查找的。我很早就看这些代码不爽了，可惜一直没有时间去重构，最近项目加了几个人，而且美国那边也开始渐渐的把这个项目开发的控制权交给我们了，所以我开始有一些按自己的方式开发的机会了。因而最近动手开始重构这些字符串拼接的代码。

对 XML 到 Java Bean 的解析框架，熟悉一点的只有 Digester 和 XStream ， Digester 貌似只能从 XML 文件解析成 Java Bean 对象，所以只能选择 XStream 来做了，而且同组的其他项目也有在用 XStream 。一直听说 XStream 的使用比较简单，而且我对 ThoughtWorks 这家公司一直比较有好感，所以还以为引入 XStream 不会花太多时间，然而使用以后才发现 XStream 并没有想象的你那么简单。不过这个也有可能是因为我不想改变原来的 XML 数据格式，而之前的 XML 数据格式的设计自然不会考虑到如何便利的使用 XStream 。因而记录在使用过程中遇到的问题，供后来人参考，也为自己以后如果打算开其源码提供参考。废话就到这里了，接下来步入正题。

首先对于简单的引用， XStream 使用起来确实比较简单，比如自定义标签的属性、使用属性和使用子标签的定义等：

@XStreamAlias( " request " )
public class XmlRequest1 {
private static XStream xstream;
static {
xstream = new XStream();
xstream.autodetectAnnotations( true );
}

@XStreamAsAttribute
private String from;

@XStreamAsAttribute
@XStreamAlias( " calculate-method " )
private String calculateMethod;

@XStreamAlias( " request-time " )
private Date requestTime;

@XStreamAlias( " input-files " )
private List < InputFileInfo > inputFiles;

public static String toXml(XmlRequest1 request) {
StringWriter writer = new StringWriter();
writer.append(Constants.XML_HEADER);
xstream.toXML(request, writer);
return writer.toString();
}
public static XmlRequest1 toInstance(String xmlContent) {
return (XmlRequest1)xstream.fromXML(xmlContent);
}

@XStreamAlias( " input-file " )
public static class InputFileInfo {
private String type;
private String fileName;

}
public static void main(String[] args) {
XmlRequest1 request = buildXmlRequest();
System.out.println(XmlRequest1.toXml(request));
}
private static XmlRequest1 buildXmlRequest() {

}
}

对以上 Request 定义，我们可以得到如下结果：

可惜这个世界不会那么清净，这个格式有些时候貌似并不符合要求，比如 request-time 的格式、 input-files 的格式，我们实际需要的格式是这样的：

对不同 Date 格式的支持可以是用 Converter 实现，在 XStream 中默认使用自己实现的 DateConverter ，它支持的格式是： yyyy-MM-dd HH:mm:ss.S 'UTC' ，然而我们现在需要的格式是 yyyy-MM-dd’T’HH:mm:ss ，如果使用 XStream 直接注册 DateConverter ，可以使用配置自己的 DateConverter ，但是由于 DateConverter 的构造函数的定义以及 @XStreamConverter 的构造函数参数的支持方式的限制，貌似 DateConverter 不能很好的支持注解方式的注册，因而我时间了一个自己的 DateConverter 以支持注解：

在 requestTime 字段中需要加入以下注解定义：

对集合类， XStream 提供了 @XStreamImplicit 注解，以将集合中的内容摊平到上一层 XML 元素中，其中 itemFieldName 的值为其使用的标签名，此时 InputFileInfo 类中不需要 @XStreamAlias 标签的定义：

对 InputFileInfo 中的字段， type 作为属性很容易，只要为它加上 @XStreamAsAttribute 注解即可，而将 fileName 作为 input-file 标签的一个内容字符串，则需要使用 ToAttributedValueConverter ，其中 Converter 的参数为需要作为字符串内容的字段名：

@XStreamConverter(value = ToAttributedValueConverter. class , strings = { " fileName " })
public static class InputFileInfo {
@XStreamAsAttribute
private String type;
private String fileName;

}

XStream 对枚举类型的支持貌似不怎么好，默认注册的 EnumSingleValueConverter 只是使用了 Enum 提供的 name() 和静态的 valueOf() 方法将 enum 转换成 String 或将 String 转换回 enum 。然而有些时候 XML 的字符串和类定义的 enum 值并不完全匹配，最常见的就是大小写的不匹配，此时需要写自己的 Converter 。在这种情况下，我一般会在 enum 中定义一个 name 属性，这样就可以自定义 enum 的字符串表示。比如有 TimePeriod 的 enum ：

我们可以编写以下 Converter 以实现对枚举类型的更宽的容错性：

如下方式使用即可：

对 double 类型，貌似默认的 DoubleConverter 实现依然不给力，它不支持自定义的格式，比如我们想在序列化的时候用一下格式： ” ###,##0.0######## ” ，此时又需要编写自己的 Converter ：

使用方式和之前的 Converter 类似：

最后，还有两个 XStream 没法实现的，或者说我没有找到一个更好的实现方式的场景。 第一种场景是 XStream 不能很好的处理对象组合问题：

在面向对象编程中，一般尽量的倾向于抽取相同的数据成一个类，而通过组合的方式构建整个数据结构。比如 Student 类中有 name 、 address ， Address 是一个类，它包含 city 、 code 、 street 等信息，此时如果要对 Student 对象做如下格式序列化：

貌似我没有找到可以实现的方式， XStream 能做是在中间加一层 address 标签。对这种场景的解决方案，一种是将 Address 中的属性平摊到 Student 类中，另一种是让 Student 继承自 Address 类。不过貌似这两种都不是比较理想的办法。

第二种场景是 XStream 不能很好的处理多态问题：

比如我们有一个 Trade 类，它可能表示不同的产品：

public class Trade {
private String tradeId;
private Product product;

}
abstract class Product {
private String name;
public Product(String name) {
this .name = name;
}

}
class FX extends Product {
private double ratio;
public FX() {
super ( " fx " );
}

}
class Future extends Product {
private double maturity;
public Future() {
super ( " future " );
}

}

通过一些简单的设置，我们能得到如下 XML 格式：

作为数据文件，对 Java 类的定义显然是不合理的，因而简单一些，我们可以编写自己的 Converter 将 class 属性从 product 中去除：

在所有 Production 上定义 @XStreamAlias(“product”) 注解。这时的 XML 输出结果为：

然而如果有人希望 XML 的输出结果如下呢 ?

大概找了一下，可能可以定义自己的 Mapper 来解决，不过 XStream 的源码貌似比较复杂，没有时间深究这个问题，留着以后慢慢解决吧。