본문 바로가기
CS Study

8월 4주차 jar, war

devWonny 2024. 8. 19. 17:20

 

 

공통 질문

1. JAR, WAR

  • 언제 jar, war를 써야하는가
  • Web Server & Web Application Server
  • Spring & Spring Boot
  • EC2 & ECS
  • JVM에서 해석 과정

2. JDK > JRE > JVM

3. GC

jar, war는 Java App을 패키징하는 방식으로 나뉜다

  • JAR: Java 라이브러리나 독립 실행형 App 배포할 때 사용.
  • WAR: Java Web App 배포할 때 사용. Web Server/App Server에서 실행될 수 있는 형식.

 

JAR (Java ARchive)

  1. 용도:
    • 독립 실행형 Java App 배포하는 데 사용
    • 라이브러리나 유틸리티 클래스들도 JAR 파일로 배포
  2. 구조:
    • 기본적으로 Java 클래스 파일(.class), 메타데이터(META-INF 디렉토리 안의 MANIFEST.MF 파일), 리소스 파일 등을 포함합니다.
    • MANIFEST.MF 파일에는 메타데이터가 포함되어 있으며, 주 실행 클래스를 지정할 수 있는 Main-Class 속성이 포함될 수 있습니다.
  3. 실행 방법:
    • java -jar your-application.jar
  4. 사용 예:
    • 예: 라이브러리, 콘솔 애플리케이션, 간단한 데스크톱 애플리케이션.
  5. 실행
    • JAR 파일 실행 (독립 실행형 애플리케이션인 경우):
      • 독립 실행형 애플리케이션의 경우, JAR 파일은 직접 실행할 수 있습니다.
      • 이 명령은 MANIFEST.MF 파일에 정의된 메인 클래스를 실행합니다.
java -jar your-application.jar

 

 

  • JAR 파일 내부 내용 보기:
    • JAR 파일은 ZIP 형식으로 압축되어 있으므로, 압축 해제 도구를 사용하거나 jar 명령을 사용하여 내부 파일을 확인할 수 있습니다
    • 이 명령은 JAR 파일 내의 파일 목록을 출력합니다.
jar tf your-application.jar

 

  • JAR 파일의 클래스 사용 (라이브러리로 사용되는 경우):
    • JAR 파일을 다른 Java 프로젝트의 라이브러리로 사용하려면, 해당 JAR 파일을 클래스패스에 추가하여 클래스와 메서드를 사용할 수 있습니다:
javac -cp your-library.jar YourClass.java java -cp your-library.jar:. YourClass
 

 

 

 

WAR (Web Application ARchive)

  1. 용도:
    • Java Web App을 배포하는데 사용
    • 웹 서버나 애플리케이션 서버(예: Tomcat, Jetty, JBoss)에 배포되는 Web App을 위한 포맷
  2. 구조:
    • 웹 애플리케이션 관련 파일들이 포함
      • WEB-INF/ 디렉토리: 서블릿과 관련된 설정(web.xml), 클래스 파일(classes/), 라이브러리(JAR 파일, lib/) 등
      • JSP 파일, HTML 파일, CSS, JavaScript, 이미지 등 웹 애플리케이션의 정적 자원.
    • WEB-INF 디렉토리 하위의 내용은 웹 클라이언트가 직접 접근할 수 없습니다.
  3. 배포 방법:
    • 웹 서버, 애플리케이션 서버의 webapps 디렉토리에 복사하여 배포
    • 서버가 자동으로 WAR 파일을 해제하고 App 배포
  4. 사용 예:
    • JSP/Servlet 웹 애플리케이션
    • Spring MVC 애플리케이션

 

언제, jar war를 써야 할까?

  • EC2:
    • 전통적인 Java 웹 애플리케이션은 WAR 파일을 배포할 수 있음
    • Spring Boot와 같은 독립 실행형 애플리케이션은 JAR 파일 사용 일반적
  • ECS:
    • 대부분의 경우 Docker 이미지를 사용하기 때문에, JAR 파일을 기반으로 컨테이너를 빌드하는 것이 일반적
    • 전통적인 웹 애플리케이션의 경우 WAR 파일을 Docker 이미지에 포함시켜 배포할 수도 있음

 

