非静态webapp别名

时间:2015-04-01 21:27:32

标签: java web-services tomcat web-applications

我想知道,如果有一个干净的方式让一个webapp应答请求,其名称没有出现在请求URL中。在某种程度上,url应该是webapp的别名。此外,别名不应该是静态的或使用这个单一的webapp固定,而是我需要能够轻松地更改别名后面的webapp以获得版本增量。 我想到的事情是

  • 构建“facade”webapp以重定向请求
  • 重命名完整的webapp

这两种想法都没有达到预期的效果。我想有一个更轻量级的解决方案。

这可能吗?

2 个答案:

答案 0 :(得分:1)

如果您只想使用tomcat进行操作,则可以静态映射定义上下文的tomcat context.xml中的webapp路径,并将request path(“路径”)映射到{{1} (“docBase”)。

只需将其添加到webapp dir

即可
<tomcatDir>/conf/context.xml

这有副作用,当然,你只能有一个webapp,因为每个请求和<Context path="" docBase="/<pathToYourWebapp>/<yourApp>" /> 都映射到你的webapp。

有关详细信息,请参阅http://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Common_Attributes

答案 1 :(得分:1)

感谢亚历山大的帖子,我发现了正确的轨道,但我使用了一些额外的工作,这或多或少是我原来问题中第1点中提到的外观webapp。我将向所有感兴趣的人展示我的整个方法:

首先,我在/tomcat/webapps部署了所有标准的网络应用程序,并启用了一个标准context.xmlautoDeploy模式。为了捕获与其中一个已部署的上下文不匹配的所有其他请求,我设置了一个新的webapp,它作为不匹配请求的默认webapp。我们称之为dispatcher-app

要使这个工作,我必须将其设置为ROOT。要以原始名称进行部署,我将其放在/tomcat/webapps2及其context.xml /tomcat/conf/Catalina/localhost/ROOT.xml下的/webapps下。必须将它放在ROOT.xml之外,以防止在使用用于其他webapps的autoDeploy模式的tomcat中进行双重部署。有关详细信息,请访问:http://tomcat.apache.org/tomcat-7.0-doc/config/context#Naming

<Context path="" docBase="/path/to/tomcat-base/webapps2/dispatcher-app" crossContext="true" /> 看起来像这样:

dispatcher-app

<servlet-mapping> <url-pattern>/</url-pattern> </servlet-mapping> 的web.xml中确保使用

dispatcher-app

uriInfo.getAbsolutePath()内部查找用户使用myserver/webapp-1/test?param=value请求的原始路径。然后,它将来自url的应用程序与在tomcat中运行的应用程序(从自定义配置文件中获知)进行匹配。如果匹配,则配置文件知道应该向哪个应用程序转发。例如,用户请求myserver/webapp-1.1.2/test?param=value,并转发到RequestDispatcher dispatcher=servletContext.getRequestDispatcher(redirectTo); dispatcher.forward(request, response); 。如果应用程序版本发生变化,可以在配置文件中手动更新要转发的Web应用程序。

应使用

进行实际转发
return Response.status(307).location(new URI(redirectTo)).build();

因为用户无法看到转发。

由于我无法进行此操作(请参阅Cross-context request forwarding in tomcat results in java.lang.ClassCastException: org.glassfish.jersey.message.internal.TracingLogger),我现在只使用307重定向。

RequestDispatcher

这个的缺点是,浏览器会在地址栏中显示重定向网址。

<强>更新 realm现在正常工作,而不是上面提到的这个特殊情况/ webapp。所以我更倾向于重定向方法。

需要注意的一点是,第二个webapp上的基于容器的身份验证(例如dispatcher-app)将无法生效(因为我们在前面&#39;后面的tomcat外观)所以{ {1}}本身需要身份验证方法,或者需要使用其他机制进行身份验证,例如RequestFilter