운영중인 서비스 스프링부트 3 업그레이드

목차

• 0. JDK
• 1. javax -> jakarta
• 2. querydsl
• 3. spring security

 

 

현재 Tidify  iOS 앱을 운영 중이다. 서버는 스프링부트 2.7.8 버전을 사용 중이었는데 연휴기간 동안 버전업을 진행했다.

버전업을 진행하면서 다양한 벽(?)에 부딪혔는데 그 과정을 하나하나 풀어보겠다. 

 

스프링부트 3 에는 다양한 라이브러리가 추가됐지만 다음의 큰 특징이 있다.

• Java17과 Java19 지원 (Java 21 도 추가)
• GraalVM 지원
• Spring framework 6.0 기반

 

0. jdk

스프링부트 3은 java17 을 기반으로 작성됐기 때문에 17 미만의 JDK는 지원하지 않는다. 

기존에도 jdk 는 java 17 을 사용하고 있었기에 별도로 jdk 업데이트는 하지 않았다.

 

1. javax -> jakarta

스프링부트 3 부턴 JavaEE 가 JakartaEE 로 변경되면서 javax.* 로 명명된 패키지를 모두 jakarta.* 로 수정해야 한다.

• Java Servlet(javax.servlet) -> Jakarta Servlet(jakarta.servlet)
• Java Message Servie (javax.jms) -> Jakarta Messaging (jakart.jms)
• JPA:Java Persistence API (javax.persistence) -> Jakarta Persistence(jakarta.persistence)
• JTA:Java Transaction API (javax.transaction) -> Jakarta Transaction(jakarta.transaction)
• Java Mail (javax.mail) -> Jakarta Mail (jakarta.mail)

필자는 IntelliJ IDE 를 사용하고 있어 간단하게 cmd + shifth + R 명령어로 javax 를 모두 jakarta 로 수정했다.

 

필자의 프로젝트가 소규모라 이런식으로 javax 패키지를 -> jakarta 패키지로 수정했는데 대규모 프로젝트에서도 이런 식으로 패키지를 수정해도 될지 모르겠다. 

 

2. querydsl

우선 build.gradle 에서 querydsl 플러그인을 제거한다. 이 부분을 제거하지 않아서 컴파일 할 때 지속적으로 에러가 발생했다.

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.7.8'
    id 'io.spring.dependency-management' version '1.0.15.RELEASE'

    // querydsl 주석 처리
    // id "com.ewerk.gradle.plugins.querydsl" version "1.0.10"
	...
}

 

dependencies 블럭에는 jakarta 패키지의 의존성을 추가한다.

dependencies {
	...
    // querydsl 기존 디펜던시
    implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
    annotationProcessor 'com.querydsl:querydsl-apt:5.0.0:jakarta'
    
    // 추가된 디펜던시
    annotationProcessor "jakarta.annotation:jakarta.annotation-api"
    annotationProcessor "jakarta.persistence:jakarta.persistence-api"
    
}

 

dependencies 까지 추가한 후에는 build.gradle 파일 하단에 아래의 내용을 추가한다.

필자는 build/generated 경로 하위에 querydsl 빌드 파일을 생성하도록 설정했다. 이 부분은 개개인 마다 차이가 있어 개별 프로젝트 설정에 맞게 변경해야한다.

 

개정 버전

// 버전업
def querydslDir = "build/generated/querydsl"
sourceSets {
    main.java.srcDirs += [ querydslDir ]
}

tasks.withType(JavaCompile) {
    options.generatedSourceOutputDirectory = file(querydslDir)
}

clean.doLast {
    file(querydslDir).deleteDir()
}

sourceSets {
    main.java.srcDir querydslDir
}
configurations {
    querydsl.extendsFrom compileClasspath
}

 

 

기존 버전

// 기존
def querydslDir = "build/generated/querydsl"
querydsl {
    jpa = true
    querydslSourcesDir = querydslDir
}
sourceSets {
    main.java.srcDir querydslDir
}
configurations {
    querydsl.extendsFrom compileClasspath
}
compileQuerydsl {
    options.annotationProcessorPath = configurations.querydsl
}

 

