기록만이살길

두 개의 JSON 개체를 Jackson과 비교

기록만이살길 — Thu, 23 Mar 2023 22:15:24 +0900

1. 개요

이 예제에서는 Java용 JSON 처리 라이브러리인 Jackson을 사용하여 두 개의 JSON 개체를 비교하는 방법을 살펴보겠습니다 .

2. 메이븐 의존성

먼저 jackson-databind Maven 의존성을 추가해 보겠습니다 .

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.13.3</version>
</dependency>

3. Jackson을 사용하여 두 개의 JSON 개체 비교

ObjectMapper 클래스를 사용하여 객체를 JsonNode 로 읽습니다 .

ObjectMapper를 만들어 봅시다 .

ObjectMapper mapper = new ObjectMapper();

3.1. 두 개의 간단한 JSON 개체 비교

JsonNode.equals 메서드를 사용하여 시작하겠습니다 . equals () 메서드는 전체(심층) 비교를 수행합니다.

s1 변수 로 정의된 JSON 문자열이 있다고 가정합니다 .

{
    "employee":
    {
        "id": "1212",
        "fullName": "John Miles",
        "age": 34
    }
}

그리고 이를 다른 JSON인 s2 와 비교하려고 합니다 .

{   
    "employee":
    {
        "id": "1212",
        "age": 34,
        "fullName": "John Miles"
    }
}

입력 JSON을 JsonNode 로 읽고 비교해 보겠습니다.

assertEquals(mapper.readTree(s1), mapper.readTree(s2));

입력 JSON 변수 s1 및 s2 의 속성 순서가 동일하지 않더라도 equals() 메서드는 순서를 무시하고 동일한 것으로 취급한다는 점에 유의해야 합니다 .

3.2. 두 개의 JSON 개체를 중첩 요소와 비교

다음으로 중첩 요소가 있는 두 JSON 개체를 비교하는 방법을 살펴보겠습니다.

s1 변수 로 정의된 JSON부터 시작하겠습니다 .

{ 
    "employee":
    {
        "id": "1212",
        "fullName":"John Miles",
        "age": 34,
        "contact":
        {
            "email": "john@xyz.com",
            "phone": "9999999999"
        }
    }
}

보시다시피 JSON에는 중첩된 요소인 contact 이 포함되어 있습니다 .

s2 로 정의된 다른 JSON과 비교하려고 합니다 .

{
    "employee":
    {
        "id": "1212",
        "age": 34,
        "fullName": "John Miles",
        "contact":
        {
            "email": "john@xyz.com",
            "phone": "9999999999"
        }
    }
}

입력 JSON을 JsonNode 로 읽고 비교해 보겠습니다.

assertEquals(mapper.readTree(s1), mapper.readTree(s2));

다시 말하지만 equals()는 두 개의 입력 JSON 개체를 중첩된 요소와 비교할 수도 있습니다.

3.3. List 요소를 포함하는 두 개의 JSON 개체 비교

마찬가지로 List 요소를 포함하는 두 개의 JSON 개체를 비교할 수도 있습니다.

s1 로 정의된 이 JSON을 살펴보겠습니다 .

{
    "employee":
    {
        "id": "1212",
        "fullName": "John Miles",
        "age": 34,
        "skills": ["Java", "C++", "Python"]
    }
}

다른 JSON인 s2 와 비교하고 있습니다 .

{
    "employee":
    {
        "id": "1212",
        "age": 34,
        "fullName": "John Miles",
        "skills": ["Java", "C++", "Python"] 
    } 
}

입력 JSON을 JsonNode 로 읽고 비교해 보겠습니다.

assertEquals(mapper.readTree(s1), mapper.readTree(s2));

두 개의 List 요소가 동일한 순서로 동일한 값을 갖는 경우에만 동일한 것으로 비교된다는 점을 아는 것이 중요합니다 .

4. 두 개의 JSON 개체를 사용자 지정 비교기와 비교

JsonNode.equals는 대부분의 경우 잘 작동합니다. Jackson은 또한 JsonNode.equals(comparator, JsonNode)를 제공하여 사용자 정의 Java Comparator 개체를 구성합니다.

사용자 정의 Comparator 를 사용하는 방법을 이해해 봅시다 .

4.1. 숫자 값을 비교하기 위한 사용자 지정 비교기

사용자 지정 Comparator를 사용하여 숫자 값이 있는 두 JSON 요소를 비교하는 방법을 살펴보겠습니다 .

이 JSON을 입력 s1 로 사용합니다 .

{
    "name": "John",
    "score": 5.0
}

s2 로 정의된 다른 JSON과 비교해 보겠습니다 .

{
    "name": "John",
    "score": 5
}

입력 s1 과 s2 의 속성 점수 값이 동일하지 않다는 것을 관찰해야 합니다 .

입력 JSON을 JsonNode 로 읽고 비교해 보겠습니다.

JsonNode actualObj1 = mapper.readTree(s1);
JsonNode actualObj2 = mapper.readTree(s2);

assertNotEquals(actualObj1, actualObj2);

두 개체가 같지 않음에 유의하십시오. 표준 equals() 메서드는 값 5.0과 5를 다른 것으로 간주합니다.

그러나 사용자 정의 비교기를 사용하여 값 5와 5.0을 비교하고 동일하게 취급할 수 있습니다.

먼저 두 개의 NumericNode 개체를 비교하기 위해 Comparator를 생성해 보겠습니다 .

public class NumericNodeComparator implements Comparator<JsonNode> 
{
    @Override
    public int compare(JsonNode o1, JsonNode o2)
    {
        if (o1.equals(o2)){
           return 0;
        }
        if ((o1 instanceof NumericNode) && (o2 instanceof NumericNode)){
            Double d1 = ((NumericNode) o1).asDouble();
            Double d2 = ((NumericNode) o2).asDouble(); 
            if (d1.compareTo(d2) == 0) {
               return 0;
            }
        }
        return 1;
    }
}

다음으로 이 비교기를 사용하는 방법을 살펴보겠습니다 .

NumericNodeComparator cmp = new NumericNodeComparator();
assertTrue(actualObj1.equals(cmp, actualObj2));

4.2. 텍스트 값을 비교하기 위한 사용자 지정 비교기

두 JSON 값의 대/소문자를 구분하지 않는 비교를 위한 사용자 지정 Comparator 의 또 다른 예를 살펴보겠습니다 .

이 JSON을 입력 s1 로 사용합니다 .

{
    "name": "john", 
    "score": 5 
}

s2 로 정의된 다른 JSON과 비교해 보겠습니다 .

{ 
    "name": "JOHN", 
    "score": 5 
}

보시다시피 속성 이름은 입력 s1 에서 소문자 이고 s2 에서 대문자입니다 .

먼저 두 개의 TextNode 개체를 비교하기 위해 Comparator를 만들어 보겠습니다 .

public class TextNodeComparator implements Comparator<JsonNode> 
{
    @Override
    public int compare(JsonNode o1, JsonNode o2) {
        if (o1.equals(o2)) {
            return 0;
        }
        if ((o1 instanceof TextNode) && (o2 instanceof TextNode)) {
            String s1 = ((TextNode) o1).asText();
            String s2 = ((TextNode) o2).asText();
            if (s1.equalsIgnoreCase(s2)) {
                return 0;
            }
        }
        return 1;
    }
}

TextNodeComparator를 사용하여 s1 과 s2를 비교하는 방법을 살펴보겠습니다 .

JsonNode actualObj1 = mapper.readTree(s1);
JsonNode actualObj2 = mapper.readTree(s2);

TextNodeComparator cmp = new TextNodeComparator();

assertNotEquals(actualObj1, actualObj2);
assertTrue(actualObj1.equals(cmp, actualObj2));

마지막으로, 입력 JSON 요소 값이 정확히 동일하지 않지만 여전히 동일한 것으로 취급하려는 경우 두 JSON 개체를 비교하는 동안 사용자 지정 비교기 개체를 사용하는 것을 볼 수 있습니다 .

5. 결론

이 빠른 기사에서는 Jackson을 사용하여 두 개의 JSON 객체를 비교하고 사용자 정의 비교기를 사용하는 방법을 살펴보았습니다 .

항상 그렇듯이 여기에서 논의된 모든 예제의 전체 소스 코드는 GitHub 에서 찾을 수 있습니다 .

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/jackson-compare-two-json-objects

Jackson으로 중첩 값 매핑

기록만이살길 — Thu, 23 Mar 2023 22:09:39 +0900

1. 개요

JSON으로 작업할 때의 일반적인 사용 사례는 한 모델에서 다른 모델로 변환을 수행하는 것입니다. 예를 들어 복잡하고 조밀하게 중첩된 개체 그래프를 다른 도메인에서 사용하기 위해 보다 간단한 모델로 구문 분석할 수 있습니다.

이 빠른 사용방법(예제)에서는 중첩된 값을 Jackson 과 매핑하여 복잡한 데이터 구조를 평면화하는 방법을 살펴보겠습니다 . 다음 세 가지 방법으로 JSON을 역직렬화합니다.

@JsonProperty 사용
JsonNode 사용
커스텀 JsonDeserializer 사용

2. 메이븐 의존성

먼저 pom.xml 에 다음 의존성을 추가해 보겠습니다 .

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.13.3</version>
</dependency>

Maven Central 에서 최신 버전의 jackson-databind를 찾을 수 있습니다 .

3. JSON 소스

예제의 소스 자료로 다음 JSON을 고려하십시오.

구조는 인위적이지만 두 수준 깊이로 중첩된 속성을 포함합니다.

