application.properties로 변경시 발생한 에러

SaGo_MunGcci·2022년 8월 6일

Spring TIL trouble

스프링

목록 보기

13/31

Today do list

JWT 적용시 application.yml에서 application.properties로 변경시 발생한 에러를 해결함.

TIL

나는 주로 application.properites를 사용해서 yml 정리해서 TIL을 작성한다.
외부 설정 파일
애플리케이션에서 사용하는 여러가지 설정 값들을 애플리케이션의 밖이나 안에 정의하는 파일이다.
Spring boot를 이용해서 어플리케이션을 만들다 보면 외부에서 특정 값들을 주입받아야 하는 경우가 있다. (예를 들면 외부 API를 사용하기 위한 API key 등) 이러한 값들을 소스 코드에 그대로 쓰면 여러가지 문제가 생길 수 있다. 따라서 이러한 값들을 외부 설정 파일에 넣어 사용할 수 있다.
resources 디렉터리 밑에 있는 application.properties 나 application.yaml 파일은 스프링 부트가 자동으로 로딩하는 설정 파일들이다.

참고 : https://velog.io/@tjswlsdl135/application.properties-vs-application.yml

1. application.yml 형식

spring:

  h2:
    console:
      enabled: true

  datasource:
    url: 
    driver-class-name: 
    username: 
    password: 

  jpa:
    defer-datasource-initialization: true
    database-platform: org.hibernate.dialect.MySQL8Dialect
    hibernate:
      ddl-auto: create
    properties:
      hibernate:
        format_sql: true
        show_sql: true

logging:
  level:
    me.silvernine: DEBUG

jwt:
  secret: 

server:
  error:
    include-message: always

기술 매니저님께서 주로 yml 형식을 많이 쓰고 기능은 appication.properties와 똑같다고 하셨다. 다만 보기에 정리가 잘되어 있어서 사용을 한다고 하셨고 다른점은 들여쓰기로 한다는 점과 각 항목에 따라 코드를 정리해두는 점이 특징이었다. YAML은 계층 적 구성 데이터를 지정하기위한 편리한 형식이다.

2. application.properties 형식

내가 처음 적용했던 application.properties였는데, 이렇게만 작성하고 서버를 돌려보니 아래와 같은 오류가 나왔다.
MySQL8Dialect를 사용하면 아래와 같이 오류가 난다는 점이다.

아래와 같은 오류가 나왔는데 innodb via jdbc오류가 났고 그다음에는 MyISAM via jdbc라는 처음 보는 에러라서 MyISAM 과 innodb에 대허서 공부해 보았다.

InnoDB VS MyISAM

MySQL의 스토리지 엔진으로 가장 많이 사용하는 엔진으로는 InnoDB와 MyISAM이 있다.
InnoDB 엔진은 트랜잭션 처리가 필요하고 대용량의 데이터를 다루는 부분에서 효율적이고,
MyISAM 엔진은 트랜잭션 처리가 필요 없고, Read only 기능이 많은 서비스일수록 효율적이다.
한줄로 정리하면, InnoDB는 데이터의 변화가 많은 서비스에, MyISAM은 SELECT가 많은 서비스에 적합하다 할 수 있다.
용도에 따라 InnoDB나 MyISAM 스토리지 엔진을 결정하는데, InnoDB와 MyISAM 테이블을 같이 사용할 경우, 조인시 주의해야한다

참고 : https://velog.io/@gillog/DBInnoDB-VS-MyISAM

2번째로 구글링해서 적용한 방식인데 이때는 MySQL5Dialect를 사용하면 아래와 같이 오류가 난다는 점이다.

MyISAM via jdbc오류 발생.

3. 해결방법

내가 처음 적용했던 application.properties에서 위의 코드를 추가해줬다.
이 코드는 h2-cosole과 mysql의 언어가달라서 예약어관련 처리가 약간다른데 비록 ;MODE=MYSQL이라고 url에 직접적으로 선언을 해주어도 실제 스프링에서 테이블이 생성되어 h2콘솔에 들어갈때 체크하지 못하는 예약어가 있다고 한다. 따라서 위의 코드가 globally즉 전체적으로 모든 예약어를 잡아 주는 코드라고 이해했다.

결국은 해결이 되어 서버가 정상적으로 실행되었다.

Retrospection

이런 식의 오류는 코딩의 문제가 아니고 스프링의 동작방식와 에러의 원인을 이해하는 것이 중요한 것 같다고 오늘 배웠다. 이런 에러도 처음이었고 직접적으로 이에러를 처리하기위해서 yml과 properties의 원리를 배웠고 동시에 결과적으로 sql에 대한 중요성도 배우게 되었던 것이다.
기술매니저님께서 말씀해주신 코딩의 흐롬, 코드의 이해도 중요하지만 그에 못지않게 스프링의 동작원리와 작동방식 그리고 에러를 처리하고 해결하는 것에서 배우는 것도 상당하다는 말씀이 이번 에러를 처리하면서 많이 느껴졌다. 이것을 해결하기위해서 4~5시간 정도 결렸지만 해결하고 난뒤에는 여러가지 개념과 작동방식 특히 그래들에서 h2콘솔을 빌드하지 않으면 불충분한 의존성이라는 엄청난?! 에러를 만나게 된다는 것도 알게됬고 마지막으로 에러코드를 잘 읽으면 해결안되는 것도 해결할 수 있다고 깨닫게 되었다.
오늘 여러가지 많이 배웠으나 특징적인 것을 정리해보자면 위의 부분이 중요해서 TIL로 정리했다.