SMALL

 

기존 설정

# application.yml

# default
spring:
    profiles:
        active: test
---
spring:
    profiles: test
        include:
        - common
# 기타 설정 .. 
---
spring:
    profiles: prod
# 기타 설정 .. 
---
spring:
    profiles: dev
# 기타 설정 ..

spring.profiles 설정을 통해 어떠한 profile인지 표시 

spring.profiles.include 설정을 통해 추가적으로 포함할 profile 표시

 

2.4 버전 이후 설정

spring.profiles 설정은 duplicated 되었다

# application.yml

# default
spring:
  profiles:
    active: test
  group:
    dev: 
    - dev-t1
    - common
---
spring:
  config:
    activate:
      on-profile: test
# 기타 설정 .. 
---
spring:
  config:
    activate:
      on-profile: prod
# 기타 설정 ..       
---
spring:
  config:
    activate:
      on-profile: dev 
# 기타 설정 ..

spring.config.activate.on-profile 설정을 통해 어떠한 profile인 경우 해당 설정들이 활성화되는지 표시 

spring.profiles.group 설정을 통해 profile들을 그룹핑 

 

활성 profile 설정 

실제로 application을 실행할 때 spring.profiles.active 설정을 주어 어떠한 profile를 활성화할 것인지 정해주어야 한다.

해당 설정이 없을 시에는 default값으로 "default" profile이 실행된다.

 

위의 예시들처럼 yaml, properties file에 설정을 해주거나 

실행 시 argument로 넘겨도 된다.

java -jar myApp.jar --spring.profiles.active=dev

 

또는, 사용하는 개발 tool의 실행 argument에 설정해주면 된다.

( 이클립스의 경우 실행 프로젝트의 오른쪽 클릭 -> Run as.. -> Run Configurations ) 

 

추가적으로, 참고할만한 링크

spring-projects github에 2.4 관련 release note와 config data migration guide 

 

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.4-Release-Notes

 

GitHub - spring-projects/spring-boot: Spring Boot

Spring Boot. Contribute to spring-projects/spring-boot development by creating an account on GitHub.

github.com

 

 

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-Config-Data-Migration-Guide

 

GitHub - spring-projects/spring-boot: Spring Boot

Spring Boot. Contribute to spring-projects/spring-boot development by creating an account on GitHub.

github.com

 

LIST
SMALL

설정 파일 분리 

application.yml을 사용하는 경우에는 "---"를 사용하여 설정을 분리할 수 있다.

server:
  port: 8089
spring:
  profiles:
    active:
    - test
  application:
    name: pj2
---
server:
  port: 8089
spring:
  profiles:
    active:
    - dev
  application:
    name: devPj2

 

또한, profile 단위로 설정 파일 자체를 분리할 수도 있다.

  • application-dev.yml
  • application-test.yml
  • application-{profile}.yml

각각의 파일은 spring application을 실행 시 args 등으로 넘기는 spring.profiles.active로 결정되어진다. 

java -jar myApp.jar --spring.profiles.active=dev

 

여러 개의 설정파일 

하나의 profile에서 사용되는데 여러개의 설정 파일을 로드하고 싶은 경우가 존재할 수 있다.

이러한 경우에는 어떻게 설정하는지 알아보자.

 

spring.config.location

이 설정은 spring config의 기본 설정을 재정의하여 여러 가지의 설정 파일을 로드할 수 있다.

spring config에서 default로 제공하는 값은 아래와 같다.

사용자가 spring.config.location을 정의하면 default값은 덮어써지게 된다.

 

spring.config.additional-location

이 설정은 추가적인 위치를 설정하는 것이다.

location 설정에 플러스로 더 설정하고 싶은 경우 

 

spring.config.location, spring.config.additional-location 설정은 application.yml 파일을 로드하기 전에 사용되는 설정으로 해당 파일에 설정하면 동작하지 않는다.

SystemProperties나 CommandLine Argument로 전달해야 정삭적으로 사용될 수 있다.

java -jar myApp.jar --spring.config.additional-location=optional:classpath:test.yml

 

spring.config.import

해당 설정은 spring boot 2.4 이후부터 추가된 설정으로 위에 설명한 설정들과 달리 application.yml를 통해서 추가적인 설정 파일의 위치를 설정할 수 있다. 

 

spring:
  config:
    import:
    - optional:classpath:/test.yml

 

위의 내용들에 아래 spring문서를 확인하면 더욱 자세하게 확인 할 수있다.

https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config

LIST
SMALL

DTO 데이터 검증이 필요한 이유 

보통 Web Appliation을 작성하면, Front-End에서 사용자가 입력한 정보를 검증하고, 검증이 완료된 데이터를 Back-End에게 넘겨주게 된다.

하지만, 보통의 경우가 아닌 상황에서는 Back-End에서는 입력값으로 받은 DTO를 신뢰할 수가 없게 된다.

( Web Application UI를 통해 요청된 Request가 아닌 경우 - curl, postman 등등..)

이러한 상황에 대한 대비로 Back-End에서도 Request로부터 전달받은 DTO에 대한 검증이 필요하다.

 

@Valid

Spring에서는 DTO 필드에 조건과 메세지를 작성해주면, @Valid를 이용해 데이터 검증을 할 수 있다.

 

