10

假设以下应用程序环境：

+-----------------+
| App server      |
+-----------------+
|                 |                                   +-------+
| ear1            |                                   |       |
|  +-web1 (/ctx1) +--<-- http://localhost/ctx1/xxx/ --+       +--<-- http://www.example.com/xxx/
|                 |                                   |       |
|                 |                                   | proxy |
| ear2            |                                   |       |
|  +-web2 (/ctx2) +--<-- http://localhost/ctx2/yyy/ --+       +--<-- http://abc.example.com/yyy/
|                 |                                   |       |
+-----------------+                                   +-------+

如您所见，代理（nginx在我的例子中）将请求转发到单个应用程序服务器实例，该实例又具有多个具有不同上下文路径的 Web 模块。当然我不希望我的公共服务器暴露内部上下文根和代理它的工作是否很好，包装和解包http请求等。但仍然存在一个大问题：JSF生成的html代码（链接，css，js资源，表单actions) 包含上下文路径，/ctx1在/ctx2我的例子中。这就是我想要避免的。

除了使用越来越多不同的应用程序服务器实例（域）之外，我目前没有任何解决方案，导致我的硬件资源逐渐消失。据我了解，我需要使用一些可能在 中注册的包装器来扩展我的 JSF 应用程序faces-config.xml，这将删除生成的 html 中的上下文前缀。也欢迎任何其他解决方案。

请指出我正确的方向。

4

3 回答 3

7

我正在发布解决方案，这可能对面临同样问题的其他人有所帮助。我需要做的就是实现我自己的javax.faces.application.ViewHandler并将其注册到faces-config.xml：

public class CustomViewHandler extends ViewHandlerWrapper {
  private ViewHandler wrappped;

  public CustomViewHandler(ViewHandler wrappped) {
    super();
    this.wrappped = wrappped;
  }

  @Override
  public ViewHandler getWrapped() {
    return wrappped;
  }

  @Override
  public String getActionURL(FacesContext context, String viewId) {
    String url =  super.getActionURL(context, viewId);
    return removeContextPath(context, url);
  }

  @Override
  public String getRedirectURL(FacesContext context, String viewId, Map<String, List<String>> parameters, boolean includeViewParams) {
    String url =  super.getRedirectURL(context, viewId, parameters, includeViewParams);
    return removeContextPath(context, url);
  }

  @Override
  public String getResourceURL(FacesContext context, String path) {
    String url = super.getResourceURL(context, path);
    return removeContextPath(context, url);
  }

  private String removeContextPath(FacesContext context, String url) {
    ServletContext servletContext = (ServletContext) context.getExternalContext().getContext();
    String contextPath = servletContext.getContextPath();
    if("".equals(contextPath)) return url; // root context path, nothing to remove
    return url.startsWith(contextPath) ? url.substring(contextPath.length()) : url;
  }
}

面孔-config.xml：

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
              version="2.0">
  <application>
    <view-handler>test.CustomViewHandler</view-handler>
  </application>
</faces-config>
于 2012-03-29T11:39:56.457 回答
7

您可以为此使用OCPsoft Rewrite URLRewriteFilter（目前不是 PrettyFaces，但您可以同时使用它们，直到它们在 PrettyFaces 4 发布后正式结合在一起 - Rewrite 是 PrettyFaces 4 的核心项目）

使用单个配置规则执行此类操作应该相当简单。如果这条规则太严格或太笼统，你显然可以摆弄。

.defineRule()
.when(URL.matches("{prefix}" + context.getContextPath() + "{suffix}")
.perform(Substitute.with("{prefix}{suffix}"))

查看重写站点。这很容易设置。http://ocpsoft.org/rewrite/

于 2012-03-29T18:51:17.613 回答
1

我遇到了同样的问题并尝试了您的解决方案。虽然它或多或少地工作，但仍然存在一些小故障。老实说，感觉更像是对抗症状而不是治愈疾病。

所以这就是最终对我有用的东西：

我没有通过路径将部署分开，而是将每个部署分配到自己的端口：

foo.war <-- http://localhost:8080/ -- | Proxy | <-- http://www.foo.com -- | Client |
bar.war <-- http://localhost:8181/ -- | Proxy | <-- http://www.bar.com -- | Client |

这样，两个部署都可以使用 / 作为其上下文路径，因此无需编辑上下文路径。

要实现这一点，您不必运行两个应用程序服务器。在我的例子中（Wildfly 10.0），在 wildfly 配置中定义两个 undertow 服务器就足够了，每个服务器都有自己的虚拟主机和 http 侦听器，如下所示：

<server name="foo-server">
   <http-listener name="foo-listener" proxy-address-forwarding="true" socket-binding="foo-http"/>
   <host name="foo-host" default-web-module="foo.war" alias="localhost, foo.com, wwww.foo.com"/>
</server>
<server name="bar-server">
   <http-listener name="bar-listener" proxy-address-forwarding="true" socket-binding="bar-http"/>
   <host name="bar-host" default-web-module="bar.war" alias="localhost, bar.com, wwww.bar.com"/>
</server>

<socket-binding name="foo-http" port="${jboss.http.port:8080}"/>
<socket-binding name="bar-http" port="${jboss.http.port:8181}"/>

你的项目中还需要一个 jboss-web.xml：

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
   <server-instance>foo-server</server-instance>
   <virtual-host>foo-host</virtual-host>
   <context-root>/</context-root>
</jboss-web>

需要这两个服务器，因为您无法将套接字绑定添加到虚拟主机。所以这里有一点点开销，但与运行两个完整的应用程序服务器相比可以忽略不计。

编辑1：

我突然想到，甚至可能没有必要使用不同的端口，而且每个部署使用一个 undertow 服务器也可能是多余的。

由于代理能够将客户端请求的主机转发到应用服务器，undertow 应该能够通过别名参数挑选出合适的虚拟主机。

所以基本上，代理会将任何对 foo.com 或 bar.com 的请求中继到 localhost:8080 并让 AS 解决问题。

我没有对此进行测试，但它是如何工作的（同样，这是针对 Wildfly 10.0）：

<server name="default-server">
   <http-listener name="http" proxy-address-forwarding="true" socket-binding="http"/>
   <host name="foo-host" default-web-module="foo.war" alias="foo.com, wwww.foo.com"/>
   <host name="bar-host" default-web-module="bar.war" alias="bar.com, wwww.bar.com"/>
</server>

jboss-web.xml 会丢失服务器标签：

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
   <virtual-host>foo-host</virtual-host>
   <context-root>/</context-root>
</jboss-web>

如果这可行，则根本不会涉及任何开销。

编辑2：

刚刚测试了简化的方法 - 是的，它有效:)

于 2017-02-23T17:11:04.793 回答