{
    "id": "957c43f2-fa2e-42f9-bf75-6e3d5bb6960a",
    "name": "The Best Product",
    "brand": {
        "id": "9bcd817d-0141-42e6-8f04-e5aaab0980b6",
        "name": "ACME Products",
        "owner": {
            "id": "b21a80b1-0c09-4be3-9ebd-ea3653511c13",
            "name": "Ultimate Corp, Inc."
        }
    }  
}

4. 간소화된 도메인 모델

아래의 Product 클래스 에서 설명하는 평면화된 도메인 모델에서 소스 JSON 내에서 한 수준 깊이 중첩된 brandName 을 추출합니다 .

또한 중첩된 브랜드 개체 내에서 두 수준 깊이 중첩된 ownerName 을 추출합니다 .

public class Product {

    private String id;
    private String name;
    private String brandName;
    private String ownerName;

    // standard getters and setters
}

5. 어노테이션으로 매핑

중첩된 brandName 속성을 매핑하려면 먼저 중첩된 브랜드 개체를 Map 으로 압축 해제하고 name 속성을 추출 해야 합니다 . ownerName 을 매핑하기 위해 중첩된 소유자 개체를 Map 으로 압축 해제 하고 이름 속성을 추출합니다.

@JsonProperty 와 Product 클래스 에 추가하는 몇 가지 사용자 지정 논리 의 조합을 사용하여 Jackson에게 중첩된 속성의 압축을 풀도록 지시할 수 있습니다 .

public class Product {
    // ...

    @SuppressWarnings("unchecked")
    @JsonProperty("brand")
    private void unpackNested(Map<String,Object> brand) {
        this.brandName = (String)brand.get("name");
        Map<String,String> owner = (Map<String,String>)brand.get("owner");
        this.ownerName = owner.get("name");
    }
}

클라이언트 코드는 이제 ObjectMapper를 사용하여 테스트 클래스 내에 문자열 상수 SOURCE_JSON 으로 존재하는 소스 JSON을 변환 할 수 있습니다.

@Test
public void whenUsingAnnotations_thenOk() throws IOException {
    Product product = new ObjectMapper()
      .readerFor(Product.class)
      .readValue(SOURCE_JSON);

    assertEquals(product.getName(), "The Best Product");
    assertEquals(product.getBrandName(), "ACME Products");
    assertEquals(product.getOwnerName(), "Ultimate Corp, Inc.");
}

6. JsonNode 로 매핑하기

중첩된 데이터 구조를 JsonNode 로 매핑하려면 약간의 추가 작업이 필요합니다.

여기서 ObjectMapper 의 readTree를 사용하여 원하는 필드를 구문 분석합니다.

@Test
public void whenUsingJsonNode_thenOk() throws IOException {
    JsonNode productNode = new ObjectMapper().readTree(SOURCE_JSON);

    Product product = new Product();
    product.setId(productNode.get("id").textValue());
    product.setName(productNode.get("name").textValue());
    product.setBrandName(productNode.get("brand")
      .get("name").textValue());
    product.setOwnerName(productNode.get("brand")
      .get("owner").get("name").textValue());

    assertEquals(product.getName(), "The Best Product");
    assertEquals(product.getBrandName(), "ACME Products");
    assertEquals(product.getOwnerName(), "Ultimate Corp, Inc.");
}

7. 사용자 지정 JsonDeserializer 로 매핑

중첩된 데이터 구조를 사용자 정의 JsonDeserializer 로 매핑하는 것은 구현 관점에서 JsonNode 접근 방식 과 동일합니다 .

먼저 JsonDeserializer를 만듭니다 .

public class ProductDeserializer extends StdDeserializer<Product> {

    public ProductDeserializer() {
        this(null);
    }

    public ProductDeserializer(Class<?> vc) {
        super(vc);
    }

    @Override
    public Product deserialize(JsonParser jp, DeserializationContext ctxt) 
      throws IOException, JsonProcessingException {
 
        JsonNode productNode = jp.getCodec().readTree(jp);
        Product product = new Product();
        product.setId(productNode.get("id").textValue());
        product.setName(productNode.get("name").textValue());
        product.setBrandName(productNode.get("brand")
          .get("name").textValue());
        product.setOwnerName(productNode.get("brand").get("owner")
          .get("name").textValue());		
        return product;
    }
}

7.1. Deserializer 수동 등록

사용자 지정 역직렬 변환기를 수동으로 등록하려면 클라이언트 코드에서 Module 에 JsonDeserializer를 추가하고 Module을 ObjectMapper 에 등록 하고 readValue를 호출해야 합니다 .

@Test
public void whenUsingDeserializerManuallyRegistered_thenOk()
 throws IOException {
 
    ObjectMapper mapper = new ObjectMapper();
    SimpleModule module = new SimpleModule();
    module.addDeserializer(Product.class, new ProductDeserializer());
    mapper.registerModule(module);

    Product product = mapper.readValue(SOURCE_JSON, Product.class);
 
    assertEquals(product.getName(), "The Best Product");
    assertEquals(product.getBrandName(), "ACME Products");
    assertEquals(product.getOwnerName(), "Ultimate Corp, Inc.");
}

7.2. 디시리얼라이저 자동 등록

JsonDeserializer 를 수동으로 등록하는 대신 클래스에 직접 deserializer를 등록 할 수 있습니다 .

@JsonDeserialize(using = ProductDeserializer.class)
public class Product {
    // ...
}

이 방법을 사용하면 수동으로 등록할 필요가 없습니다.

자동 등록을 사용하는 클라이언트 코드를 살펴보겠습니다.

@Test
public void whenUsingDeserializerAutoRegistered_thenOk()
  throws IOException {
 
    ObjectMapper mapper = new ObjectMapper();
    Product product = mapper.readValue(SOURCE_JSON, Product.class);

    assertEquals(product.getName(), "The Best Product");
    assertEquals(product.getBrandName(), "ACME Products");
    assertEquals(product.getOwnerName(), "Ultimate Corp, Inc.");
}

8. 결론

이 기사에서는 중첩된 값을 포함하는 JSON을 구문 분석하기 위해 Jackson을 사용하는 여러 가지 방법을 설명했습니다 . 더 많은 예제를 보려면 기본 Jackson Tutorial 페이지를 살펴보십시오 .

그리고 항상 그렇듯이 코드 스니펫은 GitHub 에서 찾을 수 있습니다 .

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/jackson-nested-values

Maven에서 WAR 파일 생성

기록만이살길 — Thu, 23 Mar 2023 22:05:07 +0900

1. 개요

웹 애플리케이션 리소스 또는 웹 애플리케이션 아카이브는 일반적으로 WAR 파일이라고 합니다. WAR 파일은 애플리케이션 서버에서 Java EE 웹 애플리케이션을 배포하는 데 사용됩니다. WAR 파일 내에서 모든 웹 구성 요소는 하나의 단일 단위로 압축됩니다. 여기에는 JAR 파일, JavaServer Pages, Java 서블릿, Java 클래스 파일, XML 파일, HTML 파일 및 웹 애플리케이션에 필요한 기타 리소스 파일이 포함됩니다.

Maven 은 컴파일, 패키징 및 아티팩트 관리와 같은 빌드 작업을 처리하기 위해 Java EE 프로젝트에서 널리 사용되는 인기 있는 빌드 관리 도구입니다. Maven WAR 플러그인을 사용하여 프로젝트를 WAR 파일 로 빌드 할 수 있습니다 .

이 예제에서는 Java EE 애플리케이션과 함께 Maven WAR 플러그인의 사용을 고려할 것입니다. 이를 위해 간단한 Maven Spring Boot 웹 애플리케이션을 만들고 여기에서 WAR 파일을 생성합니다.

2. Spring Boot 웹 애플리케이션 설정

간단한 Maven, Spring Boot 및 Thymeleaf 웹 애플리케이션을 만들어 WAR 파일 생성 프로세스를 시연해 보겠습니다.

먼저 Spring Boot 웹 애플리케이션을 빌드하는 데 필요한 pom.xml 파일 에 의존성을 추가합니다 .

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-tomcat</artifactId>
    <scope>provided</scope>
</dependency>

다음으로 MainController 클래스를 생성해 보겠습니다 . 이 클래스에서는 HTML 파일을 보기 위해 단일 GET 컨트롤러 메서드를 만들 것입니다 .

@Controller
public class MainController {

    @GetMapping("/")
    public String viewIndexPage(Model model) {
        model.addAttribute("header", "Maven Generate War");
        return "index";
    }
}

마지막으로 index.html 파일을 만들 차례입니다 . 부트스트랩 CSS 파일도 프로젝트에 포함되어 있으며 일부 CSS 클래스는 index.html 파일에서 사용됩니다.

<!DOCTYPE html>
<html lang="en" xmlns:th="http://www.thymeleaf.org">
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Index</title>
    <!-- Bootstrap core CSS -->
    <link th:href="@{/css/bootstrap.min.css}" rel="stylesheet">
</head>
<body>
    <nav class="navbar navbar-light bg-light">
        <div class="container-fluid">
            <a class="navbar-brand" href="#">
                Baeldung Tutorial
            </a>
        </div>
    </nav>
    <div class="container">
        <h1>[[${header}]]</h1>
    </div>
</body>
</html>

3. 메이븐 WAR 플러그인

Maven WAR 플러그인은 웹 애플리케이션의 모든 의존성, 클래스 및 리소스를 웹 애플리케이션 아카이브로 수집하고 컴파일하는 역할을 합니다.

Maven WAR 플러그인에는 몇 가지 정의된 목표가 있습니다.

war : 프로젝트의 패키징 단계에서 호출되는 기본 목표입니다. 패키징 유형이 war 인 경우 WAR 파일을 빌드합니다 .
exploded : 이 목표는 일반적으로 테스트 속도를 높이기 위해 프로젝트 개발 단계에서 사용됩니다. 지정된 디렉토리에 분해된 웹 앱을 생성합니다.
inplace : 분해된 목표 의 변형입니다 . 웹 응용 프로그램 폴더 내에 분해된 웹 응용 프로그램을 생성합니다.

