학습내용

JSP vs Mustache vs Thymeleaf
@RequestBody
Gradle 의존성 옵션
assertj의 assertThat이 junit의 assertThat보다 편리한 이유
ModelAndView 객체를 이용한 리다이렉트, 포워딩
@RequestParam, @ModelAttribute, @RequestBody
DB_CLOSE_ON_EXIT
JdbcTemplate를 사용하여 자동 생성 키를 얻기
AOP
HandlerInterceptor
nohup, &
배포 스크립트 만들기
@JsonInclude
InterceptorRegistry.addPathPattern 메소드
HttpSession invalidate, removeAttribute 차이
TIMESTAMP & DATETIME 자동 초기화 및 갱신
SLF4J Tmpleate 추가하기
Javascript Event Delegation
EC2 인스턴스에 MySQL 설치
DockerFile 작성

JSP vs Mustache vs Thymeleaf

Template Engine

지정된 템플릿 양식과 데이터가 합쳐져서 html 문자를 만들어주는 소프트웨어입니다.
프로그램 로직과 뷰 계층을 분리하기 위한 수단으로 사용됩니다.

서버 템플릿 엔진(SSR, Server Side Rendering)

서블릿(서버)에서 동작하는 템플릿입니다.
템플릿 양식과 데이터를 이용하여 동적인 html 파일을 생성하여 브라우저에 전달합니다.

클라이언트 템플릿 엔진(CSR, Client Side Rendering)

React, Vue, Anguler와 같이 서버에서 json 데이터를 전달받고 전달 받은 데이터를 기반으로 웹 페이지를 렌더링하는 라이브러리 혹은 프레임워크입니다.
SPA(Single Page Application) 환경으로 동작합니다.
자바스크립트는 브라우저 위에서 실행되어 브라우저에서 실행될 때는 서버 템플릿 엔진의 손을 벗어나 제어할 수 없습니다.

Mustache

JSP와 같이 html을 만들어주는 템플릿 엔진입니다.
로직 코드를 사용할 수 없기 때문에 View 역할과 서버의 역할을 명확히 분리하게 해줍니다.
Mustache.js와 Mustache.java 두가지가 존재하여 하나의 문법으로 클라이언트/서버 템플릿으로 모두 사용이 가능하게 합니다.

JSP vs Mustache

JSP는 Java 언어를 지원하고, Mustache는 Java는 물론, 대부분의 언어를 지원합니다.
JSP는 로직 구현이 가능하고, Mustache는 로직 구현이 불가능합니다. (View 역할에 충실합니다.)
JSP는 스프링부트에서 권장하지 않는 템플릿 엔진이고 Mustache는 스프링부트에서 공식으로 지원하는 템플릿 엔진입니다.

Mustache vs Thymeleaf

Thymeleaf는 Mustache에 비해서 문법이 어렵다는 단점이 존재합니다.
Thymeleaf는 Mustache에 비해서 좀더 복잡한 로직을 수행할 수 있습니다. 대신 View 역할에 집중하지 못할 수 있습니다.
Thymeleaf는 서버 사이드 템플릿 엔진을 수행할 수 밖에 없는데 비해 Mustache는 클라이언트/서버 템플릿 엔진으로 수행할 수 있습니다.

@RequestBody

HTTP 요청의 body에 담긴 데이터를 자바 객체로 변환해주는 역할을 수행합니다.

HTTP 요청의 Content-Type을 기반으로 자동으로 데이터 변환을 처리합니다. Content-Type이 application/json인 경우 JSON 데이터를 자바 객체로 변환합니다.

선택적으로 @Valid 애노테이션을 사용하면 HTTP 요청의 body에 담긴 데이터를 자바 객체로 변환한 후에, 해당 객체의 유효성을 검증할 수 있습니다.

Gradle 의존성 옵션

Gradle

그래들(Gradle)은 그루비(Groovy)를 기반으로 한 빌드 도구입니다.
- 그루비(Groovy) : 객체지향 프로그래밍 언어로 자바 플랫폼 상에서 동작하는 언어
And와 Maven같은 이전 세대 빌드 도구의 단점을 보완하고 장점을 취합하여 만든 오픈소스로 공개된 빌드 도구
- And 단점
  - XML 기반 설정 방식으로 복잡한 빌드 로직을 구현하기 어렵습니다.
  - 의존성 관리가 어렵고, 라이브러리들을 수동으로 다운로드하여 라이브러리 경로를 추가해주어야 합니다.
  - 유연성이 떨어지며, 프로젝트 규모가 크고 복잡해질수록 유지보수가 어렵습니다.
- Maven 단점
  - 빌드 시간이 오래 걸리는 경우가 있습니다.
  - 다른 빌드 도구에 비해 복잡한 설정 방식을 사용합니다.
  - 의존성 해결과 라이브러리 관리에 대한 이해가 필요합니다.
- Gradle 장점
  - 선언적 문법 : 빌드 스크립트를 선언적인 방식으로 작성할 수 있습니다.
  - 멀티 프로젝트 지원 : 여러 프로젝트를 한번에 빌드할 수 있습니다. 이를 통해 프로젝트간 의존성 관리를 쉽게 할 수 있습니다.
  - 빌드 캐시 : Gradle은 빌드 결과를 캐시하여 빌드 시간을 줄일 수 있습니다.
  - 다양한 플러그인 지원 : 플러그인을 통해 빌드 스크립트를 간단하게 작성할 수 있습니다.
  - 스크립트 언어 : Gradle은 Groovy, Kotlin 등의 스크립트 언어를 지원하여 빌드 스크립트를 간결하게 작성할 수 있습니다.
  - 유연성 : 사용자의 요구에 맞게 빌드 시스템을 구성할 수 있습니다.