AWS EC2 사용 시

  • 전통적인 웹 애플리케이션 (WAR 파일 사용):
    • 만약 애플리케이션이 Java 웹 애플리케이션이고, Apache Tomcat, JBoss, Jetty 같은 서블릿 컨테이너 또는 애플리케이션 서버를 사용한다면, WAR 파일을 배포하는 것이 일반적입니다.
    • WAR 파일은 EC2 인스턴스에 설정된 웹 서버의 webapps 디렉토리 등에 배포됩니다.
  • 독립 실행형 애플리케이션 (JAR 파일 사용):
    • 만약 애플리케이션이 Spring Boot와 같은 프레임워크로 작성된 독립 실행형 애플리케이션이라면, JAR 파일로 패키징되어 EC2 인스턴스에서 직접 실행됩니다.
    • Spring Boot는 내장된 Tomcat 또는 Jetty 서버를 포함할 수 있기 때문에, WAR 파일 대신 JAR 파일로 배포해도 웹 애플리케이션을 실행할 수 있습니다.

AWS ECS 사용 시

  • 컨테이너화된 애플리케이션 (보통 JAR 파일 사용):
    • ECS에서 애플리케이션을 컨테이너로 배포할 때는 보통 Docker 이미지를 사용합니다. Spring Boot와 같은 독립 실행형 애플리케이션은 JAR 파일을 기반으로 Docker 이미지가 빌드됩니다.
    • Dockerfile에서 JAR 파일을 COPY하고, 그 JAR 파일을 실행하는 방식으로 컨테이너를 구성합니다.
    • 전통적인 웹 애플리케이션도 Docker 컨테이너로 패키징할 수 있지만, 이 경우에도 JAR 파일을 사용하는 것이 더 일반적입니다.
Dockerfile

FROM openjdk:17-jdk-alpine
COPY target/your-application.jar app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

 

 

  • 컨테이너화된 웹 애플리케이션 (WAR 파일 사용):
    • 만약 전통적인 웹 애플리케이션을 Docker 컨테이너로 배포하고, 서블릿 컨테이너가 필요한 경우 WAR 파일을 사용하여 Docker 이미지를 빌드할 수 있습니다.
    • 이 경우, Tomcat이나 JBoss 같은 애플리케이션 서버 이미지를 기반으로 WAR 파일을 배포하게 됩니다.
     
Dockerfile

FROM tomcat:9.0
COPY target/your-application.war /usr/local/tomcat/webapps/

 

 

 

 

JSP를 쓰면 war?

그림 출처:

https://youtu.be/Il5d4YXtlYI?si=JQfdtFQ4Dolp1fsH

 

 

jsp 사용하면 war 써야함
외장 was(톰캣)를 쓰면 war 써야함

 

이라고 말했다가 스터디원에게 쾅 맞았다.

jsp 사용하면 war 써야하는건 아니다 위에 그림봐라 예외가 있지 않냐

 

  • WAR 파일은 Java EE 웹 애플리케이션의 표준 배포 형식으로, 모든 웹 애플리케이션의 구성 요소를 패키징하여 배포합니다.
  • JSP 사용: JSP 파일을 사용할 때, WAR 파일을 만드는 것이 일반적이지만, 반드시 필요한 것은 아닙니다. 특정 상황에서는 임베디드 서버나 서블릿 컨테이너를 사용하여 JSP 파일을 직접 실행할 수 있습니다.
  • 임베디드 서버: Spring Boot와 같은 프레임워크에서는 내장 서버를 통해 WAR 파일 없이 웹 애플리케이션을 실행할 수 있습니다.

결론적으로, WAR 파일은 Java EE 웹 애플리케이션의 표준 배포 형식이지만, JSP를 사용하는 것과 직접적으로 연관된 것은 아닙니다. 다른 배포 방식이나 실행 환경에서는 WAR 파일 없이도 JSP를 사용할 수 있습니다.

 

JSP와 WAR 파일

