학습내용

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 차이

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)
- 상태 : 서버가 해당 요청을 이해했지만, 권한이 없어 요청이 거부된 상태
- 예시 : 사용자가 권한이 없는 요청을 하는 경우

학습내용

목차

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) 차이 정리

References

Clone this wiki locally