Servlet 3.x API를 사용하면 web.xml을 완전히 제거하고 Java Config로 마이그레이션 할 수 있습니다. 필자는 web.xml을 웹 어플리케이션의 이해를 시작하기위한 디버깅 포인트로 생각합니다. Java 기반 구성으로 마이그레이션하고 web.xml을 완전히 제거하려는 이유를 이해하지 못합니다. 인터넷에서 적절한 답변을 찾으려고했지만 만족스러운 설명을 찾을 수 없습니다. 실무 시나리오에서는 누구나 이해할 수 있습니다.servlet 3.x 용 web.xml 대신 java 기반 구성을 사용할 경우의 이점
자신을 반복하지 않고 실수를하는 것을 피합니다. 서블릿 클래스는 예를 들어 com.foo.bar.SomeServlet입니다.
<servlet-class>com.foo.bar.Someservlet</servlet-class>
을 그러나 잠깐, 당신은 오타를했습니다 당신은 런타임에 그것을 발견 할 것이다 : web.xml 사용하여, 당신은 web.xml에이 클래스를 다시 입력하도록 강요하고 있습니다.
또는 서블릿 클래스의 이름을 바꾸지 만 web.xml에서도 이름을 바꾸는 것을 잊어 버리고 배포시 실수 만 발견하게됩니다.
마지막으로, 그들은 우리의 삶을 편하게 만듭니다. 서블릿을 만들고 있는데, 분명히 URL에 매핑하고 싶습니다. 따라서 주석을 추가하기 만하면됩니다. 매핑을 추가하기 위해 다른 파일로 이동할 필요가 없습니다. 그런 다음 정확한 이름을 잊어 버렸기 때문에 클래스로 돌아간 다음 다시 파일로 돌아갑니다. 서블릿과 관련된 모든 것은 서블릿 클래스에있다. 필터, 수신기 등에서 동일합니다.
주석에는 이러한 모든 문제가 없습니다.
설명자가없는 배포는 구성 파일의 대안이지만 모든 응용 프로그램 및 모든 사용 사례의 web.xml을 항상 바꾸는 것이 아닙니다. 다시 컴파일하지 않고 구성을 변경할 수 있어야한다면 물론 배포 설명자를 사용해야합니다. 때로는 모든 것이 설정된 중앙 집중식 장소를 시작하기가 더 쉽습니다. 그러나 모든 것을 명시 적으로 그리고 수작업으로 설정해야하기 때문에 유연성이 떨어질 수도 있습니다.
자동 검색 가능 주석의 한 가지 장점은 엔드 포인트를 분리하여 독립적으로 만드는 것입니다. 예를 들어 JAX-RS 웹 서비스를 구축하는 경우 웹 애플리케이션은 애플리케이션 경로 만 제공하면됩니다. 실제로 어떤 자원이 사용 가능한지 알 필요가 없습니다. 리소스 클래스 이름이나 패키지 이름은 중요하지 않습니다. 컨테이너가 모든 것을 처리합니다. 모두 서블릿 표준에 따르기 때문에, 서블릿 컨테이너에 주석이 달린 서블릿이나 리소스 엔드 포인트 만있는 war 아카이브를 던져 실행할 수 있습니다. 또는 wab 아카이브로 만들고 osgi 웹 번들과 동일한 것을 배포하십시오. DI를 추가하면 모든 모듈 식 웹 응용 프로그램과 독립적 인 마이크로 서비스를 쉽게 사용할 수 있습니다.
사실 웹 조각 설명자를 사용하여 이러한 이점 대부분을 얻을 수 있습니다. 반면에 수십 개의 web-fragment.xml 개의 파일이 시스템 전체에 흩어져있는 경우 명확한 응용 프로그램 시작 지점의 이점을 잃어 버리게됩니다. 이 시점에서 파일 또는 주석을 사용할지 여부는 환경 설정에 따라 달라질 수 있습니다.