现代应用程序开发的一个重要主题是重写。 自从Java Server Faces引入和Java EE 6中新的轻量级编程模型以来，您一直在努力使用漂亮，简单，可添加书签的URL。 PrettyFaces很久以来就一直存在，即使它在3.3.3版本中可以说是成熟的，我也不敢相信。

主要是因为我必须在xml中配置它。 如果您曾经做过JSF项目，那么您就会知道这是您稍后要做的事情。 或永远不会。 最后一个选项是我看到的很多东西。 重写将改变这一点。 程序化，易于使用和高度可定制的。 正是我想要的。

入门

从其中一个RedHat家伙那里获得的东西入门非常容易。 启动NetBeans，创建一个新的基于Maven的Webapp，将JSF和Primefaces添加到混合中并在GlassFish上运行。 向应用程序添加重写魔术的第一步是向项目添加重写依赖项。

<dependency><groupId>org.ocpsoft.rewrite</groupId><artifactId>rewrite-servlet</artifactId><version>1.1.0.Final</version></dependency>

这还不够，因为我将它与JSF一起使用，您还需要jsf-integration。

<dependency><groupId>org.ocpsoft.rewrite</groupId><artifactId>rewrite-integration-faces</artifactId><version>1.1.0.Final</version></dependency>

接下来实现您自己的ConfigurationProvider。 这是发生大多数魔术的核心部分。现在我们将其称为TricksProvider，我们还将扩展抽象的HttpConfigurationProvider。 一个简单的第一个版本如下所示：

public class TricksProvider  extends HttpConfigurationProvider
{@Overridepublic int priority(){return 10;}@Overridepublic Configuration getConfiguration(final ServletContext context){return ConfigurationBuilder.begin().addRule(Join.path("/").to("/welcomePrimefaces.xhtml"));}
}

现在，您必须注册您的ConfigurationProvider。 为此，您可以在应用程序/ META-INF / services /文件夹中添加一个名为org.ocpsoft.rewrite.config.ConfigurationProvider的简单文本文件。 向其添加ConfigurationProvider实现的标准名称，即可完成操作。 如果您启动应用程序。

重写基础

复制上述提供程序时，您隐式添加了第一个重写规则。 通过请求http：// host：8080 / yourapp /，您将直接转到NetBeans生成的Primefaces欢迎页面。 所有规则都基于相同的原则。 每个规则都由一个条件和一个运算组成。 类似“如果发生X，则执行Y”。 重写知道两种不同的规则。 一些预配置的（加入）以“ addRule（）”开头，而流畅的接口以defineRule（）开头。 这有点令人困惑，因为下一个主要版本将弃用defineRule（）并将其重命名为addRule（）。 因此，您发现的大多数示例（尤其是最新主干中的测试用例）都无法在1.1.0.Final中使用。 重写知道两个不同的方向。 入站和出站。 入站很有可能像您知道的每个重写引擎（例如mod_rewrite）一样工作。 请求到达并被转发或重定向到规则中定义的资源。 出站方向几乎没有。 它基本上在HttpServletRequest的encodeURL（）方法中具有一个钩子，并重写您页面中的链接（如果它们完全是在encodeURL的帮助下呈现的）。 JSF开箱即用。 如果您打算将其与JSP一起使用，则必须确保自己调用它。

用一些魔法将.html转发到.xhtml

让我们看一下您可以用重写做的一些事情。 首先，我们将以下内容添加到TricksProvider中：

.defineRule()
.when(Direction.isInbound()
.and(Path.matches("{name}.html").where("name").matches("[a-zA-Z/]+")))
.perform(Forward.to("{name}.xhtml"));

这是一条规则，用于检查入站请求，并检查所有与正则表达式模式[a-zA-Z /] +确认的补丁匹配{name} .html，并将其转发到{name} .xhtml文件。

如果执行此规则，则对http：// host：8080 / yourapp / something.html的所有请求最终都将转发到something.xhtml。 现在，您的用户将不再知道您在下面使用的是花哨的JSF内容，并认为您正在使用html :)如果请求的URL与正则表达式不匹配，例如类似http：// host：8080 / yourapp / something123.html根本不会转发，如果您的应用程序中不存在something123.html，您最终将收到404错误。

改写出站链接

相反，您还可以添加以下规则：

.defineRule()
.when(Path.matches("test.xhtml")
.and(Direction.isOutbound()))
.perform(Substitute.with("test.html"))

你想像这是在做什么，对吗？ 如果您的facelet包含以下内容：

<h:outputLink value="test.xhtml">Normal Test</h:outputLink>

呈现给用户的链接将被重写为test.html。 这是您永远需要的出站链接的最基本操作。 大多数魔术都发生在入站链接上。 看到encodeURL（）挂钩的作用范围非常有限，这并不让人感到意外。

OutputBuffer

重写中最令人惊讶的东西称为OutputBuffer。 至少直到我们正在使用的发行版为止。 它会在2.0中重命名，但现在让我们简单地看一下您可以做什么。 OutputBuffer是您对响应的了解。 在响应真正到达客户浏览器之前，您想对响应做什么。 考虑转换标记？ 转换CSS？ 甚至GZIP压缩？ 太好了，这正是您所能做的。 让我们实现一个简单的ZipOutputBuffer