pom.xml 파일 에 Maven WAR 플러그인을 추가해 보겠습니다 .

<plugin>
    <artifactId>maven-war-plugin</artifactId>
    <version>3.3.1</version>
</plugin>

이제 mvn install 명령을 실행하면 대상 폴더 내에 WAR 파일이 생성됩니다.

mvn:war:exploded 명령을 사용하여 폭발된 WAR을 대상 디렉토리 내부의 디렉토리로 생성할 수 있습니다. 이것은 일반 디렉토리이며 WAR 파일 내부의 모든 파일은 분해된 WAR 디렉토리 내부에 포함됩니다.

4. WAR 파일 콘텐츠 포함 또는 제외

Maven WAR 플러그인을 사용하여 WAR 파일의 내용을 필터링할 수 있습니다. WAR 파일 내에 additional_resources 폴더를 포함하도록 Maven WAR 플러그인을 구성해 보겠습니다 .

<plugin>
    <artifactId>maven-war-plugin</artifactId>
    <version>3.3.1</version>
    <configuration>
        <webResources>
            <resource>
                <directory>additional_resources</directory>
            </resource>
        </webResources>
    </configuration>
</plugin>

mvn install 명령을 실행하면 additional_resources 폴더 아래의 모든 콘텐츠를 WAR 파일 내에서 사용할 수 있습니다. 예를 들어 보고서와 같은 일부 추가 리소스를 WAR 파일에 추가해야 할 때 유용합니다.

5. 매니페스트 파일 편집

Maven WAR 플러그인을 사용하면 매니페스트 파일을 사용자 정의할 수 있습니다. 예를 들어 매니페스트 파일 에 클래스 경로를 추가할 수 있습니다 . 이는 WAR 파일이 보다 복잡한 구조에 있고 여러 모듈 간에 프로젝트 의존성을 공유해야 할 때 매우 유용합니다.

매니페스트 파일 에 클래스 경로를 추가하도록 Maven WAR 플러그인을 구성해 보겠습니다 .

<plugin>
    <artifactId>maven-war-plugin</artifactId>
    <version>3.3.1</version>
    <configuration>
        <archive>
            <manifest>
                <addClasspath>true</addClasspath>
            </manifest>
        </archive>
    </configuration>
</plugin>

6. 결론

이 짧은 사용방법(예제)에서는 Maven 빌드 도구를 사용하여 WAR 파일을 생성하는 방법에 대해 설명했습니다. 작업을 시연하기 위해 Maven Spring Boot 웹 애플리케이션을 만들었습니다. WAR 파일을 생성하기 위해 Maven WAR 플러그인이라는 특수 플러그인을 사용했습니다.

전체 소스 코드 예제는 GitHub에서 사용할 수 있습니다 .

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/maven-generate-war-file

Docker 컨테이너에 Java War 배포

기록만이살길 — Thu, 23 Mar 2023 22:01:56 +0900

1. 개요

이 사용방법(예제)에서는 Docker 컨테이너 내부에 Java WAR 파일을 배포하는 방법을 배웁니다 .

Java 커뮤니티에서 널리 사용되는 무료 오픈 소스 웹 서버인 Apache Tomcat 에 WAR 파일을 배포합니다 .

2. Tomcat에 WAR 파일 배포

WAR(Web Application Archive)은 모든 웹 애플리케이션 관련 파일과 해당 디렉토리 구조를 패키지하는 압축 아카이브 파일입니다.

간단하게 하기 위해 Tomcat에 WAR 파일을 배포하는 것은 해당 WAR 파일을 Tomcat 서버의 배포 디렉터리에 복사하는 것입니다. Linux의 배포 디렉터리는 $CATALINA_HOME/webapps 입니다 . $CATALINA_HOME은 Tomcat 서버의 설치 디렉터리를 나타냅니다.

그런 다음 배포 디렉터리 내에서 WAR 파일을 추출하는 Tomcat 서버를 다시 시작 해야 합니다 .

3. Docker 컨테이너에 WAR 배포

Tomcat 서버에 배포해야 하는 애플리케이션 ROOT.war 에 대한 WAR 파일이 있다고 가정해 보겠습니다 .

목표를 달성하려면 먼저 Dockerfile을 만들어야 합니다. 이 Dockerfile에는 애플리케이션을 실행하는 데 필요한 모든 의존성이 포함됩니다.

또한 이 Dockerfile을 사용하여 Docker 이미지를 만든 다음 Docker 컨테이너를 시작하는 단계를 수행합니다.

이제 이러한 단계를 하나씩 자세히 살펴보겠습니다.

3.1. Dockerfile 만들기

Tomcat의 최신 Docker 이미지를 Dockerfile의 기본 이미지로 사용합니다 . 이 이미지를 사용할 때의 이점은 필요한 모든 의존성/패키지가 미리 설치되어 있다는 것입니다. 예를 들어 최신 Ubuntu/CentOS Docker 이미지를 사용하는 경우 Java, Tomcat 및 기타 필수 패키지를 수동으로 설치해야 합니다.

필요한 모든 패키지가 이미 설치되어 있으므로 WAR 파일인 ROOT.war 를 Tomcat 서버의 배포 디렉터리에 복사하기만 하면 됩니다. 그게 다야!

자세히 살펴보겠습니다.

$ ls
Dockerfile  ROOT.war
$ cat Dockerfile 
FROM tomcat

COPY ROOT.war /usr/local/tomcat/webapps/

$CATALINA_HOME/webapps는 Tomcat의 배포 디렉터리를 나타냅니다 . 여기에서Tomcat의 공식 Docker 이미지에 대한 CATALINA_HOME은 /usr/local/tomcat 입니다 . 결과적으로 완전한 배포 디렉토리는 /usr/local/tomcat/webapps 가 됩니다 .

여기서 사용한 애플리케이션은 매우 간단하며 다른 의존성이 필요하지 않습니다.

3.2. 도커 이미지 빌드

이제 방금 만든 Dockerfile을 사용하여 Docker 이미지를 만들어 보겠습니다.

$ pwd
/baeldung
$ ls
Dockerfile  ROOT.war
$ docker build -t myapp .
Sending build context to Docker daemon  19.97kB
Step 1/2 : FROM tomcat
 ---> 710ec5c56683
Step 2/2 : COPY ROOT.war /usr/local/tomcat/webapps/
 ---> Using cache
 ---> 8b132ab37a0e
Successfully built 8b132ab37a0e
Successfully tagged myapp:latest

docker build 명령은 myapp 태그가 있는 Docker 이미지를 생성합니다 .

Dockerfile이 있는 디렉터리 내에서 Docker 이미지를 빌드해야 합니다. 위의 예에서 우리는 Docker 이미지를 빌드할 때 /baeldung 디렉터리 안에 있습니다.

3.3. Docker 컨테이너 실행

지금까지 Dockerfile을 만들고 Docker 이미지를 빌드했습니다. 이제 Docker 컨테이너를 실행해 보겠습니다.

$ docker run -itd -p 8080:8080 --name my_application_container myapp
e90c61fdb4ac85b198903e4d744f7b0f3c18c9499ed6e2bbe2f39da0211d42c0
$ docker ps 
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                    NAMES
e90c61fdb4ac        myapp               "catalina.sh run"   6 seconds ago       Up 5 seconds        0.0.0.0:8080->8080/tcp   my_application_container

이 명령은 Docker 이미지 myapp를 사용하여 이름이 my_application_container 인 Docker 컨테이너를 시작합니다 .

Tomcat 서버의 기본 포트는 8080입니다. 따라서 Docker 컨테이너를 시작하는 동안 항상 컨테이너 포트 8080을 사용 가능한 호스트 포트와 바인딩해야 합니다. 여기에서는 단순화를 위해 호스트 포트 8080을 사용했습니다.

3.4. 설정 확인

이제 지금까지 수행한 모든 작업을 확인하겠습니다. 애플리케이션을 보기 위해 브라우저에서 URL http://<IP>:<PORT>에 액세스합니다 .

여기서 IP는 Docker 호스트 시스템의 공용 IP(또는 경우에 따라 개인 IP)를 나타냅니다. PORT 는 Docker 컨테이너(이 경우 8080)를 실행하는 동안 노출한 컨테이너 포트입니다.

Linux에서 curl 유틸리티를 사용하여 설정을 확인할 수도 있습니다 .

$ curl http://localhost:8080
Hi from Baeldung!!!

위의 명령에서 우리는 Docker 호스트 시스템에서 명령을 실행하고 있습니다. 따라서 localhost를 사용하여 애플리케이션에 연결할 수 있습니다 . 이에 대한 응답으로 curl 유틸리티는 애플리케이션 웹 페이지의 원시 HTML을 인쇄합니다.

4. 결론

이 기사에서는 Docker 컨테이너에 Java WAR 파일을 배포하는 방법을 배웠습니다. 공식 Tomcat Docker 이미지를 사용하여 Dockerfile을 만드는 것부터 시작했습니다. 그런 다음 Docker 이미지를 빌드하고 애플리케이션 컨테이너를 실행했습니다.

마지막으로 애플리케이션 URL에 액세스하여 설정을 확인했습니다.

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/docker-deploy-java-war

Maven과 실행 가능한 War/Jar로 Spring Boot 앱 실행

기록만이살길 — Thu, 23 Mar 2023 21:59:22 +0900

1. 소개

이 예제에서는 mvn spring-boot:run 명령을 통해 Spring Boot 웹 애플리케이션을 시작하는 것과 java -jar 명령 을 통해 jar/war 패키지로 컴파일한 후 실행하는 것의 차이점을 살펴보겠습니다 .