JSP와 WAR 파일

  • JSP 파일:
    • JavaServer Pages는 동적인 웹 페이지를 생성하기 위한 기술입니다.
    • JSP 파일은 HTML과 Java 코드를 혼합하여 작성되며,
    • 웹 애플리케이션 서버가 JSP 파일을 서블릿으로 변환하여 실행합니다.
  • WAR 파일:
    • WAR 파일은 Java EE 웹 애플리케이션의 배포 형식으로,
    • 모든 웹 애플리케이션의 구성 요소(서블릿, JSP, HTML, 자바 클래스 파일 등)를 패키징한 압축 파일입니다.
    • WAR 파일을 웹 애플리케이션 서버에 배포하면, 서버가 이 파일을 해제하고 애플리케이션을 실행합니다.

 

WAR 파일 없이 JSP 사용하기

다음과 같은 예외적인 상황에서는 WAR 파일 없이도 JSP를 사용할 수 있습니다:

 

임베디드 서버:

  • Spring Boot:
    • Spring Boot는 내장 서버(Tomcat, Jetty 등)를 제공하여 웹 애플리케이션을 직접 실행할 수 있습니다.
    • Spring Boot에서는 WAR 파일을 생성할 필요 없이, 직접 JAR 파일로 패키징하여 실행할 수 있습니다.
  • 예시:
    • Spring Boot에서 JSP를 사용하려면,
    • src/main/resources/templates 디렉토리에 JSP 파일을 배치하고,
    • application.properties 또는 application.yml에서 설정을 조정합니다.
@SpringBootApplication
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

 

# application.yml
spring:
  jsp:
    prefix: /WEB-INF/jsp/
    suffix: .jsp

 

 

Java SE 환경:

  • Standalone Servlet Containers:
    • Jetty, Tomcat 등과 같은 임베디드 서블릿 컨테이너를 사용하면,
    • WAR 파일 없이도 JSP 파일을 직접 로드하고 실행할 수 있습니다.
    • 이러한 컨테이너는 Java SE 환경에서도 사용할 수 있으며,
    • JSP 파일을 포함하여 웹 애플리케이션을 직접 실행할 수 있습니다.
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.servlet.ServletContextHandler;
import org.eclipse.jetty.servlet.ServletHolder;

public class Main {
    public static void main(String[] args) throws Exception {
        Server server = new Server(8080);
        ServletContextHandler handler = new ServletContextHandler(ServletContextHandler.SESSIONS);
        handler.setResourceBase("src/main/webapp");
        handler.addServlet(new ServletHolder(new HelloServlet()), "/hello");
        server.setHandler(handler);
        server.start();
        server.join();
    }
}

 

 

 

Servlet Container 의 유무에 따라?

스터디원이 jar와 war 선택의 설명을 요청할때 서블릿컨테이너 유무를 언급했었다.
잘 몰라서 적어 본다

 

서블릿 컨테이너의 유무에 따라 JAR 파일과 WAR 파일 사용이 결정되지는 않지만,

서블릿 컨테이너가 있는 전통적인 Java EE 웹 애플리케이션에서는 WAR 파일을 사용하여 배포하는 것이 일반적입니다.

그러나 현대적인 개발 환경에서는 서블릿 컨테이너를 내장한 JAR 파일(예: Spring Boot JAR) 사용이 증가하고 있으며,

이는 개발과 배포의 편리성을 제공합니다.

  • WAR 파일: 서블릿 컨테이너에 배포하는 표준 방법.
  • JAR 파일: 임베디드 서블릿 컨테이너를 포함하여 독립적으로 실행 가능한 애플리케이션 패키징 방식

 

서블릿 컨테이너와 WAR 파일

  • WAR 파일:
    • WAR (Web Application Archive) 파일은 Java EE(또는 Jakarta EE) 웹 애플리케이션의 표준 배포 형식입니다.
    • 웹 애플리케이션을 패키징할 때 서블릿, JSP, HTML, 자바 클래스 파일, 설정 파일 등을 포함하여 단일 압축 파일로 만듭니다.
  • 서블릿 컨테이너:
    • 서블릿 컨테이너(예: Apache Tomcat, Jetty, JBoss 등)는 WAR 파일을 해제하고,
    • 그 안의 서블릿과 JSP를 실행할 수 있습니다.
    • WAR 파일은 컨테이너에 배포되어 실행됩니다.

