JAXB 2的ObjectFactory类有什么意义？
我是使用JAXB的新手，并且使用JAXB
2.1.3的xjc从我的XML模式生成一组类。除了为我的架构中的每个元素生成一个类之外，它还创建了一个ObjectFactory类。
似乎没有什么阻止我直接实例化元素的，例如
MyElement element = new MyElement();
而教程似乎更喜欢
MyElement element = new ObjectFactory().createMyElement();
如果查看ObjectFactory.java，我会看到：
public MyElement createMyElement() {
return new MyElement();
}
那怎么办？为什么我还要麻烦保持ObjectFactory类？我假设如果我从更改后的模式重新编译，它也会被覆盖。
问题答案：
向后兼容性不是唯一原因。:-P
对于更复杂的模式，例如对元素内容可以采用的值具有复杂约束的模式，有时您需要创建实际JAXBElement对象。通常，手工创建它们并不容易，因此这些create*方法为您完成了艰巨的工作。示例（来自XHTML
1.1模式）：
@XmlElementDecl(namespace = "http://www.w3.org/1999/xhtml", name = "style", scope = XhtmlHeadType.class)
public JAXBElement<XhtmlStyleType> createXhtmlHeadTypeStyle(XhtmlStyleType value) {
return new JAXBElement<XhtmlStyleType>(_XhtmlHeadTypeStyle_QNAME, XhtmlStyleType.class, XhtmlHeadType.class, value);
}
这是将<style>标签放入<head>标签的方法：
ObjectFactory factory = new ObjectFactory();
XhtmlHtmlType html = factory.createXhtmlHtmlType();
XhtmlHeadType head = factory.createXhtmlHeadType();
html.setHead(head);
XhtmlStyleType style = factory.createXhtmlStyleType();
head.getContent().add(factory.createXhtmlHeadTypeStyle(style));
ObjectFactory可以认为前三个用途是多余的（尽管对于一致性很有用），但是第四个用途使JAXB变得非常容易使用。成像new JAXBElement每次都要手工写出来！
-
问题内容： 这可能是一个愚蠢的问题，但这不是在我的脑海中点击。 在Django中，惯例是将特定于应用程序的所有静态文件（即css，js）放入名为static的文件夹中。所以结构看起来像这样： 在我有： 因此，当我运行命令时： 它会在根目录下创建一个文件夹（与相同的目录myapp/） 这有什么意义呢？它不只是创建我所有静态文件的副本吗？ 问题答案： 将来自多个应用程序的静态文件收集到一个路径中 那么
-
在GlassFish Server开源版本3.1中部署。1（构建12）： 引起原因：java.security.PrivilegedActionExcema：com.sun.xml.bind.v2.runtime.IllegalAnnotationsExceptions： 1个IllegalAnnotationExceptions的计数没有ObjectFactory与@XmlElementDecl
-
问题内容： 如果我已经在大多数主流浏览器中测试过我的页面，为什么我需要维护一个经过验证的代码？如果WebKit浏览器和Firefox支持框阴影和拐角半径，我想使用它们。我不在乎它们是否不会出现在Internet Explorer中。但是我通过不包含图像来降低HTTP请求的数量。 有效代码是否有优势？在搜索引擎优化还是其他方式？ 问题答案： Google更喜欢它，因此对SEO很有好处。 它使您的网页
-
当我可以只调用文件并执行完全相同的操作时，创建一个类对象来调用另一个文件中的方法有什么意义？ 我所看到和学到的是，为了从另一个文件调用一个方法，您需要首先创建一个类对象，然后使用该对象调用该方法 假设您在“文件Two”中有一个方法 所以，如果我想在另一个文件中调用“方法”，我会这样调用它 但是我可以通过调用文件本身来做同样的事情 那么创建类对象有什么意义呢？
-
我遇到了一些实现的类代码，文档中写道： 类实现Cloneable接口，以向object.clone（）方法表明，该方法对该类的实例进行字段对字段的复制是合法的。在未实现可克隆接口的实例上调用对象的克隆方法会导致引发异常CloneNotSupportedException。按照约定，实现此接口的类应该使用公共方法重写Object.clone（受保护）。有关重写此方法的详细信息，请参见object.c
-
在Apache Tomcat中，参数URIEncoding告诉Tomcat如何解释传入的URI： 编码 这指定在%xx解码URL后用于解码URI字节的字符编码。如果没有规定，将使用ISO-8859-1。 Apache Tomcat 7-HTTP连接器 然而，正如在URL编码Unicode字符的正确方法是什么中所解释的那样，URI中的非ASCII字符始终按照当前标准（RFC 3986和3987）以U