소개
옛날에는 Java가 웹 애플리케이션을 우선적으로 선택했다는 사실로 인해 그 위치가 더욱 강화되었습니다. Java는 초기부터 자신의 길을 찾는 데 어려움을 겪었습니다. 먼저 애플릿을 제안했습니다. 이는 개발자에게 정적 HTML 페이지에 동적 콘텐츠(콘텐츠)를 만들 수 있는 많은 기회를 제공했습니다. 그러나 애플릿은 보안, 오버헤드 등 여러 가지 이유로 기대에 부응하지 못했습니다. 그런 다음 Java 언어 개발자는 대안인
Servlet API를 제안했습니다 . 그리고 그것은 올바른 결정으로 판명되었습니다.
Servlet API는 웹 기반 애플리케이션이든 요청에 따라 정보를 반환하는 웹 서비스이든 모든 Java 웹 애플리케이션이 구축되는 사양입니다. 따라서 Java 웹 애플리케이션의 작동 방식을 이해하는 길은 Servlet API를 이해하는 것부터 시작됩니다.
서블릿 API
따라서
Servlet API는 언어 개발자가 Java 개발자에게 제공한 것입니다. Servlet API는 우리의 주요 질문에 답해야 하는 사양입니다. 여기에서 찾을 수 있습니다: "
JSR-000340 JavaTM Servlet 3.1 평가용 최종 릴리스 ".
" 1.1 서블릿이란? " 장에서는
서블릿이 동적 콘텐츠(즉, 콘텐츠)를 생성하는 Java 기술 기반의 웹 구성 요소라고 말합니다 . "Java 기반"은
서블릿이 바이트코드로 컴파일된 Java 클래스임을 의미합니다 . 서블릿은 서블릿 엔진이라고도 불리는 서블릿 컨테이너에 의해 관리됩니다.
서블릿 컨테이너는 서블릿 기능을 제공하는 웹 서버 확장입니다. 결과적으로 서블릿은 서블릿 컨테이너에 의해 구현되는 요청/응답 패러다임에서 클라이언트와의 상호 작용을 제공합니다.
" 1.2 서블릿 컨테이너란 무엇입니까? " 장에서 서블릿 컨테이너 는 요청과 응답이 전송되고 MIME 기반 요청과 응답이 생성되고 처리되는 네트워크 서비스를 제공하는
웹 서버 또는 응용 프로그램 서버의 일부라고 말합니다. . 또한 서블릿 컨테이너는 서블릿의 수명 주기를 관리합니다(예: 서블릿 생성 시기, 삭제 시기 등 결정). 모든 서블릿 컨테이너는 요청을 수신하고 응답을 보내기 위해 HTTP 프로토콜을 지원해야 합니다. 여기서는 MIME이 인터넷을 통해 전송될 수 있도록 정보를 인코딩하고 메시지 형식을 지정하는 방법을 알려주는 표준인 사양이라는 점을 덧붙이고 싶습니다.
웹 서버
웹 서버는 클라이언트로부터 HTTP 요청을 수락하고 HTTP 응답(일반적으로 HTML 페이지, 이미지, 파일 또는 기타 데이터와 함께)을 제공하는 서버입니다. 요청된 리소스는 URL로 식별됩니다. Servlet API를 지원하는 가장 널리 사용되는 웹 서버 중 하나는
Apache Tomcat 입니다 . 대부분의 웹 서버는 각각 특정 기능을 수행하는 다양한 구성 요소로 구성된 복잡한 시스템입니다. 예를 들어:
커넥터
— 입력에는 클라이언트로부터 들어오는 요청을 수락하는 커넥터(예: 커넥터)가 있습니다. Tomcat의 HTTP 커넥터는 "Coyote" 구성 요소를 사용하여 구현됩니다. 커넥터는 클라이언트로부터 데이터를 수신하여 Tomcat 엔진에 전달합니다.
서블릿 컨테이너 - Tomcat 엔진은 서블릿 컨테이너인 "Catalina" 구성 요소를 사용하여 클라이언트로부터 받은 요청을 처리합니다. 자세한 내용은 Tomcat 문서 "
아키텍처 개요 "를 참조하십시오. Servlet API 사양을 지원하는 다른 웹 서버가 있습니다. 예를 들어 "
Jetty " 또는 "
Undertow "입니다. 그들의 아키텍처는 유사하므로 하나의 서블릿 컨테이너로 작업하는 원리를 이해하면 다른 서블릿 컨테이너로 작업하도록 전환할 수 있습니다.
웹 애플리케이션
따라서 웹 애플리케이션을 실행하려면 Servlet API를 지원하는 웹 서버(즉, 웹 서버에 대한 Servlet API 지원을 구현하는 확장 구성 요소가 있는 서버)가 필요합니다. 괜찮은.
어쨌든 웹 애플리케이션이란 무엇입니까? 서블릿 API 사양의 "
10가지 웹 애플리케이션 " 장 에 따르면
웹 애플리케이션은 웹 서버에서 최종 애플리케이션을 구성하는 서블릿, HTML 페이지, 클래스 및 기타 리소스의 모음입니다.
" 10.6 웹 애플리케이션 아카이브 파일 " 장에 따르면 , 웹 애플리케이션은 Web ARchive(WAR 확장자를 가진 아카이브)로 패키징될 수 있습니다. "
용어집-219 " 페이지에 명시된 바와 같이:
즉, JAR 대신 WAR을 만들어 웹 애플리케이션임을 보여줍니다. 다음으로 중요한 사실은 WAR 아카이브에 특정 디렉토리 구조가 있어야 한다는 것입니다.
" 10.5 디렉토리 구조 " 장의 Servlet API 사양에 있습니다 . 이 장에서는 "WEB-INF"라는 특별한 디렉터리가 있다고 설명합니다. 이 디렉토리는 클라이언트에 표시되지 않고 직접 표시되지 않는다는 점에서 특별하지만 서블릿 코드에 액세스할 수 있습니다. 또한 WEB-INF 디렉토리에 포함될 수 있는 내용도 나와 있습니다.
이 전체 목록에서 우리는 이제 배포 설명 자라는 일부
web.xml 파일 에 대한 항목을 모르고 이해하지 못합니다 . 그것은 무엇입니까?
" 14. 배포 설명자 " 장은 배포 설명자에 대해 다룹니다. 간단히 말해서
배포 설명자는 웹 서버에 웹 애플리케이션을 배포(즉, 실행)하는 방법을 설명하는 xml 파일입니다. 예를 들어 배포 설명자는 애플리케이션에 액세스하는 데 사용해야 하는 URL, 애플리케이션과 관련된 보안 설정 등을 나타냅니다.
" 14.2 배포 처리 규칙 " 장에서는 응용 프로그램을 구성하고 시작하기 전에 web.xml의 스키마가 검증될 것이라고 말합니다(즉, web.xml의 내용이 스키마에 따라 올바르게 작성되었는지 확인합니다). .
그리고 " 14.3 배포 설명자 " 장에는 다이어그램이 여기에 있음이 표시되어 있습니다. 파일 내용을 보면 다음을 볼 수 있습니다.
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd
XML 파일에 사용되는 스키마는 무엇입니까? 스키마는 사용할 수 있는 요소, 요소에 지정할 수 있는 데이터 유형, 요소의 순서, 필요한 요소 등 XML 문서를 올바르게 작성하는 방법을 나타냅니다. XML 문서의 스키마를 Java의 인터페이스와 비교할 수 있습니다. 왜냐하면 Java의 스키마는 주어진 인터페이스를 만족하는(즉, 주어진 인터페이스를 구현하는) 클래스가 작성되어야 하는 방법도 지정하기 때문입니다. 이제 우리는 비밀 지식을 갖추고 첫 번째 웹 애플리케이션을 만들 준비가 되었습니다!
웹 애플리케이션 생성
자동 프로젝트 빌드 시스템을 사용하지 않고 최신 Java 애플리케이션으로 작업하는 것은 상상하기 어렵습니다. 가장 널리 사용되는 시스템 중 일부는
Maven과 Gradle 입니다 . 이 검토에는 Gradle을 사용하겠습니다. Gradle 설치는
공식 웹사이트 에 설명되어 있습니다 .
새 애플리케이션을 생성하려면 Gradle에 내장된 플러그인인 " Build Init Plugin " 이 필요합니다 . Java 애플리케이션을 생성하려면 다음 명령을 실행해야 합니다.
gradle init --type java-application
프로젝트를 생성한 후에는 build.gradle 파일을 편집해야 합니다 . 이것은 소위 빌드 스크립트입니다(자세한 내용은 Gradle 문서: "
빌드 스크립트 작성 " 참조). 이 파일은 프로젝트를 어셈블하는 방법과 Java 프로젝트 작업의 다른 측면을 설명합니다. 플러그인 블록은 현재 Gradle 프로젝트에 사용해야 하는 "
Gradle 플러그인 "을 설명합니다. 플러그인은 프로젝트의 기능을 확장합니다. 예를 들어 기본 플러그인은 "
java "입니다. 이 플러그인은 Java 지원이 필요할 때 항상 사용됩니다. 하지만 "
application " 플러그인은 필요하지 않습니다 . 왜냐하면... 설명에 따르면 "실행 가능한 JVM 애플리케이션"을 생성하는 데 사용됩니다. JVM 애플리케이션을 실행 중입니다. WAR 아카이브 형태로 웹 애플리케이션을 생성해야 합니다. 그리고 Gradle 문서에서 WAR이라는 단어를 찾으면 "
War Plugin "을 찾을 수 있습니다. 따라서 다음 플러그인을 지정합니다.
plugins {
id 'java'
id 'war'
}
또한 "
War Plugin 기본 설정 "에는 웹 애플리케이션의 모든 콘텐츠가 포함된 디렉터리가 "src/main/webapp"이어야 하고 web.xml이 있어야 하는 동일한 WEB-INF 디렉터리가 있어야 한다고 나와 있습니다. 위치하고 있습니다. 그런 파일을 만들어 보겠습니다. 잠시 후에 작성하겠습니다. 왜냐면... 아직 이에 대한 정보가 충분하지 않습니다. "의존성" 블록에서는 프로젝트의 종속성, 즉 애플리케이션이 없으면 작동할 수 없는 라이브러리/프레임워크를 나타냅니다. 이 경우 웹 애플리케이션을 작성하고 있는데 이는 Servlet API 없이는 작업할 수 없음을 의미합니다.
dependencies {
providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
testCompile 'junit:junit:4.12'
}
제공된컴파일은 웹 애플리케이션의 WAR 아카이브에 종속성을 포함할 필요가 없으며 컴파일에만 필요함을 의미합니다. 그리고 실행되면 이 종속성은 다른 사람(즉, 웹 서버)에 의해 제공됩니다. 글쎄, 우리가 사용하려는 종속성 저장소에 대한 정보를 빌드 스크립트에 남겨 둡니다. 지정된 모든 종속성은 여기에서 다운로드됩니다.
repositories {
jcenter()
}
빌드 스크립트 파일에서 다른 모든 것을 제거합니다. 이제 src\main\java\App.java 클래스를 편집해 보겠습니다. 그것으로 서블릿을 만들어보자.
" 2장. 서블릿 인터페이스 " 장의 서블릿 API 사양에서는 서블릿 인터페이스에
HttpServlet의 기본 구현이 있다고 나와 있는데 , 이는 대부분의 경우 충분하며 개발자는 이를 상속하기만 하면 됩니다.
그리고 " 2.1.1 HTTP 특정 요청 처리 방법 " 장에서는 들어오는 요청을 처리하는 주요 방법을 표시합니다. 따라서 App.java 클래스를 다시 작성해 보겠습니다.
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.PrintWriter;
import java.io.IOException;
public class App extends HttpServlet {
public String getGreeting() {
return "Hello world.";
}
public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
PrintWriter out = resp.getWriter();
out.println(this.getGreeting());
out.close();
}
}
그래서 우리는 모든 준비가 완료된 것 같습니다. 남은 것은 배포 설명자를 올바르게 작성하는 것뿐입니다. 다이어그램에서 다음 텍스트를 web.xml에 복사합니다.
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="..."
version="3.1">
...
</web-app>
그리고 여기에 표시된 스키마에 대한 경로도 표시됩니다.
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd 이제 Servlet API 사양에서 web.xml이 어떤 모습이어야 하는지에 대한 예를 살펴보겠습니다.
이 예는 " 14.5.1 기본 예 " 장에 나와 있습니다 . 다이어그램에 표시된 내용과 사양에 표시된 예를 결합해 보겠습니다. 우리는 다음을 얻습니다:
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<display-name>A Simple Web Application</display-name>
<servlet>
<servlet-name>app</servlet-name>
<servlet-class>App</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/app</url-pattern>
</servlet-mapping>
</web-app>
보시다시피 앞서 지정한 스키마와 스키마 위치를 사용했습니다. 그리고 요소 자체에 대한 설명은 14.5.1장의 예에서 따왔습니다. 모든 작업을 올바르게 수행했다면 오류 없이 Gradle War 작업을 실행할 것입니다.
웹 애플리케이션 실행
웹 애플리케이션은 어떻게 시작되나요? 먼저 더 복잡한 옵션을 다루겠습니다. 우리는 이전에 Servlet API를 지원하는 Apache Tomcat 웹 서버가 있다고 말했습니다. 이는 수집된 전쟁 아카이브(“배포”라고도 함)를 이 서버에 배포할 수 있음을 의미합니다. "
Tomcat 다운로드 " 페이지의 "Binary Distributions" 섹션에서 전달 유형 "Core"를 zip 형식으로 다운로드합니다. 그리고 다운로드한 아카이브를 C:\apache-tomcat-9.0.14와 같은 일부 디렉터리에 압축을 풉니다. 서버를 시작하기 전에 편집할 파일을 열고
conf\tomcat-users.xml다음 줄을 추가해 보겠습니다.
<user username="tomcat" password="tomcat" roles="tomcat,manager-gui,admin-gui"/> 이제 명령줄에서 bin 디렉터리로 이동하여
catalina.bat start. 기본적으로 서버 콘솔은 에서 사용할 수 있습니다
http://localhost:8080/manager. 로그인 및 비밀번호는 tomcat-users.xml에 지정한 것과 동일합니다. Tomcat에는 웹 애플리케이션이 포함된 "webapps" 디렉터리가 있습니다. 우리 자신의 것을 배포하려면 전쟁 기록을 거기에 복사해야 합니다. 이전에 gradle war 명령을 실행했을 때
\build\libs\디렉터리에 war 아카이브가 생성되었습니다. 이것이 우리가 복사해야 할 것입니다. 복사한 후 페이지를 새로 고치고
http://localhost:8080/manager다음을 확인하세요.
완료한 후에
http://localhost:8080/javaweb/app우리는 서블릿으로 전환할 것입니다. 이전에는 /app 요청을 앱 서블릿에 "매핑"(즉, 매핑)했습니다. 애플리케이션이 어떻게 작동하는지 확인하는 더 빠른 방법이 있습니다. 그리고 조립 시스템이 이를 다시 도와줍니다. Gradle 프로젝트의 빌드 스크립트에서 새로운 플러그인 "
Gretty "를 플러그인 섹션에 추가할 수 있습니다.
id "org.gretty" version "2.3.1" 이제 Gradle 작업을 수행하여 애플리케이션을 실행할 수 있습니다.
gradle appRun
자세한 내용은 "
gretty 플러그인 추가 및 앱 실행 "을 참조하세요.
스프링과 서블릿 API
서블릿은 모든 것의 기초입니다. 그리고 현재 인기 있는 Spring Framework조차도 Servlet API의 추가 기능에 지나지 않습니다. 우선
Spring Framework는 우리 프로젝트의 새로운 종속성입니다. 따라서 종속성 블록의 빌드 스크립트에 이를 추가해 보겠습니다. Spring Framework 문서에는 "
1.1. DispatcherServletcompile 'org.springframework:spring-webmvc:5.1.3.RELEASE' " 장이 있습니다 . Spring Framework는 "전면 컨트롤러" 패턴을 기반으로 구축되었다고 합니다. 이는 "
DispatcherServlet "이라는 중앙 서블릿이 있는 경우입니다. 모든 요청은 이 서블릿으로 들어오며 필요한 구성 요소에 대한 호출을 위임합니다. 보시다시피 여기에도 서블릿이 있습니다. 배포 설명자에 리스너를 추가해야 합니다.
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
이것은 서블릿 컨텍스트 이벤트 리스너입니다. 즉, Servlet Context가 시작되면 Spring 컨텍스트(WebApplicationContext)도 시작된다.
서블릿 컨텍스트란 무엇입니까? 이는 " CHAPTER 4. 서블릿 컨텍스트 " 장의 Servle API 사양에 설명되어 있습니다 . 서블릿 컨텍스트는 서블릿이 실행되는 웹 애플리케이션에 대한 서블릿의 "보기"입니다. 각 웹 애플리케이션에는 자체 서블릿 컨텍스트가 있습니다. 다음으로 Spring Framework를 활성화하려면 서블릿 컨텍스트의 초기화 매개변수인 context-param을 지정해야 합니다.
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/app-context.xml</param-value>
</context-param>
그리고
DispatcherServlet 정의가 구성을 완료합니다 .
<servlet>
<servlet-name>app</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value></param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
이제 contextConfigLocation에 지정된 파일을 작성하면 됩니다. 이를 수행하는 방법은 Spring Framework 문서의 "1.3.1. 선언" 장에 설명되어 있습니다.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc.xsd">
<context:component-scan base-package="ru.javarush.javaweb"/>
<mvc:annotation-driven/>
</beans>
여기에서는 스캔할 패키지를 나타내는 것뿐만 아니라 주석 기반, 즉 Spring 작동 방식에 대한 주석을 제어하기를 원한다는 것도 중요합니다. 남은 것은 ru.javarush.javaweb 패키지를 생성하고 여기에 Spring 컨트롤러 클래스를 배치하는 것입니다.
package ru.javarush.javaweb;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.ResponseBody;
@Controller
public class SpringController {
@GetMapping("/app")
@ResponseBody
public String getGreeting() {
return "Hello world.";
}
}
이제 gradle appRun을 실행하고 해당 주소로 이동하면
http://127.0.0.1:8080/javaweb/app동일한 Hello World가 표시됩니다. 보시다시피 Spring Framework는 Servlet API와 밀접하게 얽혀 있으며 이를 사용하여 그 위에서 작업합니다.
주석
지금까지 살펴본 것처럼 주석은 편리합니다. 그렇게 생각한 사람은 우리뿐만이 아니었습니다. 따라서 Servlet API 사양에는 버전 3.0부터 "
CHAPTER 8 Annotations and Pluggability " 장이 등장했는데, 이는 서블릿 컨테이너가 이전에 배치 설명자에 지정된 내용을 주석을 통해 지정하는 기능을 지원해야 한다고 명시하고 있습니다. 따라서 web.xml은 프로젝트에서 완전히 제거될 수 있으며 서블릿 클래스 위에서
@WebServlet 주석을 지정 하고 서블릿을 매핑할 경로를 나타낼 수 있습니다. 여기서는 모든 것이 명확해 보입니다. 하지만 더 복잡한 설정이 필요한 프로젝트에 Spring을 연결하면 어떻게 될까요? 여기서는 모든 것이 조금 더 복잡합니다. 첫째, Spring 문서에서는 web.xml 없이 Spring을 구성하려면 WebApplicationInitializer를 구현할 자체 클래스를 사용해야 한다고 나와 있습니다.
자세한 내용은 " 1.1. DispatcherServlet " 장을 참조하세요 . 이것은 Spring 클래스인 것으로 밝혀졌습니다. 그러면 여기서 Servlet API는 어떻게 사용됩니까? 실제로
ServletContainerInitializer는 Servlet API 3.0에 추가되었습니다 . Java의 특수 메커니즘(
SPI 라고 함 )을 사용하여 Spring은 이라는 서블릿 컨테이너 초기화 프로그램을 지정합니다
SpringServletContainerInitializer. 그러면 이미 WebApplicationInitializer 구현을 찾고 필요한 메서드를 호출하고 필요한 설정을 수행합니다. 자세한 내용은 "
서블릿 컨테이너가 WebApplicationInitializer 구현을 찾는 방법 "을 참조하세요. 위 설정은 다음과 같이 할 수 있습니다.
package ru.javarush.javaweb.config;
import org.springframework.web.WebApplicationInitializer;
import org.springframework.web.context.ContextLoaderListener;
import org.springframework.web.context.support.AnnotationConfigWebApplicationContext;
import org.springframework.web.servlet.DispatcherServlet;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRegistration;
public class AppInitializer implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext servletContext) throws ServletException {
AnnotationConfigWebApplicationContext ctx = new AnnotationConfigWebApplicationContext();
ctx.register(AppConfig.class);
servletContext.addListener(new ContextLoaderListener(ctx));
ctx.setServletContext(servletContext);
ServletRegistration.Dynamic servlet =
servletContext.addServlet("dispatcher", new DispatcherServlet(ctx));
servlet.addMapping("/");
servlet.setLoadOnStartup(1);
}
}
이제 "
Java 기반 구성 "을 사용하여 스캔할 패키지를 표시하고 주석을 활성화합니다.
package ru.javarush.javaweb.config;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;
@Configuration
@EnableWebMvc
@ComponentScan(basePackages = "ru.javarush.javaweb.controllers")
public class AppConfig {
}
그리고 SpringController 자체가 로 이동되었으므로
ru.javarush.javaweb.controllers스캔할 때 구성은 자체를 찾지 않고 컨트롤러만 찾습니다.
요약
이 개요를 통해 웹 애플리케이션이 Java에서 작동하는 방식에 대해 어느 정도 밝혀졌기를 바랍니다. 이는 빙산의 일각에 불과하지만, 기본을 이해하지 못하면 이러한 기반을 바탕으로 한 기술이 어떻게 작동하는지 이해하기 어렵습니다. Servlet API는 모든 Java 웹 애플리케이션의 핵심 부분이며 다른 프레임워크가 이에 어떻게 적용되는지 살펴보았습니다. 계속하려면 다음 자료를 볼 수 있습니다.
#비아체슬라프
GO TO FULL VERSION