3. spring security

스프링부트3.0 부턴 스프링 시큐리티 6.0.0 이상의 버전이 적용된다. 기존 2.7.3 이후 부터 시큐리티 설정의 deprecated 된 내용이 추가되었고 3.0 부터는 아예 삭제된 설정도 있다. 

버전업을 하고 느낀점은 시큐리티에서 람다 DSL 을 보다 적극적으로 도입한 것이다. 공식문서에서 언급하듯 스프링시큐리티 5.2 버전부터 람다 DSL 을 사용할 수 있고 HttpSecurity 설정시 이를 적용할 수 있다.

람다 DSL 이 적용된 주요한 이유를 요약하자면 1) 리턴 타입이 명확하지 않다는 점과 2) 버전 간 코드 일관성 통일을 위해서 수정됐다고 한다.

 

https://docs.spring.io/spring-security/reference/migration-7/configuration.html

 

아래 수정된 코드를 보자. Boot 3.x 이전에는 antMatchers(...), mvcMatchers(...)  선언해서 특정 리소스에 대한 접근권한을 부여했지만, 개정 버전에서는 authorizeRequests() 에서 람다로 url request 의 권한을 설정한다.

또한 Boot 3.x 이후 부터는 antMatchers(), mvcMatchers() 가 없어지고 requestMatchers() 를 사용한다.

// 기존
@Override
protected void configure(HttpSecurity http) throws Exception {
    http.csrf().disable();
    http.httpBasic()
        .and()
        .authorizeRequests()
        .antMatchers("/oauth2/login").permitAll()
        .and()
        .addFilterBefore(new JwtAuthenticationFilter(jwtTokenProvider), UsernamePasswordAuthenticationFilter.class);
}

// 버전업
@Bean
protected SecurityFilterChain filterChain(HttpSecurity http, HandlerMappingIntrospector introspector) throws Exception {
    http.csrf(AbstractHttpConfigurer::disable);
    http.authorizeHttpRequests(authorize ->
            authorize.requestMatchers(new MvcRequestMatcher(introspector, "/**")).permitAll()
                .requestMatchers(new MvcRequestMatcher(introspector, "/oauth2/login")).permitAll()
                .anyRequest()
                .authenticated())
        .httpBasic(Customizer.withDefaults());
    return http.build();
}

 

또한 기존 버전에서는 WebSecurityConfig 에서 WebSecurityConfigurerAdapter 를 상속받아 사용했지만 스프링 시큐리티 5.7부터 WebSecurityConfigurerAdapter가 Deprecated 됨에 따라 오버라이딩해서 사용한 configure() 메서드를 사용할 수 없게 됐다.   

대신 SecurityFilterChain Bean 을 등록해 설정할 수 있다. 

 

JwtSecurityConfig

SecurityConfigurerAdapter 를 filterChain 에 직접 추가할 수 있다. 이를 위해 SecurityConfigureAdapter 를 상속받는 JwtSecurityConfig 클래스를 생성하고 이를 filterChain 에 추가했다.

현재 프로젝트는 jwt 를 이용한 로그인을 구현했기에 JwtSecurityConfig 클래스를 만들어 SecurityConfigurerAdapter 를 상속받았다.

 

@RequiredArgsConstructor
public class JwtSecurityConfig extends SecurityConfigurerAdapter<DefaultSecurityFilterChain, HttpSecurity> {
    private final JwtTokenProvider tokenProvider;

    @Override
    public void configure(HttpSecurity builder) throws Exception {
        JwtAuthenticationFilter authFilter = new JwtAuthenticationFilter(tokenProvider);
        builder.addFilterBefore(authFilter, UsernamePasswordAuthenticationFilter.class);
    }
}

 

JwtAuthenticationFilter

현재 프로젝트는 OncePerRequestFilter 를 상속받는 Jwt 인증 필터를 사용중이기에 이를 configure method 내부에서 직접 호출하여 filter 에 추가했다. JwtTokenProvider 는 jwt accessToken, refreshToken 을 발급하는 용도의 클래스다.

@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtTokenProvider jwtTokenProvider;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
        FilterChain filterChain) throws ServletException, IOException {

        String accessToken = resolveAccessToken(request);
        ... (내부구현)
        filterChain.doFilter(request, response);
    }
}

 

 

이제 JwtSecurityConfig 클래스를 filterChain 내부에 추가하기만 하면 된다. 

@Bean
protected SecurityFilterChain filterChain(HttpSecurity http, HandlerMappingIntrospector introspector) throws Exception {
    http.csrf(AbstractHttpConfigurer::disable);
    http.authorizeHttpRequests(authorize ->
            authorize.requestMatchers(new MvcRequestMatcher(introspector, "/**")).permitAll()
                .requestMatchers(new MvcRequestMatcher(introspector, "/oauth2/login")).permitAll()
                .anyRequest()
                .authenticated())
        .httpBasic(Customizer.withDefaults())
        .apply(new JwtSecurityConfig(jwtTokenProvider)); // JwtSecurityConfig 추가

    return http.build();
}

 

도식화하면 아래와 같은 모습으로 클래스간 의존관계가 형성된다.

 

 

WebSecurityConfig 코드 비교 정리

이전 버전 (스프링부트 v2.7.8)

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    private final JwtTokenProvider jwtTokenProvider;

    @Bean
    public PasswordEncoder passwordEncoder() {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }

    @Override
    public void configure(WebSecurity web) throws Exception {
        web.ignoring()
            .antMatchers("/api")
            .antMatchers("/oauth2/login")
            .antMatchers("/root");
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable();
        http.httpBasic()
            .and()
            .authorizeRequests()
            .antMatchers("/oauth2/login").permitAll()
            .and()
            .addFilterBefore(new JwtAuthenticationFilter(jwtTokenProvider), UsernamePasswordAuthenticationFilter.class);
    }

    @Bean
    @Override
    public AuthenticationManager authenticationManagerBean() throws Exception {
        return super.authenticationManagerBean();
    }

}

 

 

업그레이드 버전 (스프링부트 v3.0.2)

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class WebSecurityConfig {

    private final JwtTokenProvider jwtTokenProvider;

    @Bean
    public PasswordEncoder passwordEncoder() {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }


    @Bean
    public WebSecurityCustomizer webSecurityCustomizer() {
        return (web) -> web.ignoring().
            requestMatchers(new AntPathRequestMatcher("/api"))
            .requestMatchers(new AntPathRequestMatcher( "/oauth2/login"))
            .requestMatchers(new AntPathRequestMatcher( "/root"));
    }

    @Bean
    protected SecurityFilterChain filterChain(HttpSecurity http, HandlerMappingIntrospector introspector) throws Exception {
        http.csrf(AbstractHttpConfigurer::disable);
        http.authorizeHttpRequests(authorize ->
                authorize.requestMatchers(new MvcRequestMatcher(introspector, "/**")).permitAll()
                    .requestMatchers(new MvcRequestMatcher(introspector, "/oauth2/login")).permitAll()
                    .anyRequest()
                    .authenticated())
            .httpBasic(Customizer.withDefaults())
            .apply(new JwtSecurityConfig(jwtTokenProvider));
        return http.build();
    }

}

 

 

마무리

현재 티디파이 앱의 서버는 필수적으로 스프링부트 3.0이 필요한 상황은 아니었지만, 버전 업그레이드를 진행하면서 그간 모호하게 알았던 JavaEE 와 JakartaEE 에 대한 내용이나 spring security 에 관한 설정을 자세히 알아볼 수 있었다. 다음 포스팅에선 스프링부트3 의 graalVm에 관한 내용도 추가적으로 공부해봐야겠다.