이 사용방법(예제)의 목적을 위해 Spring Boot 리패키지 목표 의 구성에 익숙하다고 가정합니다 . 이 항목에 대한 자세한 내용은 Spring Boot로 Fat Jar 앱 만들기를 참조하세요 .

2. Spring Boot Maven 플러그인

Spring Boot 애플리케이션을 작성할 때 Spring Boot Maven 플러그인은 코드를 빌드, 테스트 및 패키징하는 데 권장되는 도구입니다.

이 플러그인은 다음과 같은 편리한 기능을 많이 제공합니다.

올바른 의존성 버전을 해결합니다.
모든 의존성(필요한 경우 임베디드 애플리케이션 서버 포함)을 하나의 실행 가능한 팻 jar/war로 패키징할 수 있으며 다음도 수행합니다.
- 클래스 경로 구성을 관리하여 java -jar 명령 에서 긴 -cp 옵션을 건너뛸 수 있습니다.
- 이제 패키지 내부에 중첩된 모든 외부 jar 라이브러리를 찾아 로드하기 위해 사용자 정의 ClassLoader를 구현합니다.
- 자동으로 main() 메서드를 찾고 매니페스트에서 구성하므로 java -jar 명령 에서 기본 클래스를 지정할 필요가 없습니다.

3. 분해된 형태로 Maven으로 코드 실행하기

웹 애플리케이션에서 작업할 때 Spring Boot Maven 플러그인의 또 다른 매우 흥미로운 기능을 활용할 수 있습니다. 바로 임베디드 애플리케이션 서버에 웹 애플리케이션을 자동으로 배포하는 기능입니다.

Tomcat을 사용하여 코드를 실행하고 싶다는 것을 플러그인에 알리려면 하나의 의존성만 필요합니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId> 
</dependency>

이제 프로젝트 루트 폴더에서 mvn spring-boot:run 명령을 실행할 때 플러그인은 pom 구성을 읽고 웹 애플리케이션 컨테이너가 필요하다는 것을 이해합니다.

mvn spring-boot:run 명령을 실행하면 Apache Tomcat 다운로드가 트리거되고 Tomcat 시작이 초기화됩니다.

$ mvn spring-boot:run
...
...
[INFO] --------------------< com.baeldung:spring-boot-ops >--------------------
[INFO] Building spring-boot-ops 0.0.1-SNAPSHOT
[INFO] --------------------------------[ war ]---------------------------------
[INFO]
[INFO] >>> spring-boot-maven-plugin:2.1.3.RELEASE:run (default-cli) > test-compile @ spring-boot-ops >>>
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/tomcat/embed/tomcat-embed-core/9.0.16/tomcat-embed-core-9.0.16.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/tomcat/embed/tomcat-embed-core/9.0.16/tomcat-embed-core-9.0.16.pom (1.8 kB at 2.8 kB/s)
...
...
[INFO] --- spring-boot-maven-plugin:2.1.3.RELEASE:run (default-cli) @ spring-boot-ops ---
...
...
11:33:36.648 [main] INFO  o.a.catalina.core.StandardService - Starting service [Tomcat]
11:33:36.649 [main] INFO  o.a.catalina.core.StandardEngine - Starting Servlet engine: [Apache Tomcat/9.0.16]
...
...
11:33:36.952 [main] INFO  o.a.c.c.C.[Tomcat].[localhost].[/] - Initializing Spring embedded WebApplicationContext
...
...
11:33:48.223 [main] INFO  o.a.coyote.http11.Http11NioProtocol - Starting ProtocolHandler ["http-nio-8080"]
11:33:48.289 [main] INFO  o.s.b.w.e.tomcat.TomcatWebServer - Tomcat started on port(s): 8080 (http) with context path ''
11:33:48.292 [main] INFO  org.baeldung.boot.Application - Started Application in 22.454 seconds (JVM running for 37.692)

로그에 'Started Application'이 포함된 줄이 표시되면 브라우저 주소 http://localhost:8080/에서 웹 애플리케이션을 쿼리할 준비가 된 것입니다.

4. 코드를 독립 실행형 패키지 애플리케이션으로 실행

개발 단계를 통과하고 애플리케이션을 프로덕션으로 가져오는 과정이 진행되면 애플리케이션을 패키징해야 합니다.

안타깝게도 jar 패키지 로 작업하는 경우 기본 Maven 패키지 목표에는 외부 의존성이 포함되지 않습니다. 이는 더 큰 프로젝트에서 라이브러리로만 사용할 수 있음을 의미합니다.

이 제한을 피하려면 Maven Spring Boot 플러그인 리패키지 목표를 활용하여 jar/war를 독립 실행형 애플리케이션으로 실행 해야 합니다 .

4.1. 구성

일반적으로 빌드 플러그인만 구성하면 됩니다.

<build>
    <plugins>
        ...
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
        ...
    </plugins>
</build>

예제 프로젝트에는 둘 이상의 기본 클래스가 포함되어 있으므로 플러그인을 구성하여 실행할 클래스를 Java에 알려야 합니다.

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <configuration>
                <mainClass>com.baeldung.webjar.WebjarsdemoApplication</mainClass>
            </configuration>
        </execution>
    </executions>
</plugin>

또는 시작 클래스 속성 설정 :

<properties>
    <start-class>com.baeldung.webjar.WebjarsdemoApplication</start-class>
</properties>

4.2. 애플리케이션 실행

이제 두 가지 간단한 명령으로 예제 전쟁을 실행할 수 있습니다.

$ mvn clean package spring-boot:repackage
$ java -jar target/spring-boot-ops.war

jar 파일을 실행하는 방법에 대한 자세한 내용은 Run JAR Application With Command Line Arguments 문서에서 확인할 수 있습니다 .

4.3. 전쟁 파일 내부

위에서 언급한 명령이 전체 서버 애플리케이션을 실행하는 방법을 더 잘 이해하기 위해 spring-boot-ops.war를 살펴볼 수 있습니다 .

압축을 풀고 내부를 들여다보면 일반적인 용의자를 찾을 수 있습니다.

META-INF , 자동 생성된 MANIFEST.MF 포함
컴파일된 클래스를 포함하는 WEB-INF/classes
WEB-INF/lib , 우리의 전쟁 의존성 및 포함된 Tomcat jar 파일을 보유합니다.

팻 패키지 구성과 관련된 일부 폴더가 있기 때문에 이것이 전부는 아닙니다.

WEB-INF/lib-provided , 포함 실행 시 필요하지만 배포 시 필요하지 않은 외부 라이브러리 포함
org/springframework/boot/loader - Spring Boot 사용자 정의 클래스 로더를 보유합니다. 이 라이브러리는 외부 의존성을 로드하고 런타임에 액세스할 수 있도록 합니다.

4.4. 전쟁 선언문 내부

앞서 언급했듯이 Maven Spring Boot 플러그인은 메인 클래스를 찾아 java 명령 을 실행하는 데 필요한 구성을 생성합니다 .

결과 MANIFEST.MF에는 몇 가지 추가 줄이 있습니다.

Start-Class: com.baeldung.webjar.WebjarsdemoApplication
Main-Class: org.springframework.boot.loader.WarLauncher

특히 마지막 항목은 사용할 Spring Boot 클래스 로더 실행기를 지정하는 것을 볼 수 있습니다.

4.5. Jar 파일 내부

기본 패키징 전략으로 인해 우리의 전쟁 패키징 시나리오는 Spring Boot Maven Plugin을 사용하든 사용하지 않든 크게 다르지 않습니다 .

플러그인의 장점을 더 잘 이해하기 위해 pom 패키징 구성을 jar 로 변경하고 mvn clean 패키지를 다시 실행해 볼 수 있습니다 .

이제 fat jar가 이전 war 파일과 약간 다르게 구성되어 있음을 관찰할 수 있습니다.

모든 클래스 및 리소스 폴더는 이제 BOOT-INF/classes 아래에 있습니다 .
BOOT-INF/lib는 모든 외부 라이브러리를 보유합니다.

플러그인이 없으면 lib 폴더가 존재하지 않으며 BOOT-INF/classes 의 모든 콘텐츠는 패키지의 루트에 위치합니다.

4.6. Jar 매니페스트 내부

매니페스트 . MF도 변경되어 다음과 같은 추가 라인이 있습니다.

Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Spring-Boot-Version: 2.1.3.RELEASE
Main-Class: org.springframework.boot.loader.JarLauncher

Spring-Boot-Classes 와 Spring-Boot-Lib는 클래스 로더가 클래스와 외부 라이브러리를 찾을 위치를 알려주므로 특히 흥미롭습니다.

5. 선택 방법

도구를 분석할 때 이러한 도구가 만들어진 목적을 반드시 고려해야 합니다. 개발을 쉽게 하고 싶습니까, 아니면 원활한 배포 및 이식성을 보장하고 싶습니까? 이 선택에 의해 가장 영향을 받는 단계를 살펴보겠습니다.

5.1. 개발

개발자로서 우리는 코드를 로컬에서 실행하기 위해 환경을 설정하는 데 많은 시간을 할애할 필요 없이 대부분의 시간을 코딩하는 데 사용합니다. 간단한 응용 프로그램에서는 일반적으로 문제가 되지 않습니다. 그러나 보다 복잡한 프로젝트의 경우 환경 변수를 설정하고 서버를 시작하고 데이터베이스를 채워야 할 수 있습니다.

애플리케이션을 실행하려고 할 때마다 올바른 환경을 구성하는 것은 특히 둘 이상의 서비스를 동시에 실행해야 하는 경우 매우 비실용적입니다.

Maven으로 코드를 실행하면 도움이 됩니다. 우리는 이미 전체 코드베이스를 로컬에서 체크아웃했기 때문에 pom 구성 및 리소스 파일을 활용할 수 있습니다. 환경 변수를 설정하고 메모리 내 데이터베이스를 생성하며 올바른 서버 버전을 다운로드하고 하나의 명령으로 애플리케이션을 배포할 수도 있습니다.

각 모듈마다 다른 변수와 서버 버전이 필요한 다중 모듈 코드베이스에서도 Maven 프로필을 통해 올바른 환경을 쉽게 실행할 수 있습니다.

5.2. 생산

우리가 생산으로 이동할수록 대화는 안정성과 Security으로 더 많이 이동합니다. 그렇기 때문에 개발 시스템에 사용되는 프로세스를 실제 고객이 있는 서버에 적용할 수 없습니다.

이 단계에서 Maven을 통해 코드를 실행하는 것은 여러 가지 이유로 나쁜 습관입니다.

우선 Maven을 설치해야 합니다.
그런 다음 코드를 컴파일해야 하므로 전체 JDK(Java Development Kit)가 필요합니다.
다음으로 코드베이스를 서버에 복사하고 모든 독점 코드를 일반 텍스트로 남겨 두어야 합니다.
mvn 명령은 수명 주기의 모든 단계(소스 찾기, 컴파일 및 실행)를 실행해야 합니다 .
이전 포인트 덕분에 CPU도 낭비하고 클라우드 서버의 경우 돈도 낭비합니다.
Maven은 각각 메모리를 사용하는 여러 Java 프로세스를 생성합니다(기본적으로 각 프로세스는 상위 프로세스와 동일한 메모리 양을 사용함).
마지막으로 배포할 서버가 여러 개인 경우 위의 모든 작업이 각 서버에서 반복됩니다.

이것들은 응용 프로그램을 패키지로 배송하는 것이 생산에 더 실용적인 몇 가지 이유입니다 .

6. 결론

이 기사에서는 Maven을 통해 코드를 실행하는 것과 java -jar 명령 을 통해 코드를 실행하는 것의 차이점을 살펴보았습니다 . 또한 몇 가지 실제 사례 시나리오에 대한 간략한 개요도 살펴보았습니다.

이 기사에서 사용된 소스 코드는 GitHub에서 사용할 수 있습니다 .

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/spring-boot-run-maven-vs-executable-jar

JAR과 WAR 패키징의 차이점

기록만이살길 — Thu, 23 Mar 2023 21:54:34 +0900

1. 개요

이 빠른 사용방법(예제)에서는 Java에서 JAR과 WAR 패키징의 차이점에 중점을 둘 것입니다.

먼저 각 패키징 옵션을 개별적으로 정의합니다. 그런 다음 차이점을 요약하겠습니다.

2. JAR 패키징

간단히 말해서 JAR(또는 Java 아카이브)은 패키지 파일 형식입니다. JAR 파일은 .jar 확장자를 가지며 라이브러리, 리소스 및 메타데이터 파일을 포함할 수 있습니다 .

기본적으로 이것은 압축된 버전의 .class 파일과 컴파일된 Java 라이브러리 및 애플리케이션의 리소스를 포함하는 압축 파일입니다 .

예를 들어 다음은 간단한 JAR 파일 구조입니다.

META-INF/
    MANIFEST.MF
com/
    baeldung/
        MyApplication.class

META -INF/MANIFEST.MF 파일에는 아카이브에 저장된 파일에 대한 추가 메타데이터가 포함될 수 있습니다.

jar 명령이나 Maven 과 같은 도구를 사용하여 JAR 파일을 만들 수 있습니다 .

3. WAR 패키징

WAR은 웹 애플리케이션 아카이브 또는 웹 애플리케이션 리소스를 나타냅니다. 이러한 아카이브 파일은 .war 확장자를 가지며 모든 Servlet/JSP 컨테이너에 배포할 수 있는 웹 애플리케이션을 패키징하는 데 사용 됩니다 .

다음은 일반적인 WAR 파일 구조의 예시 레이아웃입니다.

META-INF/
    MANIFEST.MF
WEB-INF/
    web.xml
    jsp/
        helloWorld.jsp
    classes/
        static/
        templates/
        application.properties
    lib/
        // *.jar files as libs

내부에는 웹 아카이브에 대한 MANIFEST.MF 의 유용한 정보를 포함하는 META-INF 디렉토리 가 있습니다 . META -INF 디렉토리는 비공개이며 외부에서 접근할 수 없습니다.

반면에 HTML 페이지, 이미지 및 JS 파일을 포함한 모든 정적 웹 리소스가 있는 WEB-INF 공용 디렉토리도 포함합니다. 또한 web.xml 파일, 서블릿 클래스 및 라이브러리가 포함되어 있습니다.

.war 아카이브 를 빌드하기 위해 JAR을 빌드하는 데 사용한 것과 동일한 도구와 명령을 사용할 수 있습니다 .

4. 주요 차이점

그렇다면 이 두 아카이브 유형의 주요 차이점은 무엇입니까?

첫 번째이자 가장 분명한 차이점은 파일 확장자 입니다 . JAR의 확장자는 .jar 이고 WAR 파일의 확장자는 .war 입니다 .

두 번째 주요 차이점은 목적과 작동 방식 입니다 . JAR 파일을 사용하면 라이브러리, 플러그인 또는 모든 종류의 애플리케이션으로 사용하기 위해 여러 파일을 패키징할 수 있습니다. 반면 WAR 파일은 웹 애플리케이션에만 사용됩니다.

아카이브의 구조도 다릅니다. 원하는 구조로 JAR을 만들 수 있습니다. 반대로 WAR에는 WEB-INF 및 META-INF 디렉토리가 있는 미리 정의된 구조가 있습니다.

마지막으로 추가 소프트웨어를 사용하지 않고 실행 가능한 JAR 로 빌드하면 명령줄에서 JAR을 실행할 수 있습니다 . 또는 라이브러리로 사용할 수 있습니다. 반대로 WAR을 실행하려면 서버가 필요합니다 .

5. 결론

이 빠른 기사에서는 .jar 및 .war Java 패키징 유형을 비교했습니다 . 그렇게 함으로써 우리는 둘 다 동일한 ZIP 파일 형식을 사용하지만 몇 가지 중요한 차이점이 있다는 점에 주목했습니다.

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/java-jar-war-packaging

JBoss에서 WAR 파일 배포

기록만이살길 — Thu, 23 Mar 2023 21:52:19 +0900

1. 소개

이 예제에서는 JBoss 서버에 war 파일을 배포하는 방법을 살펴보겠습니다.

war 파일을 적절한 디렉토리에 수동으로 배치하거나 Eclipse에서 직접 배치하여 배치할 수 있습니다.

2. WAR 파일을 직접 배포

war 파일이 이미 있고 JBoss에 배포하려는 경우 standalone/deployments 의 JBoss 설치 디렉터리로 이동하여 거기에 파일을 붙여넣을 수 있습니다 .

배포가 작동하는 두 가지 모드가 있습니다.

수동: 배포 스캐너는 배포 폴더를 직접 모니터링하려고 시도하지 않습니다. 대신 스캐너는 마커 파일에 의존합니다. 사용자가 마커 파일을 추가하는 것은 스캐너가 콘텐츠를 배포하도록 지시하는 일종의 명령 역할을 합니다.
자동: 스캐너가 배포 폴더를 직접 모니터링하여 새 콘텐츠를 자동으로 배포하고 타임스탬프가 변경된 콘텐츠를 다시 배포합니다.

auto-deploy-zipped 속성 값을 true 또는 false 로 설정하여 구성 파일 standalone.xml 에서 모드를 지정할 수 있습니다 .

<deployment-scanner 
  name="default" 
  path="deployments" 
  scan-enabled="true" 
  scan-interval="5000" 
  relative-to="jboss.server.base.dir" 
  auto-deploy-zipped="true" 
  deployment-timeout="60"/>

기본적으로 값은 true 입니다 . 따라서 배포 폴더에 war 파일을 배치할 때마다 자동으로 배포됩니다. JBoss는 콘텐츠가 배포되었음을 나타내는 .deployed 마커 파일을 자동으로 생성합니다.

그러나 새 war 파일을 배포 폴더에 복사하기 전에 이전 배포를 제거하면 JBoss는 배포가 제거되었음을 제안하는 .undeployed 마커 파일 을 생성합니다 . 이 경우 배포를 시작하려면 마커 파일을 수동으로 삭제해야 합니다.

auto-deploy-zipped 값이 false 로 설정된 경우 배포를 시작하려면 .deployed 마커 파일을 수동으로 생성해야 합니다 .

3. Eclipse를 사용하여 배포

Eclipse에서 동적 웹 프로젝트를 생성하고 JBoss 서버를 추가한 다음 서버에서 실행되도록 애플리케이션을 구성 할 수 있습니다 . 내부적으로 Eclipse는 애플리케이션의 war 파일을 생성하고 JBoss 디렉토리에 배치합니다. index.html 파일을 만들고 web.xml 의 welcome-file이 이 파일 을 가리키도록 설정할 수 있습니다.

응용 프로그램이 성공적으로 배포되었는지 테스트하기 위해 웹 브라우저를 시작하고 다음 형식으로 URL에 액세스할 수 있습니다. http://localhost: <portnumber>/<projectname>

인덱스 페이지가 표시되면 애플리케이션이 성공적으로 배포된 것입니다.

4. 결론

이 기사에서는 배포 폴더로 작업하고 Eclipse를 사용하여 JBoss 서버에 war 파일을 배포하는 방법을 살펴보았습니다.

