Apache+Tomcat+jk：在 Java EE Web 应用程序中提供静态资源
我最近安装了 Apache w/s + Tomcat 并使用 jk 能够将请求从 apache 路由到 t/c。网上的例子通常采用以下形式：
JkMount /*.jsp myTC
我们有几个 Java EE 应用程序运行在单个 tomcat 实例上（那么为什么要使用 apache？相信我，我有理由）。我想我们可以将每个应用程序的上下文更改为以下内容：
/servlet/application1/
/servlet/application2/
/servlet/application3/
然后有类似的内容：
JkMount /servlet/* myTC
这会将请求正确路由到 tomcat，但是，问题仍然是如何为标准 Java EE 应用程序提供静态资源
/webapp-root
resources/
css/
js/
images/
WEB-INF/
/usual-folder-structure
：是：
如何从 apache 提供资源/文件夹？所有应用程序都有自己的资源/文件夹。我认为 resources/ 必须驻留在战争之外并位于 apache 的文档根目录中的某个位置，但无法找出 JkMount 字符串。
/servlet/ 方案是“正确”的方法吗？我应该遵循哪些模式？
我将不胜感激任何帮助，任何指向网上资源的指针都会很棒，因为我需要阅读更多有关此内容的内容。
I recently installed Apache w/s + Tomcat and using jk was able to route requests from apache to t/c. The examples on the net are usually of the form:
JkMount /*.jsp myTC
We have several Java EE applications running on a single instance of tomcat (then why use apache? believe me i have reasons). I figured we could change the context for each of those applications to something like:
/servlet/application1/
/servlet/application2/
/servlet/application3/
and then have something like:
JkMount /servlet/* myTC
This would route the requests to tomcat correctly, however, the question remains how to serve static resources for a standard Java EE application:
/webapp-root
resources/
css/
js/
images/
WEB-INF/
/usual-folder-structure
The questions are:
How to serve resources/ folder from apache? all the applications have their own resources/ folder. I figure resources/ will have to reside 'out' of the war and on apache's doc-root somewhere, but can't figure out the JkMount string.
Is the /servlet/ scheme the 'correct' way to do it? are there patterns I should follow?
I'll appreciate any help, any pointers to resources on the net would be great as I need to read a lot more about this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
(1) 以下内容就足够了：
(2) 没问题。有很多正确的解决方案。我个人不喜欢 URL 中的 /servlet/ 。这是垃圾，尤其是在这个 URL 是网站/网络应用程序资产的时代。我使用这个方案：
(1) The following should be enough:
(2) It's OK. There are many correct solutions. I personally don't like /servlet/ in the URL. It's garbage, especially in this age where URLs are an asset of a website/webapp. I use this scheme: