이렇게 하면 myapp.war 파일을 사용하면서도 컨텍스트 경로는 /(루트)로 설정할 수 있습니다.
2. webapps/ROOT/ 폴더에 직접 배포하기
- Tomcat경로/webapps폴더 안에 ROOT 디렉토리를 만들고, 빌드한 .war파일을 안에 압축을 해제합니다.
4. 추가
Root.war 파일과 ROOT.war를 조심하시오.
Tomcat은 기본 컨텍스트(/ 경로)에 배포할 .war파일의 이름을 ROOT.war로 인식하기 때문에, 서버에 scp 명령어를 사용해 배포파일을 올리다가 Root.war로 올려버리면 Tomcat은 이를 올바르게 배포하지 못하고 무시하거나 동작이 잘못될 수 있습니다. 🥲🥲
자주 사용되는 객체나 메서드, 설정에 대해서는 Spring Configuration을 이용해 빈(Bean)을 스프링 컨테이너에 등록해 사용합니다.
그러나 환경 변수를 선언하고 이를 빈 컨테이너에 등록해 사용하는 방법도 있습니다.
프로젝트를 진행하는 도중 여러 환경 변수가 필요한 때가 있습니다.
(예: OAuth2.0 로그인을위해 필요한 시크릿 키를 설정해야 할 때, 혹은 Google SMTP를 사용하기위해 포트번호나 username, password의 등록이 필요할 때, CORS 설정을 config 이곳 저곳에 해 두었는데 여기 할당할 도메인이나 아이피를 전역변수로 편하게 관리하고 싶을 때 등)
이를 위해 스프링 프로젝트의 설정파일인 .properties 혹은 .yml에서 환경변수 설정방법을 알아봅니다.
아래와 같은 흐름으로 설명합니다.
1. .properties? .yml?
2. 환경변수 설정하기
3. 환경변수 사용하기
1. .properties ? .yml ?
두 파일형식 모두 보통 application.properties 혹은 application.yml의 형태로 프로젝트 경로(src/main/resources)에 포함되게 됩니다. 딱히 Maven이나 Gradle처럼 빌드도구를 달리한다고 해서 파일형태식이 지정되는 것이 아니라, 프로젝트의 성격에 따라 개발자가 프로젝트 생성 단계에서 정하게 됩니다.
- Spring boot에서는 환경별 설정파일을 이용해 환경에 따라 다른 설정을 적용할 수 있습니다. (예: 로컬개발환경에서의 파일경로설정 → C:\...(윈도우), 배포환경에서의 파일경로설정 → /home/user/...(리눅스))
.properties 파일형식을 사용하는 경우, 다음과 같은 규칙으로 환경별 설정 파일을 정의할 수 있습니다.
(한 파일에서 관리할 수도 있으나, 개별파일로 작성하는것이 관리에 더 유리합니다.)
application-{profile}.properties
application.properties: 기본 설정
application-dev.properties: 개발 환경
application-prod.properties: 운영 환경
application-test.properties: 테스트 환경
이후 기본설정파일에 spring.profiles.active=dev 형식으로 작성해 어떤 환경의 설정파일을 적용할 지 정할 수 있습니다.
(중복되는 설정이 있다면 기본 설정위에 활성화된 설정파일이 덮어씌워집니다.)
.jar 파일을 실행할땐 CLI환경에서 java -jar 파일명.jar -Dspring.profiles.active=dev 형식으로 설정파일을 적용해 실행할 수 있습니다.
.yml 파일형식을 사용하는 경우에도 환경별 설정을 한 파일에서 혹은 개별 파일로 관리할 수 있습니다.
application.yml: 기본 설정
application-dev.yml: 개발 환경
application-prod.yml: 운영 환경
application-test.yml: 테스트 환경
어떤 기준으로 설정파일 형식을 정하고, 어떻게 관리할 것 인가 ?
환경별 설정 파일 개수가 많아지는 경우 → 파일을 개별로 나누어 관리하는 것이 용이합니다.
properties 형식과 yml 형식의 차이는 다음과 같습니다.
개별 파일 관리가 기본적이고 권장되는 경우 → properties 형식: 계층구조 표현이 키-값 형태라 설정이 복잡해지는 경우, 하나의 파일에 모든 설정을 작성하면 읽기가 굉장히 어려워집니다.
yml형식: 계층구조 표현이 읽기 용이해 하나의 파일 안에서 관리가 쉬울것으로 판단되는 경우. 그러나 계층구조 표현이 읽기 쉬워도, 설정이 많아지면 개별파일로 관리하는 것이 용이합니다.
Relaxed Binding : 위의 예시들에서 모든 환경변수가 소문자로 작성되었는데, 본래는 Windows OS에서는 대소문자와 . _ 구분에 상관없이 환경변수에 따른 설정이 잘 적용됩니다. 그러나 Linux/Mac OS에서는 환경변수이름을 대문자로 작성해야하며 .대신 _기호를 사용하는 것이 안전합니다. 다만, Spring Boot에서 지원(2.4 이상에서 더 강화되었음)하는 Relaxed Binding 기능이 다양한 형식의 매핑을 지원합니다. Docker 컨테이너 역시도 대소문자에 관대합니다. 다만, 권장사항은 '환경변수는 대문자에 _기호를 조합해 작성하는 것이 가장 안전.' 입니다.
2. 환경 변수 설정하기
환경변수는 파일형식에 따라 아래와 같이 설정할 수 있습니다.
# properties 파일 환경변수 설정
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=admin
# yml 파일 환경변수 설정
spring:
datasource:
url: jdbc:postgresql://localhost:5432/mydb
username: admin
사용할 환경변수의 성격에 따라 개발자 임의로 이름을 짓고, 값을 할당할 수 있습니다.
그런데, 이미 존재하는 환경변수에 임의로 작성하게 된다면 어떻게 될까요 ?
예를들어, spring.jpa.hibernate.ddl-auto라는 JPA관련 환경변수 설정과 개발자가 임의로 작성할 환경변수 이름이 겹친다고 가정해보겠습니다.
Spring Boot는 설정값을 가져올 때 아래와 같은 순서를 따릅니다.
명령줄 인자(--spring.jpa.hibernate.ddl-auto=none)
JVM 옵션(-Dspring.jpa.hibernate.ddl-auto=none)
환경변수(SPRING_JPA_HIBERNATE_DDL_AUTO=NONE)
application.properties 또는 application.yml
기본 설정 값(스프링 내부 기본 값)
따라서 우선순위가 높은곳에 정의된 값이 우선으로 적용됩니다.
# application.properties 파일에서의 설정
spring.jpa.hibernate.ddl-auto=create
# 환경변수에서의 설정
export SPRING_JPA_HIBERNATE_DDL_AUTO=update
# 명령어 실행
java -jar myapp.jar
환경마다 각 설정값이 다르게 설정해 실행하면, 환경변수에서의 설정이 설정파일에서의 설정보다 높은 우선순위를 가져 해당 옵션은 update로 설정됩니다.
3. 환경변수 사용하기
예시: Google SMTP를 이용해 이메일을 보내려고 합니다.
SMTP 설정법에 따라 host, port, username, password 등을 설정파일에 작성해서 설정파일로 사용하려고 합니다.
# Google SMTP 설정 (properties 파일 내부)
spring.mail.host = smtp.gmail.com
spring.mail.port = 587
spring.mail.username = 이메일 작성부분
spring.mail.password = 비밀번호 작성 부분
spring.mail.properties.mail.smtp.auth = true
spring.mail.properties.mail.smtp.starttls.enable = true
spring.mail.properties.mail.smtp.starttls.required = true
spring.mail.properties.mail.smtp.ssl.trust = smtp.gmail.com
spring.mail.properties.mail.smtp.ssl.enable = true
이를 EmailConfig.java라는 설정 클래스 파일에서 다음과 같이 사용할 수 있습니다.
@Configuration
public class EmailConfig {
// SMTP 이메일 전송을 위한 설정클래스
@Value("${spring.mail.host}")
private String host;
@Value("${spring.mail.port}")
private int port;
@Value("${spring.mail.username}")
private String username;
@Value("${spring.mail.password}")
private String password;
....
}
혹은, Environment 객체를 통해 전역 변수를 프로그램 내에서 직접 읽어오는 방법도 있습니다.
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.core.env.Environment;
import org.springframework.stereotype.Component;
@Component
public class EnvironmentReader {
@Autowired
private Environment environment;
public String getAppName() {
return environment.getProperty("app.name");
}
public String getAppVersion() {
return environment.getProperty("app.version");
}
}
: 줄여서 GC 라고 부르기도 한다. 가비지 컬렉션은 메모리 관리 기법중 하나로, 동적으로 할당된 메모리 영역 중 더 이상 쓰이지 않는 영역을 자동으로 찾아내어 해제하는 기능이다.
옛날 언어들은 동적 메모리 할당 기능이 없거나, C처럼 프로그래머가 할당한 뒤 수동으로 해제까지 해 줘야 하는 방식이었는데, 사람이 하는 일이 항상 완벽할 수 없기 때문에 메모리 누수가 생기거나, 해제했던 메모리를 실수로 다시 사용하거나 해제헀던 메모리를 다시 해제하는 실수가 일어나 온갖 버그가 양산되었다. 이를 해결하기 위해 고안된 방법이 가비지 컬렉션이다.
작성한 Java 소스코드는 javac 컴파일러를 거쳐 바이트코드로 변환되고, 이 바이트 코드는 JRE(Java Runtime Environment)에 들어있는 java classloader에 의해 JVM으로 적재되고 JVM에 적재된 바이트코드를 JIT(Just In Time)컴파일 방식으로 실행하는 컴퓨터의 OS 및 CPU 아키텍처용 기계어로 번역되어 수행된다.
JVM의 강점은 '플랫폼 독립'적으로 JVM이 실행가능한 환경이라면 어디서든 Java 프로그램이 실행될 수 있도록 하는 것이다.
"Write Once, Run Anywhere"
단, 특정 운영체제의 특수한 기능을 호출하거나 하드웨어를 제어하는 등의 일은 JVM으로 할 수 없으며, JNI 같은 Navite 코드를 호출하기 위한 인터페이스를 거쳐야 한다. (이 부분에 대해 찾아볼 것 !)
또 Java 가상머신이라고 Java 바이트 코드만 인식하는 것이 아니라, Kotlin, Scala, Groovy처럼 Java에서 파생된 언어들의 바이트 코드 또한 인식할 수 있다.
다만, 이 바이트 코드가 실제 기계에서 실행되는 것이 아니라, JVM의 해석단계를 거치므로 같은 기능의 네이티브 언어(C, C++, Rust, Go 등)보다 실행속도가 느리다고 한다.
(현재는 JIT 컴파일의 도입과 하드웨어 발전으로 성능이 개선되었다고 한다 !)
가비지 콜렉션(GC: Garbage Collection) 또한 Java 계열의 강력한 무기라고 할 수 있을까?
JVM은 가비지 컬렉션을 수행하여 할당되었다가 더 이상 쓰이지 않는 메모리를 자동으로 회수한다.
Garbage Collection 알아보기 →(미완)
Java Class 파일 단독으로 실행시켜보기
국비학원에서 수업을 들을 때, JRE, JDK를 설치하고나서 강사님께서 가장 먼저 메모장에 클래스파일을 간단하게 작성해서 javac명령어를 사용해 클래스 파일 실행을 보여주신 적이 있다. 그땐 몰랐지만 지금은 알 수 있다 😁
public class test {
public static void main(String[] args) {
System.out.println("Hello World");
}
}
test.txt 메모장 파일을 생성해서 위와 같이 코드를 작성한다, 이후 저장하고 확장자명을 .java로 변경한다.
cmd 또는 powershell 명령 프롬프트를 열어, 메모장이 있는 폴더로 이동해
javac test.java 명령어를 입력한다.
그러면 같은 폴더에 test.class 파일이 생성된다.
다시 명령 프롬프트에 java test 명령어를 입력하면, 프롬프트에 Hello World가 출력되며 Class 파일이 실행된다.
어노테이션 속성에 groups이 포함되었는데 이 group이 이전 1편에서 언급한 '검증 그룹'입니다.
검증그룹은 별도의 클래스안에 인터페이스로서 명시할 수 있습니다.
public class ValidationGroups {
public interface NotBlankGroup{}
public interface SizeGroup{}
public interface PatternGroup{}
public interface AssertTrueGroup{}
}
ValidationGroups.class 파일 안에 내가 그룹명을 사용할 이름을 인터페이스로 명시합니다.
그리고 CommandVO의 Valid 어노테이션에 groups 속성으로 설정해 두면, 해당 어노테이션이 내가 설정한 groups에 속하게 됩니다.
이렇게 그룹설정을 하는 이유는 1편에서 설명한 바와 같이 컨트롤러 메서드에따라 검증그룹을 선택할 수 있을 뿐만 아니라, 검증 순서도 정할 수 있기 때문입니다.
지금상태에서는 사용자 데이터 유효성검사를 실행하면 아이디 → 닉네임 → 이메일 검증 순서는 작동되지만,
아이디 순서일때 빈칸에 대한 유효성 검사가 진행되거나 정규표현식 유효성 검사가 진행되거나 랜덤이므로 이 순서도 정해주어야 합니다.
@GroupSequence({
ValidationGroups.NotBlankGroup.class,
ValidationGroups.SizeGroup.class,
ValidationGroups.PatternGroup.class,
})
public interface ValidationOrder {
}
ValidationOrder 인터페이스를 만들고, @GroupSequence 어노테이션에 검증을 실시할 그룹을 순서대로 넣어주고, 컨트롤러의 @Validated 어노테이션에 이 순서를 사용함을 명시해주면 됩니다.
@PostMapping("")
public ResponseEntity<Map<String, Object>> signUpController(@Validated(ValidationOrder.class) @ModelAttribute CommandVO commandVO)
이렇게 적용하면 CommandVO의 유효성검사는 username(1. NotBlank, 2. Pattern) → password(1. Notblank, 2. Pattern) → email(1. NotBlank, 2. Pattern) 순서대로 이루어져 사용자에게 예외 발생시 안내메시지를 응답합니다.
문자열이 null이 아니고, 공백이 아닌 문자 하나 이상을 포함해야 함. (””, “ “) 불가능
@Size(min=, max=)
문자열, 컬렉션, 맵, 배열 등이 주어진 범위 내에 있어야 함.
@Min(value)
숫자가 지정한 최소값 이상 이어야함.
@Max(value)
숫자가 지정한 최대값 이하 이어야 함.
@Positive
숫자가 양수여야 함.
@PositiveOrZero
숫자가 양수거나 0이어야 함.
@Negative
숫자가 음수여야 함.
@NegativeOrZero
숫자가 음수거나 0이어야 함.
@Email
문자열이 이메일 형식이어야 함.
@Digits(Integer=, fraction=)
숫자가 지정된 자릿수를 넘지 않아야 함. (Integer = 정수부분 최대 자릿수, fraction = 소수부분 최대 자릿수)
@Pattern(regexp=)
문자열이 정규식에 매치되어야 함.
2. 예외 처리하기
발생한 유효성검증 예외를 처리하는 방법은 여러가지가 있지만, 대표적으로 2가지가 있습니다.
전역 예외 처리 핸들러를 사용하거나, Error 객체를 사용해 처리하는 방식입니다.
먼저 전역 예외 처리 핸들러를 사용하는 방법을 알아보겠습니다.
간단하게 ExceptionHandler.java 클래스를 다음과 같이 구현합니다.
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler({MethodArgumentNotValidException.class})
public ResponseEntity<?> handleValidationException(Exception ex){
// 사용자에게 응답할 객체
Map<String, Object> response = new HashMap<>();
// 예외를 처리할 BindingResult객체(아래 설명 참조)
BindingResult bindingResult = null;
if(ex instanceof MethodArgumentNotValidException){
bindingResult = ((MethodArgumentNotValidException)ex).getBindingResult();
}
response.put("message", bindingResult.getFieldError());
return ResponseEntity.ok().body(response);
}
}
@ControllerAdvice 어노테이션은 모든 @Controller 어노테이션이 할당된 클래스에서 발생하는 예외를 처리해주는 어노테이션 입니다. 비슷한 어노테이션으로는 @RestControllerAdvice 등이 있습니다.
메서드에 작성된 @ExceptionHandler({예외클래스}) 메서드는 파라미터에 작성된 예외를 처리하겠음을 명시합니다.
앞서 유효성검사 과정에서 발생된 예외가 MethodArgumentNotValidException 예외였으므로 이 예외를 작성해줍니다.
메서드의 파라미터에서는 해당 예외를 처리할 수 있도록 Exception 객체를 주입받습니다.
우리가 받는 사용자 데이터는 Spring의 데이터 바인딩 과정을 통해 사용자 데이터 -> CommandVO 객체로 변환됩니다.
예외는 이 과정에서 발생하므로 데이터 바인딩중 발생한 에러를 다루기 위해 BindingResult 객체가 필요한데, BidningResult 객체는 Exception객체 하위의 상세 예외객체에서 가져올 수 있으므로, 이 과정을 위해 예외가 정확히 어떤 예외인지 형변환을 실시해야 합니다.
현재 이 예시에서는 MethodArgumentNotValidException을 다루므로, 해당 예외로 형변환 합니다.