또한 자동 및 수동 배포 모드와 이들이 JBoss의 마커 파일과 함께 작동하는 방식에 대해서도 논의했습니다.

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/jboss-war-deploy

WAR 파일을 Tomcat에 배포하는 방법

기록만이살길 — Thu, 23 Mar 2023 21:50:23 +0900

1. 개요

Apache Tomcat은 Java 커뮤니티에서 가장 인기 있는 웹 서버 중 하나입니다. WAR 확장이 있는 웹 아카이브를 제공할 수 있는 서블릿 컨테이너 로 제공됩니다 .

컨테이너를 다시 시작하지 않고도 새 웹 애플리케이션을 배포하거나 기존 애플리케이션을 배포 취소할 수 있는 관리 대시보드를 제공합니다 . 이는 프로덕션 환경에서 특히 유용합니다.

이 예제에서는 Tomcat에 대한 간략한 개요를 수행한 다음 WAR 파일 배포에 대한 다양한 접근 방식을 다룰 것입니다.

2. 톰캣 구조

시작하기 전에 몇 가지 용어와 환경 변수에 익숙해져야 합니다.

2.1. 환경 변수

이전에 Tomcat으로 작업한 적이 있다면 익숙할 것입니다.

이 변수는 서버가 설치된 디렉토리를 가리킵니다.

$CATALINA_HOME

이 변수는 특정 Tomcat 인스턴스의 디렉토리를 가리킵니다(여러 인스턴스가 설치되어 있을 수 있음).

$CATALINA_BASE

이 변수가 명시적으로 설정되지 않으면 $CATALINA_HOME 과 동일한 값이 할당됩니다 .

웹 응용 프로그램은 $CATALINA_HOME\webapps 디렉터리 아래에 배포됩니다 .

2.2. 술어

문서 루트 - JSP 파일, HTML 페이지, Java 클래스 및 이미지와 같은 모든 응용 프로그램 리소스가 있는 웹 응용 프로그램의 최상위 디렉터리를 나타냅니다.

컨텍스트 경로 – 서버 주소에 상대적인 위치를 나타내며 웹 애플리케이션의 이름을 나타냅니다.

예를 들어 웹 애플리케이션이 $CATALINA_HOME\webapps\myapp 디렉토리 아래에 있는 경우 URL http://localhost/myapp 로 액세스할 수 있으며 해당 컨텍스트 경로는 /myapp 입니다 .

WAR – 웹 아카이브의 약자. 웹 애플리케이션 디렉토리 계층 구조를 ZIP 형식으로 패키징하는 파일의 확장자입니다. Java 웹 응용 프로그램은 일반적으로 배포용 WAR 파일로 패키지됩니다. 이러한 파일은 Eclipse와 같은 IDE를 사용하거나 명령줄에서 만들 수 있습니다.

WAR 파일을 배포한 후 Tomcat은 압축을 풀고 webapps 디렉터리 의 모든 프로젝트 파일을 프로젝트 이름을 딴 새 디렉터리에 저장합니다.

3. 톰캣 설정

Tomcat Apache 웹 서버는 웹 사이트에서 다운로드 할 수 있는 무료 소프트웨어입니다 . 사용자 시스템에 사용 가능한 JDK가 있고 JAVA_HOME 환경 변수가 올바르게 설정되어 있어야 합니다.

3.1. 톰캣 시작

$CATALINA_HOME\bin\startup 에 있는 시작 스크립트를 실행하여 Tomcat 서버를 시작할 수 있습니다 . 모든 설치에는 .bat 및 .sh 가 있습니다 .

Windows 또는 Unix 기반 운영 체제를 사용하는지 여부에 따라 적절한 옵션을 선택합니다.

3.2. 역할 구성

배포 단계 동안 몇 가지 옵션이 있으며 그 중 하나는 Tomcat의 관리 대시보드를 사용하는 것입니다. 이 대시보드에 액세스하려면 적절한 역할로 구성된 관리 사용자가 있어야 합니다.

대시보드에 액세스하려면 admin 사용자에게 manager-gui 역할이 필요합니다. 나중에 Maven을 사용하여 WAR 파일을 배포해야 하며 이를 위해 관리자 스크립트 역할도 필요합니다.

$CATALINA_HOME\conf\tomcat-users 에서 다음과 같이 변경해 보겠습니다 .

<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<user username="admin" password="password" roles="manager-gui, manager-script"/>

다른 Tomcat 역할에 대한 자세한 내용은 이 공식 링크를 따라 찾을 수 있습니다 .

3.3. 디렉토리 권한 설정

마지막으로 Tomcat 설치 디렉터리에 대한 읽기/쓰기 권한이 있는지 확인합니다.

3.4. 테스트 설치

Tomcat이 제대로 설정되었는지 테스트하기 위해 시작 스크립트( startup.bat / startup.sh )를 실행합니다. 콘솔에 오류가 표시되지 않으면 http://localhost:8080 을 방문하여 다시 확인할 수 있습니다 .

Tomcat 랜딩 페이지가 보이면 서버를 올바르게 설치한 것입니다.

3.5. 포트 충돌 해결

기본적으로 Tomcat은 포트 8080 에서 연결을 수신 대기하도록 설정되어 있습니다 . 이 포트에 이미 바인딩된 다른 애플리케이션이 있는 경우 시작 콘솔에서 알려줍니다.

포트를 변경하려면 $CATALINA_HOME\conf\server.xml 에 있는 서버 구성 파일인 server.xml을 편집하면 됩니다 . 기본적으로 커넥터 구성은 다음과 같습니다.

<Connector port="8080" protocol="HTTP/1.1" 
  connectionTimeout="20000" redirectPort="8443" />

예를 들어 포트를 8081 로 변경하려면 커넥터의 포트 속성을 변경해야 합니다.

<Connector port="8081" protocol="HTTP/1.1" 
  connectionTimeout="20000" redirectPort="8443" />

때로는 선택한 포트가 기본적으로 열려 있지 않습니다. 이 경우 Unix 커널에서 적절한 명령으로 포트를 열거나 Windows에서 적절한 방화벽 규칙을 생성해야 합니다. 이 문서의 범위를 벗어나므로 여기서는 더 자세히 설명하지 않습니다.

4. Maven에서 배포

웹 아카이브를 배포하기 위해 Maven을 사용하려면 Maven의 settings.xml 파일에서 Tomcat을 서버로 구성해야 합니다.

settings.xml 파일을 찾을 수 있는 위치는 두 곳입니다 .

Maven 설치: ${maven.home}/conf/settings.xml
사용자 설치: ${user.home}/.m2/settings.xml

찾으면 Tomcat을 추가합니다.

<server>
    <id>TomcatServer</id>
    <username>admin</username>
    <password>password</password>
</server>

이제 배포를 테스트하기 위해 Maven에서 기본 웹 애플리케이션을 만들어야 합니다. 애플리케이션을 생성할 위치로 이동해 보겠습니다.

콘솔에서 이 명령을 실행하여 새 Java 웹 애플리케이션을 생성합니다.

mvn archetype:generate -DgroupId=com.baeldung -DartifactId=tomcat-war-deployment 
  -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

이렇게 하면 tomcat-war-deployment 디렉토리에 완전한 웹 애플리케이션이 생성되고 hello world! 지금 배포하고 브라우저를 통해 액세스한다면.

하지만 그 전에 Maven 배포를 활성화하기 위해 한 가지 변경을 수행해야 합니다. pom.xml 로 이동하여 이 플러그인을 추가해 보겠습니다.

<plugin>
    <groupId>org.apache.tomcat.maven</groupId>
    <artifactId>tomcat7-maven-plugin</artifactId>
    <version>2.2</version>
    <configuration>
        <url>http://localhost:8080/manager/text</url>
        <server>TomcatServer</server>
        <path>/myapp</path>
    </configuration>
</plugin>

특별한 변경 없이 버전 7과 8 모두에서 작동하기 때문에 Tomcat 7 플러그인을 사용하고 있습니다.

구성 URL은 배포를 보내는 URL이며 Tomcat은 이를 사용하여 수행할 작업을 알 수 있습니다. server 요소 는 Maven이 인식하는 서버 인스턴스의 이름입니다. 마지막으로 경로 요소는 배포의 컨텍스트 경로를 정의합니다 .

즉, 배포가 성공하면 http://localhost:8080/myapp 를 눌러 웹 애플리케이션에 액세스합니다 .

이제 Maven에서 다음 명령을 실행할 수 있습니다.

웹 앱을 배포하려면:

mvn tomcat7:deploy

그런 다음 배포를 취소하려면 다음을 수행하십시오.

mvn tomcat7:undeploy

마지막으로 변경 후 재배포하려면 다음을 수행하십시오.

mvn tomcat7:redeploy

5. Cargo 플러그인으로 배포

Cargo 는 다양한 유형의 애플리케이션 컨테이너를 표준 방식으로 조작할 수 있는 다목적 라이브러리입니다.

5.1. 화물 배치 설정

이 섹션에서는 WAR을 Tomcat에 배포하기 위해 Cargo의 Maven 플러그인을 사용하는 방법을 배웁니다. 이 경우 버전 7 인스턴스에 배포합니다.

전체 프로세스를 확실하게 이해하기 위해 명령줄에서 새 Java 웹 애플리케이션을 생성하여 처음부터 시작하겠습니다.

mvn archetype:generate -DgroupId=com.baeldung -DartifactId=cargo-deploy 
  -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

그러면 cargo-deploy 디렉토리 에 완전한 자바 웹 애플리케이션이 생성됩니다 . 이 애플리케이션을 그대로 빌드, 배포 및 로드하면 Hello World! 브라우저에서.

Tomcat7 Maven 플러그인과 달리 Cargo Maven 플러그인은 이 파일이 있어야 합니다.

웹 애플리케이션에는 서블릿이 포함되어 있지 않으므로 web.xml 파일은 매우 기본적입니다. 새로 생성된 프로젝트의 WEB-INF 폴더 로 이동 하고 다음 내용으로 web.xml 파일을 생성합니다.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns="http://java.sun.com/xml/ns/javaee" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
      http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" 
        id="WebApp_ID" version="3.0">

    <display-name>cargo-deploy</display-name>
    <welcome-file-list>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>
</web-app>

Maven이 정규화된 이름을 입력하지 않고 Cargo의 명령을 인식할 수 있도록 하려면 Maven의 settings.xml에 있는 플러그인 그룹에 Cargo Maven 플러그인을 추가해야 합니다 .

루트 <settings></settings> 요소의 직계 자식으로 다음을 추가합니다.

<pluginGroups>
    <pluginGroup>org.codehaus.cargo</pluginGroup>
</pluginGroups>

5.2. 로컬 배포

이 하위 섹션에서는 새 배포 요구 사항에 맞게 pom.xml을 편집합니다 .

다음 플러그인을 추가합니다.

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.cargo</groupId>
            <artifactId>cargo-maven2-plugin</artifactId>
            <version>1.5.0</version>
            <configuration>
                <container>
                    <containerId>tomcat7x</containerId>
                    <type>installed</type>
                    <home>Insert absolute path to tomcat 7 installation</home>
                </container>
                <configuration>
                    <type>existing</type>
                    <home>Insert absolute path to tomcat 7 installation</home>
                </configuration>
            </configuration>
       </plugin>
    </plugins>
</build>

작성 시점의 최신 버전은 1.5.0 입니다 . 그러나 최신 버전은 항상 여기에서 찾을 수 있습니다 .

패키징을 WAR로 명시적으로 정의합니다. 이것이 없으면 빌드가 실패합니다. 플러그인 섹션에서 cargo maven2 플러그인을 추가할 것입니다. 또한 Maven에 Tomcat 컨테이너와 기존 설치를 사용하고 있음을 알리는 구성 섹션을 추가합니다.

컨테이너 유형을 installed 로 설정하여 머신에 인스턴스가 설치되어 있음을 Maven에 알리고 이 설치에 대한 절대 URL을 제공합니다.

구성 유형을 existing 으로 설정하면 사용 중인 기존 설정이 있고 추가 구성이 필요하지 않음을 Tomcat에 알립니다.

대안은 카고에게 URL을 제공하여 지정된 버전을 다운로드하고 설정하도록 지시하는 것입니다. 그러나 우리의 초점은 WAR 배치에 있습니다.

Maven 2.x를 사용하든 Maven 3.x를 사용하든 간에 cargo maven2 플러그인은 둘 다에 대해 작동한다는 점은 주목할 가치가 있습니다.

이제 다음을 실행하여 애플리케이션을 설치할 수 있습니다.

mvn install

그런 다음 배포합니다.

mvn cargo:deploy

모든 것이 순조롭게 진행된다면 http://localhost:8080/cargo-deploy를 로드하여 웹 애플리케이션을 실행할 수 있어야 합니다 .

5.3. 원격 배포

원격 배포를 수행하려면 pom.xml 의 구성 섹션만 변경하면 됩니다 . 원격 배포는 Tomcat의 로컬 설치가 없지만 원격 서버의 관리자 대시보드에 액세스할 수 있음을 의미합니다.

구성 섹션이 다음과 같이 보이도록 pom.xml을 변경해 보겠습니다 .

<configuration>
    <container>
        <containerId>tomcat8x</containerId>
        <type>remote</type>
    </container>
    <configuration>
        <type>runtime</type>
        <properties>
            <cargo.remote.username>admin</cargo.remote.username>
            <cargo.remote.password>admin</cargo.remote.password>
            <cargo.tomcat.manager.url>http://localhost:8080/manager/text
              </cargo.tomcat.manager.url>
        </properties>
    </configuration>
</configuration>

이번에는 컨테이너 유형을 설치됨 에서 원격 으로 변경 하고 구성 유형을 기존 에서 런타임 으로 변경합니다 . 마지막으로 구성에 인증 및 원격 URL 속성을 추가합니다.

이전과 마찬가지로 역할과 사용자가 이미 $CATALINA_HOME/conf/tomcat-users.xml 에 있는지 확인합니다.

원격 배포를 위해 동일한 프로젝트를 편집하는 경우 먼저 기존 WAR의 배포를 취소합니다.

mvn cargo:undeploy

그런 다음 프로젝트를 정리합니다.

mvn clean

다음으로 설치합니다.

mvn install

마지막으로 다음과 같이 배포합니다.

mvn cargo:deploy

그게 다야.

6. Eclipse에서 배포

Eclipse를 사용하면 IDE에서 벗어나 탐색하지 않고도 일반 워크플로에서 웹 프로젝트 배포를 추가하기 위해 서버를 내장할 수 있습니다.

6.1. Eclipse에 Tomcat 포함

Eclipse에 설치를 포함하려면 작업 표시줄에서 창 메뉴 항목을 선택한 다음 드롭다운에서 환경 설정을 선택합니다.

그러면 나타나는 창의 왼쪽 패널에 기본 설정 항목의 트리 그리드가 표시됩니다. 다음으로 eclipse -> 서버 로 이동하거나 검색 표시줄에 서버를 입력합니다 .

그런 다음 아직 열려 있지 않은 경우 설치 디렉토리를 선택하고 다운로드한 Tomcat 버전을 선택할 수 있습니다.

패널 오른쪽에 구성 페이지가 나타납니다. 여기에서 사용 옵션을 선택하여 이 서버 버전을 활성화하고 설치 폴더를 찾습니다.

변경 사항을 적용한 다음 다음에 Eclipse 창 -> 보기 하위 메뉴 표시에서 서버 보기를 열면 새로 구성된 서버가 나타나며 애플리케이션을 시작, 중지 및 배포할 수 있습니다.

6.2. Embedded Tomcat에 웹 애플리케이션 배포

Tomcat에 웹 애플리케이션을 배포하려면 작업 공간에 웹 애플리케이션이 있어야 합니다.

창 -> 보기 표시 에서 서버 보기를 열고 서버를 찾아봅시다. 열리면 구성한 서버를 마우스 오른쪽 버튼으로 클릭하고 나타나는 상황에 맞는 메뉴에서 배포 추가를 선택할 수 있습니다.

표시되는 새 배포 대화 상자 에서 프로젝트 드롭다운을 열고 웹 프로젝트를 선택합니다.

프로젝트 콤보 상자 아래에 배포 유형 섹션이 있습니다 . Exploded Archive(development mode) 를 선택 하면 응용 프로그램의 변경 사항이 다시 배포하지 않고도 실시간으로 동기화됩니다. 이것은 매우 효율적이기 때문에 개발 중에 가장 좋은 옵션입니다.

Packaged Archive(프로덕션 모드)를 선택하면 변경 사항을 적용하고 브라우저에서 확인할 때마다 다시 배포해야 합니다. 이것은 프로덕션에만 가장 적합하지만 여전히 Eclipse를 사용하면 똑같이 쉽게 만들 수 있습니다.

6.3. 외부 위치에 웹 애플리케이션 배포

우리는 일반적으로 디버깅을 더 쉽게 하기 위해 Eclipse를 통해 WAR을 배포하도록 선택합니다. 그러나 Eclipse의 임베디드 서버에서 사용하는 위치가 아닌 다른 위치에 배포해야 할 때가 올 수 있습니다. 가장 일반적인 인스턴스는 프로덕션 서버가 온라인 상태이고 웹 애플리케이션을 업데이트하려는 경우입니다.

프로덕션 모드에서 배포하고 새 배포 대화 상자 에서 배포 위치를 확인한 다음 거기에서 WAR을 선택하여 이 절차를 건너뛸 수 있습니다 .

배포하는 동안 내장형 서버를 선택하는 대신 내장형 서버 List 옆에 있는 서버 보기에서 <외부 실행> 옵션을 선택할 수 있습니다. 그런 다음 외부 Tomcat 설치의 webapps 디렉토리 로 이동합니다 .

7. IntelliJ IDEA에서 배포

웹 응용 프로그램을 Tomcat에 배포하려면 웹 응용 프로그램이 존재해야 하며 이미 다운로드 및 설치되어 있어야 합니다.

7.1. 로컬 구성

실행 메뉴를 열고 구성 편집 옵션을 클릭합니다 .

왼쪽 패널에서 Tomcat 서버를 검색합니다. 없는 경우 메뉴에서 + 기호를 클릭하고 Tomcat을 검색한 다음 Local 을 선택합니다 . 이름 필드에 Tomcat 7/8을 입력합니다 (버전에 따라 다름).

그런 다음 구성... 버튼을 클릭 하고 Tomcat 홈 필드에서 설치의 홈 위치로 이동하여 선택합니다.

선택적으로 시작 페이지를 http://localhost:8080/ 및 HTTP 포트: 8080 으로 설정할 수 있습니다 . 포트를 적절하게 변경합니다.

마지막으로 배포 탭 으로 이동하여 + 기호를 클릭하고 서버에 추가할 아티팩트를 선택한 다음 확인을 클릭합니다.

7.2. 원격 구성

로컬 Tomcat 구성과 동일한 지침을 따르지만 서버 탭에서 원격 설치 위치를 입력해야 합니다.

8. 아카이브를 복사하여 배포

Eclipse에서 WAR을 내보내는 방법을 배웠습니다. 우리가 할 수 있는 또 다른 일은 Tomcat 인스턴스의 $CATALINA_HOME\webapps 디렉토리 에 간단히 드롭하여 배포하는 것입니다 . 인스턴스가 실행 중인 경우 Tomcat이 아카이브의 압축을 풀고 해당 컨텍스트 경로를 구성하는 즉시 배포가 시작됩니다.