선언적 문법 예시

dependencies {
    implementation 'com.google.guava:guava:30.1.1-jre'
    testImplementation 'junit:junit:4.13.2'
}

멀티 프로젝트 지원 예시

root-project/
   build.gradle
   settings.gradle
   sub-project1/
       build.gradle
       src/
   sub-project2/
       build.gradle
       src/

settings.gradle 파일에 각 하위 프로젝트 정의
include 'sub-project1'
include 'sub-project2'

compile vs implementation

위 그림을 보면 모듈 B, C가 모듈 A에 의존하고 있는 그림입니다.

compile을 사용하는 경우

A 모듈을 수정하게 되면 A 모듈을 의존하는 모듈 B, C도 같이 리빌드(rebuild)됩니다.
간접적으로 의존하는 모듈까지 다시 빌드하게 되므로 시간이 오래 걸리게 됩니다.

implementation을 사용하는 경우

A 모듈을 수정하게 되면 A 모듈을 직접적으로 의존하는 모듈까지만 리빌드됩니다.
직접적으로 의존하는 모듈까지만 빌드하게 되므로 시간이 상대적으로 적게 걸립니다.
사용자에게 필요 이상의 API를 노출하는 것은 불필요하므로 API의 노출을 막을 수 있습니다.

의존성 옵션들

implementation : 의존 라이브러리 수정시 본 모듈까지만 재빌드합니다.
- 본 모듈을 의존하는 모듈은 해당 라이브러리의 api를 사용할 수 없습니다.
- 본 모듈의 라이브러리가 api를 외부에 공개하지 않았거나 외부에서 api를 사용할 수 없는 제한이 있다는 의미입니다.
- 예를 들어 A 모듈을 의존하는 B 모듈이 있고 B 모듈을 의존하는 C 모듈이 존재할때 A 모듈 수정시 B 모듈까지만 재빌드합니다. C 모듈은 A 모듈의 api를 사용할 수 없습니다.
api : 의존 라이브러리 수정시 본 모듈을 의존하는 모듈들도 재빌드합니다.
- 본 모듈을 의존하는 모듈들도 해당 라이브러리의 api를 사용할 수 있습니다.
- 예를 들어 A <- B <- C와 같이 A 모듈을 B,C 모듈이 의존한다고 가정할때 C 모듈이 A 모듈의 api를 사용할 수 있습니다.
compileOnly : compile 시에만 빌드하고 빌드 결과물에는 포함되지 않습니다. runtime 시 필요없는 라이브러리인 경우 사용하는 의존성 옵션입니다.
runtimeOnly : runtime 시에만 필요한 라이브러리인 경우 설정하는 옵션입니다.
annotationProcessor : 자바 컴파일러가 컴파일 시점에 애노테이션을 처맇라 때 사용되는 라이브러리나 모듈입니다.
- 애노테이션을 사용하여 컴파일 시점에 코드를 생성하거나, 검증 등의 작업을 할 수 있습니다.
- ex) lombok
testImplementation : 테스트할때만 사용하는 의존성 라이브러리 옵션입니다.
- ex) junit, mockito

assertj의 assertThat이 junit의 assertThat보다 편리한 이유

junit의 assertThat 사용시 불편한 점은 다음과 같습니다.

자동완성
- allOf, greaterThan, lessThan, is 등의 메소드들을 미리 import 해놓지 않으면 IDE에서 자동완성을 해주지 못하기 때문에 필요한 메소드들을 공식문서에서 찾거나, 이름을 외워서 작성해야 합니다.
- 즉, IDE에서 자동완성을 해주지 못하기 때문입니다.
Assertion 분류(matcher)
- 원하는 matcher를 찾기가 불편합니다.
확장성
- 추가된 조건을 검증하기 위해서는 allOf와 같은 메소드로 기존 조건과 묶어주어야 합니다.

    @Test
    public void number_test() throws Exception {

        int number = 3;

        int result = mathService.add(number, 3)

        assertThat(result, allOf(
            greaterThan(0),
            lessThan(10)
        ));
    }

assertj의 assertThat 장점은 다음과 같습니다.

자동완성
- assertThat에서 반환되는 Assert 클래스를 사용하기 때문에 메소드 자동완성이 지원되어 편리합니다.
Assertion 분류
- assertThat에서 인자의 타입에 맞는 Assert 클래스를 반환하기 때문에 필요한 메소드만 분류되어 있습니다.
확장성
- 체이닝 메소드 패턴으로 작성 가능하기 때문에, 조건 추가를 위해 추가 작업이 필요가 없어서 가독성이 좋습니다.

    @Test
    public void number_test() throws Exception {

        int number = 3;

        int result = mathService.add(number, 3)

        assertThat(result)
                .isGreaterThan(0)
                .isLessThan(10);

    }

ModelAndView 객체를 이용한 리다이렉트, 포워딩

@RequestMapping("/login")
public ModelAndView login(@RequestParam("username") String username, 
                           @RequestParam("password") String password) {
    if (isValidUser(username, password)) {
        return new ModelAndView("redirect:/home"); // 리다이렉트
    } else {
        ModelAndView modelAndView = new ModelAndView("login"); // 포워딩
        modelAndView.addObject("error", "Invalid credentials");
        return modelAndView;
    }
}

리다이렉트와 포워딩 비교

리다이렉트

서버는 클라이언트에게 다른 URL로 이동하도록 요청을 보내고, 클라이언트는 새로운 URL로 GET 요청을 보내 페이지를 받아옵니다.
리다이렉트 과정에서 클라이언트와 서버간에 새로운 HTTP 요청이 발생 하므로, URL이 변경됩니다.
주로 로그인, 로그아웃, 회원가입 등에서 사용됩니다.

포워딩

서버에서는 클라이언트에게 다른 페이지로 이동할 필요가 없게 합니다. 대신, 현재 요청된 페이지를 처리하기 위해 다른 페이지로 제어를 넘깁니다.
클라이언트는 이전 URL을 유지한 상태로 새로운 페이지를 받아오기 때문에 URL이 변경되지 않습니다.
포워딩 과정에서 추가적인 HTTP 요청이 발생하지 않으므로 , 보낼 데이터의 양이 많은 경우에도 URL이 길어지지 않습니다.

@RequestParam, @ModelAttribute, @RequestBody

@RequestParam

HTTP 요청 파라미터를 메소드의 인자로 받아오는 방법중 하나입니다.
요청 파라미터의 이름과 매핑될 수 있는 메소드의 매개변수를 지정할 수 있습니다.

@RequestMapping("/hello")
public String sayHello(@RequestParam("name") String name) {
    return "Hello, " + name + "!";
}

위 예시에서 @RequestParam("name")은 "name" 파라미터의 값을 받아서 String name 변수에 저장합니다. 즉, "/hello?name=김용환" 요청이 들어오면 name 변수에는 "김용환"이 저장됩니다.

@RequestParam 수행과정을 코드로 표현하면 다음과 같습니다.

@RequestMapping("/hello")
public String sayHello(HttpServletRequest request) {
    String name = request.getParameter("name");
    return "Hello, " + name + "!";
}

@ModelAttribute

@ModelAttribute는 사용자가 요청시 전달하는 값을 객체 형태로 매핑해주는 애노테이션입니다.
매핑받는 객체는 setter 메소드가 있어야합니다.

    @PostMapping("/users")
    public String create(@ModelAttribute User user) {
        logger.info(user.toString());
        return "index";
    }

위와 같은 코드가 있으면 Spring 내부적으로 다음과 같은 코드를 수행합니다. request는 HttpServletRequest 타입의 객체입니다.

User user = new User();
user.setName(request.getParameter("name"));
user.setAge(Integer.parseInt(request.getParameter("age")));
user.setEmail(request.getParameter("email"));
model.addAttribute("user", user);

@RequestBody

HTTP 요청 바디의 데이터를 자바 객체로 변환해줍니다.
요청 바디에 JSON, XML, TEXT 등의 데이터를 자바 객체로 변환하여 컨트롤러 메소드의 파라미터로 전달할 수 있습니다.

{
    "name": "John",
    "age": 25,
    "email": "john@example.com"
}

@RequestMapping(value = "/user", method = RequestMethod.POST)
public ResponseEntity<String> createUser(@RequestBody User user) {
    // ...
}

DB_CLOSE_ON_EXIT

h2 데이터베이스 설정 옵션 중 하나입니다.
이 옵션을 사용하면 DB 연결 종료시 데이터베이스가 자동으로 종료되지 않고 유지됩니다.
DB_CLOSE_ON_EXIT-FALSE를 설정하면 애플리케이션 종료시 데이터베이스가 자동으로 삭제되지 않고 유지됩니다. 따라서 애플리케이션을 다시 실행하면 이전에 생성된 데이터베이스를 사용할 수 있습니다.

JdbcTemplate를 사용하여 자동 생성 키를 얻기

String INSERT_MESSAGE_SQL 
  = "insert into sys_message (message) values(?) ";
    
public long insertMessage(String message) {    
    KeyHolder keyHolder = new GeneratedKeyHolder();

    jdbcTemplate.update(connection -> {
        PreparedStatement ps = connection
          .prepareStatement(INSERT_MESSAGE_SQL);
          ps.setString(1, message);
          return ps;
        }, keyHolder);

        return (long) keyHolder.getKey();
    }
}

AOP

AOP와 OOP의 관계

OOP 사용하는 이유는 비즈니스 로직의 중복을 제거하기 위함입니다.
AOP를 사용하는 이유는 인프라 로직의 중복을 제거하기 위함입니다.

비즈니스 로직이란?

실세계의 데이터를 생성,표시,저장,변경하는 부분을 의미합니다.
데이터의 상태 값을 조작하는 로직
예를 들어 회원의 생성, 정보 변경, 삭제 등이 있습니다.

인프라 로직이란?

핵심적인 비즈니스 로직은 건들이지 않으면서 성능을 높이고, 보안을 강화하기 위해 처리하는 로직
권한 검사, 트랜잭션, 데이터 캐싱, 로깅, 성능 측정 등이 인프라 로직이 될 수 있습니다.

인프라 로직 특징

인프라 로직은 프로그래밍 모든 영역에 걸쳐 등장합니다.
많은 중복 코드를 양산합니다.
코드 가독성을 떨어뜨리고, 유지보수를 어렵게 합니다.

AOP를 사용하는 이유

인프라 로직의 중복을 제거하여 비즈니스 로직에 집중할 수 있도록 합니다.
AOP와 OOP는 적대관계가 아닌 상호 보완관계입니다.

Servlet Filter와 Intercepter

위 그림과 같이 DispatcherServlet 이전, 이후에는 CharacterEncodingFiler, ResourceFileter가 작동하는데 이 부분이 AOP 기능을 수행하고 있는 것입니다.

AOP 관련 용어들

target : 비즈니스 로직 수행 대상
advice : 비즈니스 로직을 수행하는 target에게 제공하는 부가 기능을 수행하는 클래스 (인프라 로직)
pointcut : 인프라 로직이 적용될 대상을 지정하는 것
joinpoint : 인프라 로직이 적용될 위치, 예를 들어 메소드의 실행 단계 등이 있습니다.

AOP 실습

// Aop는 빈으로 등록되어야함
@Aspect
@Component
public class TimeTraceAop {

    // 패키지명..클래스명(타입)
    // ex) "execution(* hello.hellospring.service..*(..)) 서비스 하위 패키지에만 시간 추적 aop 적용
    @Around("execution(* hello.hellospring..*(..))") // 공통 관심사항을 어디에 적용할 것인지 선택
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        System.out.printf("START: %s%n", joinPoint);
        try {
            return joinPoint.proceed();
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.printf("END: %s %dms%n", joinPoint, timeMs);
        }
    }

}

Spring Interceptor

Spring 프레임워크에서 제공하는 기능 중 하나로, 클라이언트의 HTTP 요청을 처리하기 전/후에 수행되는 기능을 구현할 수 있게 해주는 기능입니다.
Interceptor는 클라이언트 요청이 처리되기 전에 해당 요청의 정보를 가로채어 전처리 작업을 할 수 있고, 요청 처리 이후에는 응답 정보를 가로채어 후처리 작업을 할 수 있습니다.
예를 들어 로그인을 해야하는 페이지에서 Interceptor를 사용하면 로그인 페이지에 입장하면 세션을 검증하고, 세션이 유효하지 않으면 로그인 페이지로 이동시키는 작업을 수행할 수 있습니다.

Spring Interceptor 구현방법

HandlerInterceptor 인터페이스 구현

public interface HandlerInterceptor {
    // Controller 메소드 실행 전
    boolean preHandle(HttpServletRequest request,
        HttpServletResponse response, Object handler)
            throws Exception;

    // Controller 메소드 실행 후
    void postHandle(
            HttpServletRequest request, 
            HttpServletResponse response, 
            Object handler, ModelAndView modelAndView)
            throws Exception;

    // 클라이언트에 응답을 보낸 후
    void afterCompletion(
            HttpServletRequest request, 
            HttpServletResponse response, 
            Object handler, Exception ex)
            throws Exception;

}

ServletFilter와 Interceptor의 한계

ServletFilter는 Servlet 실행 전/후에 대한 처리, Interceptor는 메소드 실행 전/후에 대한 처리만 가능합니다.
애플리케이션 전체 소스 코드에 대해 Aspect를 적용하고 싶다면 Spring AOP를 사용할 수 있습니다.

Interceptor 실습

HandlerInterceptor 인터페이스 구현체 정의

public class PerformanceInterceptor implements HandlerInterceptor {

    private static final Logger logger = LoggerFactory.getLogger(PerformanceInterceptor.class);
    private static final String START_TIME = "START_TIME";

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
        Object handler) throws Exception {
        request.setAttribute(START_TIME, System.currentTimeMillis());
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
        ModelAndView modelAndView) throws Exception {
        long startTime = (long) request.getAttribute(START_TIME);
        logger.info("execution time : {}", System.currentTimeMillis() - startTime);
    }
}

설정 파일 클래스를 만들고 WebMvcConfigurer 인터페이스를 구현합니다. 그중에서 addInterceptors 메소드를 재정의합니다. 또한 performanceInterceptor 빈도 생성합니다.

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = {"hello"})
public class SpringConfig implements WebMvcConfigurer {

    @Bean
    public PerformanceInterceptor performanceInterceptor() {
        return new PerformanceInterceptor();
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(performanceInterceptor())
            .addPathPatterns("/**")
            .excludePathPatterns("/members/**");
    }
}

@EnableWebMvc : WebMvcConfigurationSupport로부터 스프링 MVC 설정을 가져옵니다. 가져온 설정 정보는 @Configuration이 사용합니다.

애플리케이션을 실행하고 "http://localhost:8080/hello"를 호출하여 로깅이 뜨는지 확인합니다.

nohup, &

nohup이란 무엇인가

리눅스, 유닉스에서 쉘 스크립트파일(*.sh)을 데몬형태로 실행시키는 프로그램
터미널 세션이 끊겨도 실행을 멈추지 않고 동작합니다.

&이란 무엇인가

프로세스를 실행 시 백그라운드에서 동작하도록 하는 명령어

nohub으로 쉘 스크립트 파일 실행시 주의사항

nohup으로 실행할 쉘 스크립트 파일(*.sh)은 현재 권한이 755 이상 상태여야 합니다.

chmod 755 shell.sh

실행방법

$ nohup shell.sh &

종료방법

$ ps -ef | grep 쉽스크립트파일명
$ kill -9 PID번호

nohup과 & 차이

$ ./run &
$ nohup ./run &

nohup 실행 : hang-up signal이 와도 동작하기 때문에 터미널 연결이 끊겨도 실행을 계속 수행합니다.
& 실행 : 백그라운드로만 돌린다는 의미이며, 터미널 연결이 끊기면 실행도 끊어집니다.

배포 스크립트 만들기

배포과정은 무엇인가

배포는 다음의 과정을 모두 포괄하는 것을 의미합니다.

git clone 혹은 git pull을 통해 새 버전의 프로젝트를 받음
Gradle이나 Maven을 통해 프로젝트 테스트와 빌드
EC2 서버에서 해당 프로젝트 실행 및 재실행

배포 스크립트 필요한 이유

배포 과정을 수행하기 위해 위에 3개의 과정을 실행하기 위해 여러 단계의 명령어들을 실행하는 것은 불편함이 많습니다. 따라서 쉘 스크립트로 작성해서 스크립트에 작성된 명령어들을 차례대로 진행되도록 합니다.

EC2 인스턴스에서 프로젝트 가져오기

/home/ec2-user $ mkdir app
/home/ec2-user $ cd app
/home/ec2-user/app $ git clone -b step3 https://github.com/yonghwankim-dev/be-java-cafe-max.git
/home/ec2-user/app $ cd be-java-cafe-max
/home/ec2-user/app/be-java-cafe-max $

배포 스크립트 작성

배포 스크립트를 작성할 파일 생성

/home/ec2-user/app/be-java-cafe-max $ vi deploy.sh

deploy.sh 파일에 다음과 같이 배포 스크립트를 작성합니다.

#!/bin/bash

#1
REPOSITORY=/home/ec2-user/app
PROJECT_NAME=be-java-cafe-max

#2
cd $REPOSITORY/$PROJECT_NAME/

#3
echo "> Git Pull"

git pull

echo "> 프로젝트 Build 시작"

#4
./gradlew build

echo "$REPOSITORY 디록토리로 이동"

cd $REPOSITORY

echo "> Build 파일 복사"

#5
cp $REPOSITORY/$PROJECT_NAME/build/libs/*.jar $REPOSITORY/

echo "> 현재 구동중인 애플리케이션 pid 확인"

#6
CURRENT_PID=$(pgrep -f ${PROJECT_NAME}.*.jar)

echo "현재 구동 중인 애플리케이션 pid: $CURRENT_PID"

#7
if [ -z "$CURRENT_PID" ]; then
  echo "> 현재 구동 중인 애플리케이션이 없으므로 종료하지 않습니다."
else
  echo "> kill -15 $CURRENT_PID"
  kill -15 $CURRENT_PID
  sleep 5
fi

echo "> 새 애플리케이션 배포"

#8
JAR_NAME=$(ls -tr $REPOSITORY/ | grep jar | tail -n 1)

echo "> JAR name: $JAR_NAME"

#9
nohup java -jar $REPOSITORY/$JAR_NAME 2>&1 &

#1 : 프로젝트 저장 위치(REPOSITORY) 및 프로젝트 이름(PROJECT_NAME)을 저장합니다.
#2 : 프로젝트 디렉토리로 이동합니다.
#3 : 원격 저장소로부터 pull 받습니다.
#4 : 프로젝트를 빌드합니다.
#5 : jar파일을 REPOSITORY 변수에 해당하는 위치에 복사합니다.
#6 : 현재 구동중인 애플리케이션 pid를 출력합니다.
#7 : 조건문에서 애플리케이션의 프로세스 ID가 비어있는지(-z) 확인합니다. 비어있지 않으면 프로세스를 제거합니다. 제거하는 이유는 애플리케이션 실행전에 실행된 애플리케이션이 있다면 종료하기 위해서입니다.
#8 : JAR 파일의 이름을 저장합니다.
#9 : 애플리케이션을 백그라운드로 실행하고 터미널 세션 연결이 끊겨도 계속 실행됩니다. 에러 출력도 표준 출력으로 리다이렉션합니다. 스프링 부트는 내장 톰캣을 갖고 있어서 바로 서버를 실행할 수 있습니다.
ls -tr
- '-t' : 파일 및 디렉토리를 수정 시간(최근 수정 시간) 순선대로 정렬합니다.
- '-r' : 역순으로 정렬합니다.
- 파일들을 가장 최근에 수정된 파일 및 디렉토리가 마지막에 출력됩니다.
tail : 파일의 끝 부분을 출력하는데 사용됩니다.
- '-n 1' : 파일의 끝에서부터 1줄을 출력합니다.

배포 스크립트 권한 추가

/home/ec2-user/app/be-java-cafe-max $ chmod +x ./deploy.sh

배포 스크립트 실행

/home/ec2-user/app/be-java-cafe-max $ ./deploy.sh

@JsonInclude

@JsonInclude 애노테이션은 Jackson 라이브러리에서 제공하는 어노테이션 중 하나로, JSON 직렬화시 제외할 항목을 지정하는 기능을 제공합니다.

기본적으로 jackson은 객체를 JSON으로 변환시 해당 객체의 모든 필드를 JSON으로 변환합니다. 하지만 필드의 값이 null인 경우 기본적으로 해당 필드를 JSON으로 변환하지 않습니다. 이러한 동작은 객체의 크기를 줄이고 JSON 응답 데이터양을 최적화하는데 도움이 됩니다.

하지만 null이 아닌 다른 특정 값(ex, 빈 문자열, 빈 배열)도 JSON으로 변환하지 않아야 할 경우가 있습니다. 이때 @JsonInclude 애노테이션을 사용하여 해당 필드의 값을 JSON으로 변환할지 여부를 지정할 수 있습니다.

@JsonInclude 애노테이션에서 value 속성을 통하여 값의 범위를 지정할 수 있습니다.

@JsonInclude value 속성

ALWAYS : 항상 포함합니다.
NON_NULL : null이 아닌 경우에 포함합니다.
NON_EMPTY : null이 아니고 빈 문자열이나 빈 컬렉션도 아닌 경우 포함합니다.
NON_DEFAULT : 기본값과 다른 경우 포함합니다.

    @JsonInclude(JsonInclude.Include.NON_EMPTY)
    private String email;

InterceptorRegistry.addPathPattern

InterceptorRegistry.addPathPattern 메소드의 파라미터로 인터셉터가 적용될 경로 패턴을 문자열로 타입으로 전달할 수 있습니다.

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LoginInterceptor())
            .order(Ordered.HIGHEST_PRECEDENCE)
            .addPathPatterns("/test1")
            .addPathPatterns("/test1/*")
            .addPathPatterns("/test1/**")
            .excludePathPatterns("/test2/**");
    }

"/test1" : url 경로가 "/test1"인 경우에만 인터셉터를 적용합니다.
"/test1/*" : url 경로가 "/test1/a", "/test1/b"와 같이 "/test1" 다음에 오는 모든 문자열을 포함하는 경로에 인터셉터를 적용합니다.
"/test1/**" : url 경로가 "/test1/a", "/test1/a/a"와 같이 "/test1" 다음에 오는 모든 문자열과 모든 하위 경로를 포함하는 경로에 인터셉터를 적용합니다.
excludePathPatterns : addPathPatterns와 반대로 인터셉터를 제외할 경로를 설정합니다.

HttpSession invalidate, removeAttribute 차이

invalidate 메소드 : 세션의 모든 속성 값을 제거하고 세션 자체를 무효화합니다. 따라서 세션이 종료되고 세션 ID가 더이상 유효하지 않게 됩니다.
removeAttribute 메소드 : HttpSession 객체에서 지정된 속성을 제거합니다. 이 메소드를 호출하면 세션 객체는 여전히 유효합니다. 다른 속성은 여전히 세션 객체에 유지되며, 세션 ID도 유효합니다.

HTTP 상태 401(Unauthorized) vs 403(Forbidden)

HTTP 상태 401(Unauthorized)

클라이언트가 인증되지 않았거나, 유효한 인증 정보가 부족하여 요청이 거부되었음을 의미하는 상태값입니다. 즉, 클라이어느가 인증되지 않았기 때문에 요청을 정상적으로 처리할 수 없다고 아려주는 것입니다.

401(Unauthorized) 응답을 받는 대표적인 경우는 로그인이 되어 있지 않은 상태에서 무언가 요청을 하는 경우가 있습니다. 예를 들어 어떤 쇼핑몰 사이트에 로그인을 하지 않았는데 나의 결제 내역과 같은 정보를 달라고 하면 401(Unauthorized)를 반환받게 될 것입니다.

HTTP 상태 403(Forbidden)

서버가 해당 요청을 이해했지만, 권한이 없어 요청이 거부되었음을 의미하는 상태값입니다. 즉, 클라이언트가 해당 요청에 대한 권한이 없다고 알려주는 경우입니다. 403(Forbidden) 응답을 받는 대표적인 경우는 로그인하여 인증되었지만 접근 권한이 없는 무언가를 요청하는 경우입니다. 예를 들어 어떤 쇼핑몰에 접속하여 로그인까지 하였지만, 다른 사용자의 결제 내역을 달라고 하면 403(Forbidden)을 반환받게 될 것입니다.

401(Unauthorized)과 403(Forbidden) 차이 정리

401(Unauthorized)
- 상태 : 클라이언트가 인증되지 않았거나, 유효한 인증 정보가 부족하여 요청이 거부된 상태
- 예시 : 사용자가 로그인되지 않은 경우
403(Forbidden)
- 상태 : 서버가 해당 요청을 이해했지만, 권한이 없어 요청이 거부된 상태
- 예시 : 사용자가 권한이 없는 요청을 하는 경우

TIMESTAMP & DATETIME 자동 초기화 및 갱신

CREATE TABLE t1 (
  ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  dt DATETIME DEFAULT CURRENT_TIMESTAMP
);

위와 같이 DEFAULT CURRENT_TIMESTAMP 설정시 테이블에 데이터를 추가할시 자동으로 생성 시간을 초기화 해줍니다.

CREATE TABLE t1 (
  ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  dt DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

ON UPDATE CURRENT_TIMESTAMP 설정시 데이터가 갱신시 갱신 시간을 자동으로 초기화해줍니다.

CREATE TABLE t1 (
  ts1 TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,     -- default 0
  ts2 TIMESTAMP NULL ON UPDATE CURRENT_TIMESTAMP -- default NULL
);

위와 같이 DEFAULT 생략시 0으로 초기화되고 NULL 설정시 기본값이 NULL로 초기화됩니다.

CREATE TABLE t1 (
  ts TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP,
  dt DATETIME DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP
);

위와 같이 DEFAULT 키워드를 사용하여 데이터 생성시 0으로 초기화 할 수 있습니다. ON UPDATE CURRENT_TIMESTAMP는 선택적 옵션입니다.

SLF4J Tmpleate 추가하기

Preferences -> Editor -> Live Templates -> Java -> 라이브 템플릿 추가

다음과 같이 SLF4J 템플릿을 입력합니다.

private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger($CLASS_NAME$.class);

변수 편집 -> 표현식 -> className() 선택

하단에 정의 -> Java -> 선언 체크박스 선택

실행 확인

Javascript Event Delegation

이벤트 위임(Event Delegation)은 하나의 부모 엘리먼트에 대해서 이벤트를 처리하는 방식입니다.
이벤트 위임을 사용하면 자식 엘리먼트에 대한 이벤트 리스너를 개별적으로 추가할 필요 없이, 부모 엘리먼트에 이벤트 리스너를 추가하여 자식 엘리먼트에서 발생하는 이벤트를 처리할 수 있습니다.
예를 들어, 부모 엘리먼트에 클릭 이벤트 리스너를 추가하고 자식 엘리먼트가 클릭 이벤트를 발생시키면, 부모 엘리먼트에서 클릭 이벤트를 처리할 수 있습니다.
이벤트 위임 장점
- DOM 구조가 변경되어도 이벤트 리스너를 다시 연결할 필요가 없으므로 유지 보수 및 성능 개선에 도움이 됩니다.
- 동적 생성되는 엘리먼트에 이벤트 처리에 유용합니다.

$(".qna-comment-slipp-articles").on("click", ".delete-answer-form button[type=submit]", deleteAnswer);

클래스 이름이 qna-comment-slipp-articles 엘리먼트 자식중 클래스 이름이 delete-answer-formbutton[type=submit]에 해당하는 엘리먼트가 클릭시 deleteAnswer 함수를 실행합니다.

EC2 인스턴스에 MySQL 설치

yum 저장소에 MySQL을 로컬설치하여 추가합니다.

$ sudo yum localinstall https://dev.mysql.com/get/mysql80-community-release-el9-1.noarch.rpm

MySQL 설치

$ sudo yum install mysql-community-server

MySQL 실행

$ sudo systemctl start mysqld

MySQL 상태 확인

$ sudo systemctl status mysqld

MySQL CharacterSet 설정

$ sudo vim /etc/my.cnf
...
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
skip-character-set-client-handshake
...

root 패드워드 확인

$ sudo grep 'temporary password' /var/log/mysqld.log

MySQL 루트 계정 접속

$ mysql -u root -p

root 계정 패스워드 변경

mysql > alter user 'root'@'localhost' identified with mysql_native_password by '{새비밀번호}';

EC2 인스턴스의 보안 그룹으로 이동하여 TCP 3306 포트를 위치무관으로 설정합니다.
유저 생성

mysql > CREATE USER 'yonghwan'@'%' IDENTIFIED BY 'YonghwanPassword8965@';

데이터베이스 생성 및 접속

mysql > CREATE DATABASE be_java_cafe_max;
mysql > use be_java_cafe_max;

mysql 데이터베이스 접속

mysql > use mysql;

루트 계정 생성 및 권한 부여

mysql > CREATE USER 'root'@'%' IDENTIFIED BY 'RootYonghwanPassword8965@';
mysql > GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;

유저 계정에게 권한 부여

msqyl > GRANT ALL PRIVILEGES ON be_java_cafe_max.* TO 'yonghwan'@'%' WITH GRANT OPTION;

변경 내용 적용

mysql > FLUSH PRIVILEGES;

MySQL에 bind address 추가

$ sudo vim /etc/my.cnf
...
bind-address=0.0.0.0
...

DockerFile 작성

DockerFile 개념

DockerImage를 생성하기 위한 스크립트(설정파일)
Docker는 DockerFile에 있는 명령어들을 차례대로 수행하여 DockerImage를 생성합니다.

DockerFile 장점

이미지가 어떻게 만들어졌는지를 기록합니다.
배포에 용이합니다.
컨테이너가 특정 행동을 수행하도록 합니다.

DockerFile 작성 및 명령어

DockerFile의 실제 파일 이름은 "DockerFile"이어야 합니다.
ubuntu에 apache 서버를 설치하는 DockerFile 작성을 실습합니다.
DockerFile을 담을 디렉토리를 생성후 DockerFile을 생성합니다.

$ mkdir ./apache-dockerfile && cd ./apache-dockerfile
$ vim DockerFile

DockerFile의 내용은 다음과 같습니다.

# server image는 ubuntu 18.04를 사용
FROM ubuntu:18.04

# Dockerfile 작성자
MAINTAINER YongHwanKim <yh.kim951107@gmail.com>

# image가 올라갔을 때 수행되는 명령어들
# -y 옵션을 넣어서 무조건 설치가 가능하도록 합니다.
RUN \
        apt-get update && \
        apt-get install -y apache2

# apache가 기본적으로 80포트를 사용하기 때문에 expost를 이용해 apache server로 접근합니다.
EXPOSE 80

# 컨테이너가 생성 된 이후에 내부의 아파치 서버는 항상 실행중인 상태로 만듭니다.
# apachectl을 foreground(즉, deamon) 상태로 돌아가도록 합니다.
CMD ["apachectl", "-D", "FOREGROUND"]

FROM : 베이스 이미지
- 어느 이미지에서 시작할건지를 의미한다.
MAINTAINER : 이미지를 생성한 개발자의 정보 (1.13.0 이후 사용 X)
LABEL : 이미지에 메타데이터를 추가 (key-value 형태)
RUN : 새로운 레이어에서 명령어를 실행하고, 새로운 이미지를 생성한다.
- RUN 명령을 실행할 때 마다 레이어가 생성되고 캐시된다.
- 따라서 RUN 명령을 따로 실행하면 apt-get update는 다시 실행되지 않아서 최신 패키지를 설치할 수 없다.
- 위 처럼 RUN 명령 하나에 apt-get update와 install을 함께 실행 해주자.
WORKDIR : 작업 디렉토리를 지정한다. 해당 디렉토리가 없으면 새로 생성한다.
- 작업 디렉토리를 지정하면 그 이후 명령어는 해당 디렉토리를 기준으로 동작한다.
- cd 명령어와 동일하다.
EXPOSE : Dockerfile의 빌드로 생성된 이미지에서 열어줄 포트를 의미한다.
- 호스트 머신과 컨테이너의 포트 매핑시에 사용된다.
- 컨테이너 생성 시 -p 옵션의 컨테이너 포트 값으로 EXPOSE 값을 적어야한다.
USER : 이미지를 어떤 계정에서 실행 하는지 지정
- 기본적으로 root에서 해준다.
COPY / ADD : build 명령 중간에 호스트의 파일 또는 폴더를 이미지에 가져오는 것
- ADD 명령문은 좀 더 파워풀한 COPY 명령문이라고 생각할 수 있다.
- ADD 명령문은 일반 파일 뿐만 아니라 압축 파일이나 네트워크 상의 파일도 사용할 수 있다.
- 이렇게 특수한 파일을 다루는 게 아니라면 COPY 명령문을 사용하는 것이 권장된다.
ENV : 이미지에서 사용할 환경 변수 값을 지정한다.
- path 등
CMD / ENTRYPOINT : 컨테이너를 생성 및 실행 할 때 실행할 명령어
- 보통 컨테이너 내부에서 항상 돌아가야하는 서버를 띄울 때 사용한다.
- CMD
  - 컨테이너를 생성할 때만 실행됩니다. (docker run)
  - 컨테이너 생성 시, 추가적인 명령어에 따라 설정한 명령어를 수정할 수 있습니다.
- ENTRYPOINT
  - 컨테이너를 시작할 때마다 실행됩니다. (docker start)
  - 컨테이너 시작 시, 추가적인 명령어 존재 여부와 상관 없이 무조건 실행됩니다.
명령어 형식
- CMD ["<커맨드>", "<파라미터1>", "<파라미터2>"]
- CMD <커맨드> <파라미터1> <파라미터2>
- ENTRYPOINT ["<커맨드>", "<파라미터1>", "<파라미터2>"]
- ENTRYPOINT <커맨드> <파라미터1> <파라미터2>

생성한 DockerFile을 Image로 빌드

이미지 빌드 명령어

docker build -t [이미지 이름:이미지 버전] [Dockerfile의 경로]

docker build -t apache-image .

생성된 이미지 확인

docker images

웹에 올릴 html 파일 생성

보통 웹으로 띄울 html 파일을 아파치 서버에 추가하고 싶을 땐
Dockerfile의 ADD / COPY를 통해 호스트의 파일을 아파치 서버 옮기는 명령어를 작성 후 빌드합니다.
하지만 이렇게 하면 호스트의 html 파일과 아파치 서버의 html 파일이 동기화 되어 있지 않기 때문에 매번 build를 해줘야합니다.
따라서 도커 볼륨을 사용해 호스트의 html 파일을 만들어놓고, 도커 컨테이너에서 그 파일에 접근해서 사용하는 방법으로 동기화 할 것입니다.
우선 호스트에 index.html 파일을 생성 및 수정합니다.

$ mkdir app && cd app
$ vim index.html

index.html

Hello world

Image로 Container를 생성

이제 컨테이너 생성 시 도커 볼륨을 통해 host와 도커 컨테이너의 html 폴더를 동기화 하겠습니다.

$ docker run --name apache-container -d -p 80:80 -v ./app/:/var/www/html apache-image

--name : 컨테이너 이름
-d : 백그라운드모드로 실행
-p : [호스트포트][컨테이너포트] 포트 연결
-v : 로컬과 컨테이너 파일 연동

접속확인

$ curl http://localhost:8080/index.html
Hello world

학습내용

목차

JSP vs Mustache vs Thymeleaf

Template Engine

서버 템플릿 엔진(SSR, Server Side Rendering)

클라이언트 템플릿 엔진(CSR, Client Side Rendering)

Mustache

JSP vs Mustache

Mustache vs Thymeleaf

@RequestBody

Gradle 의존성 옵션

Gradle

compile vs implementation

의존성 옵션들

assertj의 assertThat이 junit의 assertThat보다 편리한 이유

ModelAndView 객체를 이용한 리다이렉트, 포워딩

리다이렉트와 포워딩 비교

리다이렉트

포워딩

@RequestParam, @ModelAttribute, @RequestBody

@RequestParam

@ModelAttribute

@RequestBody

DB_CLOSE_ON_EXIT

JdbcTemplate를 사용하여 자동 생성 키를 얻기

AOP

AOP와 OOP의 관계

비즈니스 로직이란?

인프라 로직이란?

인프라 로직 특징

AOP를 사용하는 이유

Servlet Filter와 Intercepter

AOP 관련 용어들

AOP 실습

Spring Interceptor

Spring Interceptor 구현방법

ServletFilter와 Interceptor의 한계

Interceptor 실습

nohup, &

nohup이란 무엇인가

&이란 무엇인가

nohub으로 쉘 스크립트 파일 실행시 주의사항

실행방법

종료방법

nohup과 & 차이

배포 스크립트 만들기

배포과정은 무엇인가

배포 스크립트 필요한 이유

EC2 인스턴스에서 프로젝트 가져오기

배포 스크립트 작성

배포 스크립트 권한 추가

배포 스크립트 실행

@JsonInclude

InterceptorRegistry.addPathPattern

HttpSession invalidate, removeAttribute 차이

HTTP 상태 401(Unauthorized) vs 403(Forbidden)

HTTP 상태 401(Unauthorized)

HTTP 상태 403(Forbidden)

401(Unauthorized)과 403(Forbidden) 차이 정리

TIMESTAMP & DATETIME 자동 초기화 및 갱신

SLF4J Tmpleate 추가하기

Javascript Event Delegation

EC2 인스턴스에 MySQL 설치

DockerFile 작성

DockerFile 개념

DockerFile 장점

DockerFile 작성 및 명령어

생성한 DockerFile을 Image로 빌드

이미지 빌드 명령어

생성된 이미지 확인

웹에 올릴 html 파일 생성

Image로 Container를 생성

접속확인

References

Clone this wiki locally