이 기사에서는 Spring MVC가 HTTP 요청에 응답할 수 있는 이유에 대한 내용을 제공합니다. (이유에 대한 자세한 설명) 특정 참고 가치가 있으므로 도움이 필요한 친구가 참고할 수 있기를 바랍니다.
많은 Java 면접관은 다음 질문을 좋아합니다.
Spring MVC 프로젝트 파일에서 개발자는 자신의 서블릿을 개발하지 않았지만 @RequestMapping 주석을 통해 home 메소드만 정의하여 /mvc/로 전송된 요청에 응답했습니다. 테스트1.
URL http://localhost:9098/MavenSandbox/mvc/test1을 사용하여 테스트하면 home 메서드에서 반환된 문자열을 관찰할 수 있습니다. 이것의 작동 원리는 무엇입니까?
자체 조사를 통해 답변해 드립니다. 위 코드의 53번째 줄에 중단점을 설정합니다. http://localhost:9098/MavenSandbox/mvc/test1 URL을 다시 방문하면 중단점이 트리거됩니다. 호출 스택을 관찰하고 스택 프레임 DispatcherServlet.doService(HttpServletRequest, HttpServletResponse)가 있음을 확인합니다. 이 서블릿은 @RequestMapping이라는 주석이 달린 메서드의 반환 문자열을 HttpServletResponse에 추가하는 역할을 합니다. 이것이 우리가 브라우저에서 반환 문자열을 볼 수 있는 이유입니다.
DispatcherServlet.doService의 HttpServletResponse에 우리가 기대하는 출력 문자열이 포함되어 있는지 살펴보겠습니다. 디버거에서 응답 변수를 확장합니다:
response->outputBuffer->bb->buff 이 문자열 배열 버퍼는 buff에서 볼 수 있습니다.
104는 ASCII입니다. code H, 101은 e의 ASCII 코드, 108은 l의 ASCII 코드이므로 응답에는 개발자가 home 메서드에서 반환한 문자열이 포함되어 있음이 증명됩니다. hello 이것은 가장 간단한 예입니다
마지막으로 DispatcherServlet은 Where did it was from?에서 시작됩니다. Eclipse 디버거에서 Spring 프레임워크의 표준 서블릿인 것을 발견했습니다. org.springframework.web.servlet.DispatcherServlet이 서블릿은 정확히 WEB에 있는 web.xml입니다. INF 폴더 파일의 서블릿입니다.
그래서 면접관의 대답은 다음과 같습니다. Spring MVC 프레임워크에는 여전히 Servlet이 필요하지만 이 Servlet은 Spring 프레임워크에서 제공되므로 애플리케이션 개발자가 반복적으로 구현할 필요가 없습니다.위 내용은 Spring MVC가 HTTP 요청에 응답할 수 있는 이유는 무엇입니까? (이유에 대한 자세한 설명)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!