인스턴스가 실행 중이 아니면 서버는 다음에 시작할 때 프로젝트를 배포합니다.

9. Tomcat 관리자에서 배포

WAR 파일이 이미 있고 관리 대시보드를 사용하여 배포하려는 경우 http://localhost:8080/manager를 방문하여 관리자 대시보드에 액세스할 수 있습니다 .

대시보드에는 Manager , Applications , Deploy , Diagnostics 및 Server Information의 다섯 가지 섹션이 있습니다.

배포 섹션 으로 이동하면 두 개의 하위 섹션이 있습니다.

9.1. 서버에 있는 디렉터리 또는 WAR 파일 배포

WAR 파일이 Tomcat 인스턴스가 실행 중인 서버에 있는 경우 슬래시 "/" 앞에 오는 필수 컨텍스트 경로 필드를 채울 수 있습니다.

예를 들어 URL이 http://localhost:8080/myapp 인 브라우저에서 웹 애플리케이션에 액세스하려는 경우 컨텍스트 경로 필드에는 /myapp이 있습니다.

XML 구성 파일 URL 필드를 건너뛰고 WAR 또는 디렉터리 URL 필드 로 이동할 수도 있습니다 . 여기서는 서버에 표시되는 웹 아카이브 파일의 절대 URL을 입력합니다. 예를 들어 파일 위치가 C:/apps/myapp.war 인 경우 이 위치를 입력합니다. WAR 확장을 잊지 않는 것이 중요합니다.

그런 다음 배포 버튼을 클릭할 수 있습니다. 페이지가 다시 로드되고 페이지 상단에 다음 메시지가 표시됩니다.

OK - Deployed application at context path /myapp

애플리케이션은 페이지의 애플리케이션 섹션 에도 나타나야 합니다 .

9.2. 배포할 WAR 파일

여기에서는 파일 선택 버튼을 클릭 하고 WAR 파일의 위치로 이동하여 선택한 다음 배포 버튼을 클릭합니다.

두 경우 모두 모든 것이 순조롭게 진행되면 Tomcat 콘솔은 다음 메시지와 함께 배포가 성공했음을 알려줍니다.

INFO: Deployment of web application archive \path\to\deployed_war has finished in 4,833 ms

10. 결론

이 기사에서는 WAR을 Tomcat 서버에 배포하는 방법에 중점을 두었습니다.

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/tomcat-deploy-war

WAR과 EAR 파일의 차이점

기록만이살길 — Thu, 23 Mar 2023 21:35:12 +0900

1. 개요

이 사용방법(예제)에서는 Java JAR(Java ARchive), WAR(Web Application ARchive) 및 EAR(Enterprise Application aRchive) 아티팩트 파일 간의 차이점을 살펴보겠습니다.

각 파일 형식이 수행하는 작업과 이를 사용하는 방법에 대해 설명합니다.

2. 자바 아티팩트 파일 형식

Java 사양에는 여러 유형의 아티팩트 파일이 포함되어 있습니다. 가장 눈에 띄는 것은 JAR, WAR 및 EAR이지만 다른 것들도 있습니다. JAR로 시작하여 각 유형은 각각 다른 유형을 기반으로 빌드됩니다.

JAR 파일 형식은 JavaSE 사양의 일부이지만 WAR 및 EAR 파일 자체는 현재 JakartaEE로 알려진 JavaEE의 일부입니다.

3. JAR 파일

아시 다시피 JAR 파일은 Java 애플리케이션의 기본 아티팩트입니다 .

기본적으로 확장자는 .jar 인 .zip 파일 입니다 . 클래스, 리소스, 메타 정보 파일 등의 내용을 포함합니다.

jar 프로그램 으로 JAR 파일을 만들고 JRE(Java Runtime Environment)만 있는 모든 시스템에서 java -jar 명령을 사용하여 실행할 수 있습니다.

4. 전쟁 파일

WAR 파일은 Java 웹 애플리케이션 번들링 에 사용됩니다 .

또한 후드 아래의 .zip 파일이며 JAR 파일 형식의 확장입니다.

클래스 및 리소스와 함께 WAR 파일에는 라이브러리, JSP 파일 , Java 서블릿 및 모든 유형의 정적 웹 파일 (HTML, CSS, Javascript 등) 형식의 다른 JAR이 포함될 수 있습니다 .

JakartaEE는 올바른 형식의 WAR 파일이 web.xml 파일을 포함하는 WEB-INF 디렉토리를 포함해야 한다고 지정합니다 . 여기에서 각 서블릿의 웹 경로 또는 세션 시간 초과 양과 같은 웹 응용 프로그램의 구조 및 구성을 선언합니다.

JAR과 달리 WAR 파일은 독립 실행형 애플리케이션으로 실행할 수 없으며 서블릿 컨테이너 또는 애플리케이션 서버와 같은 다른 애플리케이션의 구성 요소로만 사용할 수 있습니다 .

WAR 파일을 서버에 넣는 과정을 애플리케이션 배포 라고 합니다 . 일반적인 애플리케이션 서버에는 Tomcat, Jetty 및 Wildfly가 포함됩니다.

5. 귀 파일

EAR 파일은 여러 모듈로 구성된 엔터프라이즈 애플리케이션에 사용됩니다.

여러 유형의 모듈이 있지만 가장 일반적인 것은 웹 모듈(기본적으로 WAR 파일)과 Enterprise Java Bean 클래스를 포함하는 JAR 파일의 특수 유형인 EJB 모듈 입니다.

WAR과 마찬가지로 EAR은 JAR 확장이며 루트 META-INF 디렉토리 아래에 application.xml 이라는 특수 XML 파일을 포함해야 합니다 . 이 파일에서는 엔터프라이즈 애플리케이션을 설명하고 해당 모듈을 나열합니다. 또한 전체 앱에 대한 Security 역할을 추가할 수 있습니다.

WAR과 마찬가지로 EAR 파일도 독립 실행형 애플리케이션으로 실행할 수 없습니다. 애플리케이션 서버에 배포해야 합니다.

그러나 이 경우 모든 유형이 호환되는 것은 아닙니다. Wildfly와 같은 JakartaEE 기술을 지원하는 서버를 사용해야 하지만 Jetty는 사용할 수 없습니다. Tomcat의 경우에도 호환되지 않지만 호환되는 TomEE라는 다른 버전이 있습니다.

EAR 형식의 장점은 복잡한 다중 구성 요소 응용 프로그램을 단일 파일에 지정할 수 있다는 것입니다. 또한 공통 리소스를 공유하여 중복을 방지할 수 있습니다. 마지막으로 단일 파일 형식은 배포 오류를 제거하므로 매우 유용합니다.

6. 결론

이 기사에서는 WAR과 EAR 파일의 차이점을 살펴보았습니다. 우리는 각 파일의 구조를 배웠고 일반적인 사용 사례에 대해 논의했습니다. 마지막으로 각 유형의 아티팩트를 사용하는 방법을 살펴보았습니다.

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/war-vs-ear-files

Mockito 2를 사용한 지연 검증

기록만이살길 — Thu, 23 Mar 2023 21:33:06 +0900

1. 소개

이 짧은 예제에서는 Mockito의 지연 검증을 살펴보겠습니다.

빠른 실패 대신 Mockito를 사용하면 테스트가 끝날 때 수집되고 보고된 모든 결과를 볼 수 있습니다.

2. 메이븐 의존성

Mockito 의존성을 추가하여 시작하겠습니다 .

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>2.21.0</version>
</dependency>

3. Lazy 검증

Mockito의 기본 동작은 첫 번째 실패에서 즉 열심히 중지하는 것입니다 . 이 접근 방식은 fail-fast 라고도 합니다 .

때로는 이전 실패에 관계없이 모든 검증을 실행하고 보고해야 할 수도 있습니다.

VerificationCollector 는 테스트 메서드의 모든 검증을 수집하는 JUnit 규칙입니다.

오류가 있는 경우 테스트가 끝날 때 실행되고 보고됩니다.

public class LazyVerificationTest {
 
    @Rule
    public VerificationCollector verificationCollector = MockitoJUnit.collector();

    // ...
}

간단한 테스트를 추가해 보겠습니다.

@Test
public void testLazyVerification() throws Exception {
    List mockList = mock(ArrayList.class);
    
    verify(mockList).add("one");
    verify(mockList).clear();
}

이 테스트가 실행되면 두 검증의 실패가 모두 보고됩니다 .

org.mockito.exceptions.base.MockitoAssertionError: There were multiple verification failures:
1. Wanted but not invoked:
arrayList.add("one");
-> at com.baeldung.mockito.java8.LazyVerificationTest.testLazyVerification(LazyVerificationTest.java:21)
Actually, there were zero interactions with this mock.

2. Wanted but not invoked:
arrayList.clear();
-> at com.baeldung.mockito.java8.LazyVerificationTest.testLazyVerification(LazyVerificationTest.java:22)
Actually, there were zero interactions with this mock.

VerificationCollector 규칙이 없으면 첫 번째 확인만 보고됩니다.

Wanted but not invoked:
arrayList.add("one");
-> at com.baeldung.mockito.java8.LazyVerificationTest.testLazyVerification(LazyVerificationTest.java:19)
Actually, there were zero interactions with this mock.

4. 결론

Mockito에서 지연 검증을 사용하는 방법을 간단히 살펴보았습니다.

또한 항상 그렇듯이 코드 샘플은 GitHub 에서 찾을 수 있습니다 .

참고

https://docs.spring.io/spring-framework/docs/current/reference/html
https://www.baeldung.com/mockito-lazy-verification