서블릿 컨테이너가 있을 때 WAR 파일을 사용하는 것이 일반적이며, WAR 파일은 다음과 같은 이유로 선택됩니다:

  • 표준화:
    • Java EE 표준에 따라 웹 애플리케이션을 패키징하고 배포하는 표준 방법입니다.
  • 구성 요소 포함:
    • 서블릿, JSP, HTML 파일, 자바 클래스 파일, 설정 파일 등을 한 파일로 패키징하여 배포합니다.

서블릿 컨테이너와 JAR 파일

  • JAR 파일:
    • JAR (Java ARchive) 파일은 일반적으로 Java 애플리케이션과 라이브러리의 배포 형식입니다.
    • JAR 파일은 Java 클래스 파일, 메타데이터, 리소스 파일을 포함합니다.
  • 임베디드 서블릿 컨테이너:
    • JAR 파일을 사용할 때도 서블릿 컨테이너를 포함할 수 있습니다.
    • 예를 들어, Spring Boot와 같은 프레임워크는 내장 서블릿 컨테이너(Tomcat, Jetty 등)를 JAR 파일에 포함하여
    • 애플리케이션을 단일 JAR 파일로 패키징합니다.

임베디드 서블릿 컨테이너를 사용하는 JAR 파일은 다음과 같은 이유로 선택됩니다:

  • 편리한 배포:
    • 모든 애플리케이션 구성 요소와 서블릿 컨테이너를 단일 JAR 파일로 패키징하여 배포할 수 있습니다.
  • Spring Boot:
    • Spring Boot와 같은 프레임워크는 JAR 파일을 사용하여
    • 애플리케이션과 내장 서블릿 컨테이너를 함께 패키징하고 실행할 수 있게 합니다.
    • 이는 WAR 파일을 생성할 필요 없이 독립적인 실행 가능한 JAR 파일을 제공합니다.

 

 

그림 출처: https://www.youtube.com/watch?v=calGCwG_B4Y

 

Web Server, Web Application Server(WAS)

 

  • 웹 서버 (Web Server):
    • HTTP 요청을 처리하고 정적 콘텐츠를 제공하는 서버입니다.
    • Nginx, Apache HTTP Server 등이 대표적입니다.
  • 웹 애플리케이션 서버 (WAS):
    • 동적 웹 애플리케이션의 로직을 실행하고, 데이터베이스와 상호작용하며, HTTP 요청을 처리하는 서버입니다.
    • Tomcat, JBoss, WebSphere 등이 WAS의 대표적 예입니다.

 

Web Server

  • 기본 개념:
    • HTTP/HTTPS 프로토콜을 사용하여 클라이언트(주로 웹 브라우저)로부터 들어오는 요청을 처리, 응답을 반환하는 서버
    • Apache HTTP Server, Nginx, Microsoft IIS
  • 기능:
    1. HTTP 요청 처리:
      • 클라이언트로부터 들어오는 HTTP 요청(GET, POST 등)을 수신하고, 요청된 리소스(HTML 파일, 이미지, CSS 파일 등)를 반환합니다.
    2. 정적 콘텐츠 제공:
      • 정적 파일(HTML, 이미지, CSS, JavaScript 등)을 클라이언트에게 전달합니다.
    3. 동적 콘텐츠 처리:
      • PHP, Python, Node.js 등의 스크립트를 처리
      • WAS(웹 애플리케이션 서버)와의 연계를 통해 동적 콘텐츠를 생성
    4. 부하 분산:
      • 여러 서버로 들어오는 트래픽을 분산시키기 위한 로드 밸런싱 기능을 제공하기도 합니다.
    5. SSL/TLS 암호화:
      • HTTPS를 통해 보안된 통신을 제공하기 위해 SSL/TLS 암호화를 처리합니다.
    6. 접속 관리 및 로그 기록:
      • 접속 제어(예: IP 차단) 및 접속 로그를 기록하여 관리할 수 있습니다.

 

Web Application Server(WAS)

  • 기능:
    • 동적 콘텐츠 처리
      • Java, Python, PHP, Ruby 등으로 작성된 동적 웹 애플리케이션의 비즈니스 로직을 실행하고, 데이터를 처리하여 결과를 생성합니다.
    • 서블릿 컨테이너
      • 서블릿(Java 기반 웹 애플리케이션 컴포넌트)을 실행하고 관리
      • JSP, JSF와 같은 Java 기반 웹 기술도 WAS에서 처리
    • 트랜잭션 관리
      • 데이터베이스와의 연동 및 트랜잭션 관리를 지원
    • 세션 관리
      • 클라이언트와의 세션을 유지하고 관리
    • 엔터프라이즈 기능 제공
      • 메시징 서비스, 커넥션 풀링, 보안, 데이터 접근 관리 등 엔터프라이즈 애플리케이션에 필요한 기능을 제공
  • 대표적인 웹 애플리케이션 서버 소프트웨어
    • Apache Tomcat, JBoss, WebLogic, IBM WebSphere.
  • 용도:
    • 동적 웹 애플리케이션 호스팅, 엔터프라이즈 애플리케이션 서비스 제공
    • 클라이언트의 요청을 처리하기 위해 비즈니스 로직을 실행하고, 데이터베이스와 상호작용하며, 동적으로 콘텐츠를 생성

 

Web Server, Web Application Server 차이점

 

  • 역할:
    • 웹 서버: 정적 콘텐츠 제공 및 기본적인 HTTP 요청 처리를 담당.
    • 웹 애플리케이션 서버: 동적 콘텐츠 처리 및 애플리케이션 로직 실행을 담당.
  • 기능 범위:
    • 웹 서버는 정적 파일의 제공에 주력하며, 클라이언트의 요청에 대해 리소스를 반환하는 역할을 합니다.
    • 웹 애플리케이션 서버는 동적 요청을 처리하기 위해 애플리케이션 로직을 실행하고, 데이터베이스 연동, 트랜잭션 관리, 세션 관리 등 더 복잡한 처리를 수행합니다.
  • 통합 사용:
    • 많은 경우, 웹 서버와 웹 애플리케이션 서버는 함께 사용됩니다. 예를 들어, Nginx(웹 서버)가 들어오는 요청을 받아 정적 파일을 제공하고, 동적 요청은 Tomcat(웹 애플리케이션 서버)으로 전달하여 처리하는 방식입니다.
    • Spring Boot 애플리케이션처럼 내장 웹 서버를 사용하는 경우, 애플리케이션이 웹 서버와 웹 애플리케이션 서버 역할을 동시에 수행할 수도 있습니다.

 

 

 

Spring과 Spring Boot

 

  • Spring Framework에서는 주로 외부의 WAS가 사용되며, Spring Boot에서는 내장 WAS가 사용됩니다.
  • Spring Boot에서 말하는 서버는 내장된 웹 애플리케이션 서버(WAS)로서, 웹 서버의 기능도 함께 수행합니다.
  • Spring Boot의 내장 WAS 덕분에 개발자는 외부 WAS 설정 없이 애플리케이션을 손쉽게 실행하고 배포할 수 있습니다.

 

Spring Framework

  • 기본 개념:
    • Spring Framework는 Java 애플리케이션 개발을 위한 종합적인 프레임워크로, 웹 애플리케이션뿐만 아니라 다양한 종류의 애플리케이션 개발에 사용됩니다.
    • Spring Framework는 자체적으로 서버를 제공하지 않습니다. 대신, 웹 애플리케이션을 배포하려면 외부의 WAS (예: Apache Tomcat, JBoss)에서 실행해야 합니다.
  • 작동 방식:
    • 개발자는 Spring을 이용해 웹 애플리케이션을 개발하고, 이를 WAR 파일로 패키징합니다.
    • 패키징된 WAR 파일은 외부 WAS에 배포됩니다. WAS는 이 WAR 파일을 읽어 애플리케이션을 실행하고, HTTP 요청을 처리합니다.
    • 외부 WAS가 웹 서버의 역할을 하며, 애플리케이션 로직을 실행하고 클라이언트의 요청을 처리하는 것은 WAS에서 이루어집니다.

Spring Boot

  • 기본 개념:
    • Spring Boot는 Spring Framework의 확장판으로, 빠르고 간편한 애플리케이션 개발을 목표로 합니다.
    • Spring Boot는 "자체 실행 가능한 JAR 파일"로 애플리케이션을 패키징하고 실행할 수 있으며, Tomcat, Jetty, Undertow와 같은 내장 웹 애플리케이션 서버(WAS)를 포함할 수 있습니다.
  • 작동 방식:
    • Spring Boot 애플리케이션은 내장된 WAS (예: 내장 Tomcat)를 포함하여 실행됩니다. 이 WAS가 웹 서버의 역할도 겸합니다.
    • 애플리케이션이 시작되면, 내장된 WAS가 함께 실행되며, HTTP 요청을 수신하고 처리할 준비를 합니다.
    • Spring Boot 애플리케이션이 실행될 때, 서버가 자동으로 설정되고, @RestController, @RequestMapping과 같은 Spring 애노테이션을 통해 정의된 웹 엔드포인트가 WAS에 의해 관리됩니다.
    • 개발자는 별도의 외부 WAS를 설치하거나 관리할 필요 없이, 애플리케이션 실행만으로 모든 기능이 동작하게 됩니다.

 

서버의 작동 방식

  • Spring Framework:
    • 외부 WAS (예: Tomcat, JBoss)에 WAR 파일 형태로 애플리케이션을 배포합니다.
    • WAS는 클라이언트의 HTTP 요청을 처리하고, Spring의 애플리케이션 로직을 실행합니다.
    • 웹 서버와 WAS의 역할은 분리되어 있으며, WAS가 둘 다 담당합니다.
  • Spring Boot:
    • 내장 WAS (예: 내장 Tomcat)를 포함한 자체 실행 가능한 JAR 파일 형태로 애플리케이션을 패키징합니다.
    • 애플리케이션 실행 시 내장 WAS가 함께 실행되어 웹 서버와 WAS의 역할을 동시에 수행합니다.
    • 별도의 외부 WAS가 필요 없으며, 개발자가 쉽게 서버를 설정하고 애플리케이션을 실행할 수 있습니다.

 

 

 

 

EC2와 ECS

  • AWS EC2 (Elastic Compute Cloud):
    • EC2는 AWS에서 제공하는 가상 서버
    • 사용자가 원하는 운영체제를 선택하여 서버를 생성할 수 있다
    • 애플리케이션을 설치하고 실행할 수 있습니다.
    • 웹 서버(Nginx, Apache 등)를 설치하여 운영하거나, 데이터베이스 서버, 애플리케이션 서버 등으로 사용할 수 있습니다.
    • EC2는 물리 서버의 가상화된 형태로서, 사용자가 서버의 자원(CPU, 메모리, 스토리지 등)을 제어하고 관리할 수 있습니다.
  • AWS ECS (Elastic Container Service):
    • ECS는 Docker 컨테이너를 관리하고 실행할 수 있는 컨테이너 오케스트레이션 서비스
    • 컨테이너로 패키징된 애플리케이션을 배포, 관리할 수 있으며, 컨테이너 내부에서 웹 서버나 애플리케이션 서버가 실행될 수 있습니다.
    • ECS는 컨테이너의 스케일링, 로드 밸런싱, 서비스 발견 등을 자동으로 관리합니다.

 

웹 서버와 EC2/ECS의 관계

  • 웹 서버와 EC2:
    • EC2 인스턴스에 웹 서버 소프트웨어(Apache, Nginx 등)를 설치하여, HTTP 요청을 처리하고 웹 애플리케이션을 호스팅할 수 있습니다.
    • EC2는 웹 서버를 설치하고 운영할 수 있는 인프라 역할을 합니다.
  • 웹 서버와 ECS:
    • ECS에서 컨테이너로 실행되는 애플리케이션에 웹 서버가 포함될 수 있습니다. 예를 들어, Nginx가 설치된 Docker 이미지를 사용하여 웹 서버를 ECS에서 실행할 수 있습니다.
    • ECS는 컨테이너 기반 웹 서버의 실행과 관리를 담당합니다.

요약

  • 웹 서버는 HTTP 요청을 처리하고 웹 페이지나 데이터를 클라이언트에게 제공하는 소프트웨어입니다.
  • EC2는 AWS에서 제공하는 가상 서버로, 웹 서버 소프트웨어를 설치하여 운영할 수 있습니다.
  • ECS는 컨테이너화된 애플리케이션을 관리하는 서비스로, 컨테이너 내부에서 웹 서버를 실행할 수 있습니다.

웹 서버는 애플리케이션을 실제로 실행하고 HTTP 요청을 처리하는 역할을 하며, EC2와 ECS는 그러한 웹 서버가 운영될 수 있는 인프라 환경을 제공한다고 볼 수 있습니다.

 

 

 

 

JVM에서 해석 과정

 

JAR 파일 해석 과정

  • JVM 초기화:
    • JVM이 시작되고, JAR 파일이 JVM에 전달됩니다.
  • 클래스 로더(ClassLoader):
    • JVM의 클래스 로더는 JAR 파일의 내부를 탐색하여 필요한 .class 파일을 로드합니다.
    • 클래스 로더는 MANIFEST.MF 파일을 읽어 메인 클래스를 찾아, 이 클래스의 main 메서드를 실행합니다.
  • 실행 환경 설정:
    • JVM은 메모리 공간을 할당하고, 런타임 스택, 힙, 메소드 영역을 설정하여 애플리케이션이 사용할 수 있는 환경을 준비합니다.
  • 바이트코드 실행:
    • JVM의 실행 엔진은 로드된 클래스의 바이트코드를 해석하고, JIT(Just-In-Time) 컴파일러를 통해 네이티브 코드로 변환하여 CPU에서 실행합니다.
  • 애플리케이션 실행:
    • main 메서드가 호출되며 애플리케이션 로직이 실행됩니다.
  • 종료:
    • 애플리케이션이 종료되면, JVM은 자원을 정리하고 종료됩니다.

 

WAR 파일 해석 과정

  • WAS 초기화:
    • WAS가 시작되면서 WAR 파일이 배포됩니다. 이 과정에서 WAS는 WAR 파일을 해석하여 필요한 구성 정보를 읽습니다.
  • 클래스 로딩:
    • WAS의 클래스 로더가 WEB-INF/classes 및 WEB-INF/lib 폴더에 있는 클래스와 라이브러리 JAR 파일을 로드합니다.
  • 서블릿 컨테이너 초기화:
    • WAS는 web.xml 파일을 읽어 서블릿, 필터, 리스너와 같은 웹 구성 요소를 초기화합니다.
  • 애플리케이션 컨텍스트 설정:
    • WAS는 애플리케이션 컨텍스트를 설정하고, 서블릿 매핑 및 URL 패턴과 같은 설정을 기반으로 요청을 처리할 준비를 합니다.
  • 요청 처리 및 실행:
    • 클라이언트로부터 HTTP 요청이 들어오면, WAS는 이를 서블릿 컨테이너로 전달하고, 서블릿이 요청을 처리하여 응답을 생성합니다.
  • 서버 실행 유지:
    • WAS는 서버를 계속 실행 상태로 유지하며, 클라이언트의 추가 요청을 처리합니다.

 

 

 

 

 

 

 

 

 

저작자표시

'CS Study' 카테고리의 다른 글

8월 4주차 GC  (0) 2024.08.19
8월 4주차 JDK, JRE, JVM  (0) 2024.08.19
8월 3주차  (0) 2024.08.12
8월 2주차 - 개인 질문  (0) 2024.08.05
8월 2주차 - 공통 질문  (0) 2024.08.05

'CS Study' Related Articles

티스토리툴바