对于 Web 应用程序，为什么更喜欢 /WEB-INF/lib 而不是 /META-INF/MANIFEST.MF？
我想知道为什么 Java webapps 规范为依赖项强加了一个特定的目录：/WEB-INF/lib。
事实上，为什么不使用经典的 /META-INF/MANIFEST.MF 文件呢？
有人会说 Web 应用程序更加安全，因为库在物理上集成在 WAR 文件中。
但是，如果我们这么认为，我们可能会想：
为什么对于一个简单的 Java 应用程序（简单的 JAR），没有专门的依赖目录？它也可能更安全，因为清单文件中没有错误的类路径（例如修改不当）的风险。
其他人会说 webapp 被设计为可移植的，因此 /WEB-INF/lib 的好处是不用担心链接依赖性。
我很想知道你对这个问题的看法。
I wonder why Java webapps specifications imposed a specific directory for dependencies: /WEB-INF/lib.
Indeed, why don't use classic /META-INF/MANIFEST.MF file?
Someone will tell that webapps are so more secure because libs are physically integrated in WAR file.
But, if we think so, we could wonder :
Why for a simple Java application (simple JAR), there's no special directory for dependencies? It could be also more secure because no risk to have a wrong classpath (modified improperly for instance) in manifest file.
Other will tell that webapp is designed to be portable, so benefit of /WEB-INF/lib is to not worry about links dependencies.
I'm curious to know your opinions on the subject.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
jar 是一个标准库。对于普通的实用程序罐子，最好将它们分开。如果一个库依赖于另一个库，并且您需要更多的依赖库，那么您会浪费空间、内存，并且可能会因不同的库版本而出现问题。
然而，Web 应用程序是一个应用程序包。您必须确保一切正常，以便添加所需的库。
A jar is a standard library. For normal utility jars its probably better to keep them separate. If a library has a dependency on a different library and you need that dependent library more then once you would waste space, memory and maybe incorporte problems to due different library versions.
The web application however is an application bundle. You have to make sure that everythings works so you add the required libraries.
因为 WEB-INF/lib 提供了一个非常简单、独立的库包，并简化了最常见用例的整个部署。
这就是一场全面的战争，而对于 Servlet 3.0，web.xml 基本上是空的。布局简单，创建起来很简单，并且最终是一个可以使用的独立工件。
Because the WEB-INF/lib makes for a very easy, self contained package of libraries and simplifies the entire deploy for the most common use cases.
That's a full boat WAR right there, and with Servlet 3.0, the web.xml is basically empty. Simple layout, trivial to create, and a stand alone artifact to work with in the end.