使用 Servlet 3.x API，我们可以完全消除 web.xml 并迁移到 Java Config。我总是发现 web.xml 是开始理解 Web 应用程序的一个很好的调试点。我不明白为什么我们计划迁移到基于 Java 的配置并完全删除 web.xml。我曾尝试在互联网上寻找合适的答案，但找不到令人满意的解释。任何人都可以在实际场景中帮助我理解这一点。
【问题讨论】：
标签： java web.xml servlet-3.0
它避免重复自己，并因此而犯错误。例如，servlet 类是com.foo.bar.SomeServlet。使用web.xml，你不得不在web.xml中重新输入这个类：
<servlet-class>com.foo.bar.Someservlet</servlet-class>
但是等等，你打错了，你只会在运行时发现它。
或者您重命名了一个 servlet 类，但是您忘记在 web.xml 中也重命名它，并且您只在部署时才发现错误。
最后，它们让我们的生活更轻松。您正在创建一个 servlet，并且显然希望将其映射到某个 URL。所以你只需添加一个注释。无需转到另一个文件来添加映射，然后返回该类，因为您忘记了它的确切名称，然后再次返回该文件。有关 servlet 的所有内容都在 servlet 类中。过滤器、侦听器等也是如此。
注解不存在所有这些问题。
【讨论】：
无描述符部署是配置文件的替代方案，但它并不打算总是替换每个应用程序和每个用例中的 web.xml。如果您需要能够在不重新编译的情况下更改配置，那么您当然应该坚持部署描述符。有时，一切都设置好的集中位置可能更容易开始。但它也可能不太灵活，因为您需要手动明确地设置所有内容。
自动可发现注释的一个优点是它们将您的端点解耦并使它们独立。例如，如果您构建 JAX-RS Web 服务，则 Web 应用程序只需要提供应用程序路径。它不需要知道哪些资源实际上是可用的。资源类如何命名或它们在哪个包中并不重要。容器将处理一切。由于这一切都符合 servlet 标准，因此您可以只在 servlet 容器中抛出带有注释的 servlet 或资源端点的战争存档并让它们运行。或者将其设为 wab 存档并部署与 osgi web bundle 相同的东西。添加一些 DI，所有这些都允许高度模块化的 Web 应用程序和轻松使用独立的微服务。
实际上，您也可以通过 Web 片段描述符获得大部分这些好处。另一方面，当您有几十个web-fragment.xml 文件分散在整个系统中时，您也会失去清晰的应用程序入口点的优势。此时，使用文件还是注释可能取决于您的偏好。
【讨论】：