cho*_*603 6 java web-applications java-ee
如果多个Web应用程序需要一个jar文件,那么您会选择哪个选项？将它保存在服务器类路径中还是为每个Web应用程序的lib文件夹保留jar文件的一个副本？
从技术上讲，这取决于它是什么类型的 JAR 文件，通常您只有一个选择。
如果它是基于 Java EE 的“Web 片段”JAR 文件，可通过包含Web 内容文件（JSP/CSS/JS/等）的/META-INF/web-fragment.xml文件和/或 ,/META-INF/faces-config.xml和/或/META-INF/*.tld文件和/或文件夹来识别，那么/META-INF/resources它绝对属于 WAR 的/WEB-INF/lib。否则，带注释/注册的 Web 片段工件（模块化 servlet、过滤器、侦听器、标签、组件、bean 等）将不会被自动扫描、发现和安装，和/或 Web 片段资源（共享 JSP/Facelets/CSS/JS/图像文件）不能包含在 webapp 中。
或者，如果它代表 Java EE API 的实现，例如 JSF、JSTL、JAX-RS 等，那么它可以（应该）进入服务器的/lib，但是您必须确保替换任何现有/较旧的实现，否则您可能会遇到由运行时类路径中重复的不同版本库引起的类加载问题（可以通过类/方法/字段相关异常识别，例如NoSuchMethodError、LinkageError等）。如果无论如何将其包含在 WAR 中，那么您需要确保指示相关服务器或 API 使用 WAR 捆绑实现而不是服务器捆绑实现。
否则，它很可能是一个基于 Java SE 的“普通”库，例如 Apache Commons 等。这样的库可以安全地进入服务器/lib并在所有网络应用程序之间共享。这至少对于 JDBC 驱动程序和具有服务加载器的类似 JAR 是必需的，该服务加载器在 JVM 启动期间自动将内容加载到内存中，可以通过/META-INF/services基于 Java SE 的 API 的目标文件夹来识别。否则，当这样的库放置在 webapp 中时/WEB-INF/lib，在热部署期间可能会出现内存泄漏风险，因为它无法发出 Java EE 取消部署的信号，并且在 JVM 尚未关闭时再次盲目地自动加载内容。
| 归档时间： |
|
| 查看次数： |
492 次 |
| 最近记录： |