@Valid는 JSR-303, 380 표준 스펙으로

제약 조건이 부여된 객체에 대해 Beam Validator를 이용하여 검증하도록 지시하는 Annotation이다.

Spring에서는 LocalValidatorFactoryBean을 이용해 JSR 표준의 검증 기능을 사용한다.

 

SpringBoot 2.3 이상의 버전 부터는 spring-boot-starter-web 의존성 내부에 있던 validation이 사라졌다.

spring-boot-starter-validation 의존성을 따로 추가해 주어야 한다. 

 

Dto

@Getter
@NoArgsConstructor
public class UserSaveRequestDto {

    @NotBlank(message = "Please, insert UserID!")
    private String userId;

    @NotBlank(message = "Please, insert UserName!")
    private String userName;

    @Email(message = "Please, insert valid e-mail!",
            regexp = "^(?=.{1,64}@)[A-Za-z0-9_-]+(\\.[A-Za-z0-9_-]+)*@[^-][A-Za-z0-9-]+(\\.[A-Za-z0-9-]+)*(\\.[A-Za-z]{2,})$")
    private String email;

    @NotBlank(message = "Please, insert password!")
    private String password;

    @Size(min = 1, message = "User must be mapped with Group")
    @NotNull(message = "Please, insert GroupIdList!")
    private Set<String> groupIdList;
}

javax.validation.constraints에서 제공하는 valid 관련 Annotation 

https://docs.jboss.org/hibernate/beanvalidation/spec/2.0/api/

 

 

Controller

@RequiredArgsConstructor
@RestController
public class UserController {
    private final UserService userService;

    @PostMapping("/user")
    public String save(@RequestBody @Valid UserSaveRequestDto requestDto) throws Exception {
        return userService.save(requestDto);
    }
}

검증을 원하는 @RequestBody argument에 @Valid Annotation을 추가해 주면 된다.

 

Exception Handling

@ControllerAdvice
public class CommonExceptionHandler<T> {

    @ExceptionHandler(value = {MethodArgumentNotValidException.class})
    protected ResponseEntity<Response<T>> handleMethodArgNotValidException(
            MethodArgumentNotValidException exception) {

        Response<T> response = new Response<>();
        response.addErrorMsgToResponse(
                exception.getBindingResult().getAllErrors().get(0).getDefaultMessage()
        );

        return ResponseEntity.status(HttpStatus.NOT_ACCEPTABLE).body(response);
    }
}

@RequestBody로 부터 받은 파라미터에 Error가 발생한 경우에는 MethodArgumentNotValidException이 발생한다.

Spring의 Exception Handling 관련 Annotation을 이용하여 해당 Exception에 대한 처리를 추가해 주면 된다.

LIST
SMALL

SLF4J

Java에는 다양한 오픈소스 로깅 프레임워크가 존재한다.

이러한 다양한 종류의 프레임워크를 통합하기 위해서는 로깅 구현체를 추상화한 인터페이스 레이어가 필요하다.

해당 역할을 하는 것이 SLF4J이다. ( Simple Logging Facade For Java )

SLF4J는 인터페이스만 제공하고, 여러 구현체는 logback, log4j 등등이 있다.

구현체는 컴파일 시점에 지정된다.

Spring Boot 2.x 이후 버전에서는 SLF4J를 사용하고 아무 log관련 설정을 하지 않은 경우에는 default 설정으로 logback이 사용된다고 한다.

 

With Zero-Configuration Logging, the application will use underlying logging implementation Logback for logging. 

( https://www.baeldung.com/spring-boot-logging - 참고 )

 

 각 클래스마다 logger를 설정하기 위해서는 아래의 코드 선언해야 한다.

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

 

lombok

이러한 코드를 모든 클래스에 선언하는 것은 비효율적 일수 있다.

lombok에서는 이러한 코드를 생성해주는 어노테이션을 제공한다.

해당 어노테이션을 원하는 클래스에 추가해 주면 된다. 

(lombok 관련 dependency 추가 필요) 

@Slf4j
public class LoggingTestService {

}

 

Custom Log Configuration

이러한 형태로 사용하면 default로 제공하는 log기능을 사용할 수 있다.

다만, 기본으로 제공하는 형태 이외에 추가적인 설정을 하고 싶은 경우에는 설정 파일 조작이 필요하다. 

spring boot config인 application.yml 설정 또는 logback-spring.xml 설정이 존재한다. 

 

application.yml

application.yml에서 제공하는 추가적인 설정은 공식 홈페이지에서 확인하면 자세하게 나와있다.

( https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.logging.custom-log-configuration )

 

logging:
  level:
    org.springframework: ERROR
    com.test.ttt: DEBUG
  pattern:
    console: "%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"
    file: "%d %p %c{1.} [%t] %m%n"
  file: apptest.log

 

해당 설정은 개발단계에서 로그를 확인하기 적당하다.

다만, 실제 production단계에서는 log파일 관리가 중요하기 때문에 file rolling 등의 디테일한 설정이 필요하다.

 

이러한 경우에는 logback-spring.xml설정 파일을 사용하게 된다. 

해당 파일에 대한 디테일한 설정은 다음 포스팅에서 알아보도록 하자. 

 

 

LIST

+ Recent posts