public class ZipOutputBuffer implements OutputBuffer {private final static Logger LOGGER = Logger.getLogger(ZipOutputBuffer.class.getName());@Overridepublic InputStream execute(InputStream input) {String contents = Streams.toString(input);LOGGER.log(Level.FINER, "Content {0} Length {1}", new Object[]{contents, contents.getBytes().length});byte[] compressed = compress(contents);LOGGER.log(Level.FINER, "Length: {0}", compressed.length);return new ByteArrayInputStream(compressed);}public static byte[] compress(String string) {ByteArrayOutputStream os = new ByteArrayOutputStream(string.length());byte[] compressed = null;try {try (GZIPOutputStream gos = new GZIPOutputStream(os)) {gos.write(string.getBytes());} compressed = os.toByteArray();os.close();} catch (IOException iox) {LOGGER.log(Level.SEVERE, "Compression Failed: ", iox);}return compressed;}
}

如您所见，我在弄乱一些流，并使用java.util.zip.GZIPOutputStream缩小通过此方法接收的流。 接下来，我们必须将相关规则添加到TricksProvider中：

.defineRule()
.when(Path.matches("/gziptest").and(Direction.isInbound()))
.perform(Forward.to("test.xhtml")
.and(Response.withOutputBufferedBy(new ZipOutputBuffer())
.and(Response.addHeader("Content-Encoding", "gzip"))
.and(Response.addHeader("Content-Type", "text/html"))))

入站规则（我们不愿意在此处重写页面中的链接..因此必须入站），该规则将ZipOutputBuffer添加到Response中。 还要注意额外的响应标头（两个），除非您想让浏览器抱怨我混在一起的内容:)就是这样。 现在，请求http：// host：8080 / yourapp / gziptest提供了具有GZIP压缩功能的te​​st.xhtml。 那是2,6KB和1.23 KB！ 不到尺寸的一半！ 使用流和byte []并不是很方便。 而且我不确定这是否可以在较大的页面大小上使用内存碎片，但是如果您没有压缩过滤器或者只需要压缩应用程序的单个部分，这是一个简单的解决方法。

通过重写增强安全性

但这还不是您能做的：您还可以通过重写来增强安全性。 林肯发表了关于用重写保护您的应用程序的精彩文章。 关于如何使用此功能，有很多可能的示例。 我想到了一个用例，其中不想使用欢迎文件功能，而是希望单独分派用户。 在执行此操作时，我还将检查他们的路径，并检查他们输入的内容是否恶意。 您可以使用.matches（）条件或使用自定义约束来执行此操作。 将以下内容添加到TricksProvider中：

Constraint<String> selectedCharacters = new Constraint<String>() {@Overridepublic boolean isSatisfiedBy(Rewrite event,EvaluationContext context, String value) {return value.matches("[a-zA-Z/]+");}};

并定义以下规则：

.defineRule()
.when(Direction.isInbound()
.and(Path.matches("{path}").where("path").matches("^(.+)/$")
.and(Path.captureIn("checkChar").where("checkChar").constrainedBy(selectedCharacters))))
.perform(Redirect.permanent(context.getContextPath() + "{path}index.html"))

另一个入站修改。 检查路径是否具有文件夹模式，并将其捕获到根据自定义约束进行检查的变量中。 大！ 现在，您已经有了保存和轻松转发的机制。 现在，所有http：// host：8080 / yourapp / folder /请求都被重写为http：// host：8080 / yourapp / index.html。 如果您从上方查看其他规则，那么.html将被转发到.xhtml……，您就完成了！

底线

我非常喜欢重写。 与配置prettyfaces的xml文件相比，这感觉要容易得多，在使用林肯和Christian的第一步中，我真的很享受Lincoln和Christian的支持。 我很好奇2.0即将推出的产品，我希望我能为规则配置获得更多调试输出，以便了解正在发生的事情。 默认值是空，并且找到具有工作规则的条件的正确组合可能非常棘手。 寻找完整的资源？ 在github上找到它们 。 很高兴阅读您的经历。

GlassFish部分在哪里？

哦耶。 我在标题中提到了吧？ 那应该更像是默认值。 我正在使用最新的GlassFish 3.1.2.2运行所有程序，因此可以确保它可以正常运行。 NetBeans目前为7.2 ，如果尚未尝试，则应尝试一下。 我没有遇到任何与GlassFish相关的问题，我很高兴在此强调这一点。 做得好！ 最后一句话：在疯狂地实现OutputBuffer之前，请看一下您最喜欢的应用服务器所拥有的库存。 GlassFish已经了解GZIP压缩 ，因此可以将其打开！ 在这里实施之前，请三思而后行是一个好主意。

参考： 重写边缘-充分利用它！ 在GlassFish上！ 来自我们的JCG合作伙伴 Markus Eisele在Java的企业软件开发博客中。