准备好了 XML 和 XML Schema,生成 JAXB 类就很简单了。确认已设置好命令行和环境,然后输入以下命令:
1
|
xjc -p com.ibm.dw guitars.xsd -d src
|
一定要在和 guitars.xsd文件相同的目录中执行上述命令,并且在工作目录中建立一个 src目录。如果没有按这些步骤操作,就会出现某种 java.io.IOException 错误。否则应该能看到一长串的输出结果,如清单 3 所示。
清单 3. JAXB 类生成的输出结果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
C:\developerworks>xjc -p com.ibm.dw guitars.xsd -d src
parsing a schema...
compiling a schema...
com\ibm\dw\impl\runtime\MSVValidator.java
com\ibm\dw\impl\runtime\SAXUnmarshallerHandlerImpl.java
com\ibm\dw\impl\runtime\ErrorHandlerAdaptor.java
com\ibm\dw\impl\runtime\AbstractUnmarshallingEventHandlerImpl.java
com\ibm\dw\impl\runtime\UnmarshallableObject.java
com\ibm\dw\impl\runtime\SAXMarshaller.java
com\ibm\dw\impl\runtime\XMLSerializer.java
com\ibm\dw\impl\runtime\ContentHandlerAdaptor.java
com\ibm\dw\impl\runtime\UnmarshallingEventHandlerAdaptor.java
com\ibm\dw\impl\runtime\SAXUnmarshallerHandler.java
com\ibm\dw\impl\runtime\ValidatorImpl.java
com\ibm\dw\impl\runtime\ValidatableObject.java
com\ibm\dw\impl\runtime\UnmarshallerImpl.java
com\ibm\dw\impl\runtime\NamespaceContext2.java
com\ibm\dw\impl\runtime\Discarder.java
com\ibm\dw\impl\runtime\NamespaceContextImpl.java
com\ibm\dw\impl\runtime\ValidatingUnmarshaller.java
com\ibm\dw\impl\runtime\UnmarshallingContext.java
com\ibm\dw\impl\runtime\GrammarInfoImpl.java
com\ibm\dw\impl\runtime\ValidationContext.java
|
实在是有点太多了--注意,即使对于一个相当简单的 XML Schema,JAXB 也创建了 大量的类。
对往返的影响
现在我已经介绍了基本的步骤,下面将实际分析一下其中到底发生了什么。不必浪费时间回顾 JAXB 的基础(其他文章已经做了很好的介绍),对于每个元素都有两个源文件,一个文件和元素同名(比如,Guitar.java),另一个则在元素名后面加上 “Type”(如 GuitarType.java)。这两个文件都是接口,类的实现在子目录 impl 下。这样就生成了很多类--我认为有点太过分了。
但真正有意思的是这些类本身。要知道数据绑定实现的主要问题之一是往返--即从 XML 到 Java 代码再返回到 XML 的过程中数据不会发生不可预料的变化的能力。换句话说,进去的是什么出来的就是什么。在目前,您还没有准备好通过解组-编组循环测试输出的结果(尽管以后要这样做),首先来分析源代码中可能存在的潜在问题。
第一个问题出现在任何数据绑定软件包通常都会出问题的地方:类型化。即使有 XML Schema 的帮助,XML 也不一定能和 Java 类型很好的匹配。这通常意味着要损失一些数据类型信息,有可能掺入非法的数据。有时候问题出在 XML Schema 中,有时候则是因为 XML 到 Java 映射的局限性,必须仔细观察。源代码中发现的一个此类问题是 top 元素的表示。注意清单 4 中粗体显示的那一行,这是 TopType 类的源代码。
清单 4. TopType.java 的源代码
1
2
3
4
5
6
7
8
|
package com.ibm.dw;
public interface TopType {
java.lang.String getValue();
void setValue(java.lang.String value);
java.lang.String getBearclaw();
void setBearclaw(java.lang.String value);
}
|
回头再看一看源文档及其 XML Schema,很明显 bearclaw 属性的值应该是“true”或“false”。不幸的是,JAXB 没有发现这一点并使用布尔数据类型, TopType 类的这个属性可以接受任何字符串值。结果可能造成错误的数据。最终可能出现“True”、“true”、“tRUe”或者任何其他变化形式,而令使用 XML 的应用程序举止失措。换句话说,您碰到了必须解决的一个问题域。
这类问题可能有以下不同的解决办法:
手工编辑 TopType 类的源代码,只接受布尔值。
向 TopType 方法中手工添加异常处理代码,保证只能提供可以转化成布尔值的字符串。
在 XML Schema 中创建表达布尔数据类型的新类型。
前两种选择非常明显。第三种选择也很简单,尽管 W3C 那帮人实际上应该把这一条放在规范中说明。清单 5 给出了一个简单的布尔类型定义: