스프링 부트를 사용하다보면 사람들이 착각하는 게 하나 있다.

스프링 부트로 개발하면서 부딪치게 되는 문제가 모두 스프링 부트에서 발생한다고 생각한다. ㅡ_-)>

실제 문제발생 부분은 본인이 추가한 모듈(JPA라면 스프링 Data JPA와 Hibernate, Web이라면 Spring 5 Servlet Stack, 보안 관련 부분은 Spring Security 5)에 기인한다.

스프링 부트를 이용한 개발 중에 발생한 문제에 대해 묻고 싶다면,
자신이 사용한 스프링부트 버전과 문제가 발생한 기능과 관련된 프레임워크나 라이브러리 버전을 거론해야 한다.

"무턱대고 스프링 부트로 개발하는데 문제가 발생했어요." 라고 묻는 건 잘못된 질문법이다.

자신의 문제를 풀어달라고 하면서, 스무고개 식으로 질문하는 행태를 보고 있으면... 답변해주고 싶지가 않다.

스프링 부트에서 제공하는 모듈을 사용하려면, 그 모듈이 제공하는 기능에 대해서 공부해야 한다.

JPA를 사용한다면, Spring Data JPA와 하이버네이트를 공부해야 하고, 웹기능을 개발한다면 Spring Servlet Stack을 봐야 하고, 비동기 기능을 개발한다면 Spring Reactive Stack을 봐야하는데...

자신이 사용하는 기능에 대한 자기학습없이 무턱대로 코딩부터 하는 습관은 좋지않다.


어떤 기능을 학습함에 있어서 기능을 구현해보면서 학습하는 것은 중요하다. 그러나 그에 앞서서 사용하는 기술의 기본적인 지식과 동작방식을 살펴보자.


스프링 부트 2.0 정식 출시

스프링 부트 2.0 새로운 점:

  • A Java 8 baseline, and Java 9 support.
  • Reactive web programming support with Spring WebFlux/WebFlux.fn.
  • Auto-configuration and starter POMs for reactive Spring Data Cassandra, MongoDB, Couchbase and Redis.
  • Support for embedded Netty.
  • HTTP/2 for Tomcat, Undertow and Jetty.
  • A brand new actuator architecture, with support for Spring MVC, WebFlux and Jersey.
  • Micrometer based metrics with exporters for Atlas, Datadog, Ganglia, Graphite, Influx, JMX, New Relic, Prometheus, SignalFx, StatsD and Wavefront.
  • Quartz scheduler support.
  • Greatly simplified security auto-configuration.

정리

기다리고 기다리던 스프링 부트 2.0이 정식으로 출시되었다.

스프링 부트 2.0 출시에 맞춰서 쓰고 있는 책은 내일 교정본을 받고 최대한 빨리 출간할 예정이다.

스프링 부트 2.0에서 크게 달라진 점은 스프링 프레임워크 5를 기반으로 하여 리액티브 지원이 가장 큰 부분이라고 생각된다.

아직까지는 리액티브 웹 프로그래밍을 적극적으로 활용한 경험은 없는 상태라서 살펴봐야할 부분이 많다.

살펴볼 수 있다.

관심가는 변화 중 하나는 JDBC 라이브러리가 Tomcat JDBC에서 HikariCP 로 변경되었다.

기존에는 Tomcat JDBC를 제외(exclude)하고 HikariCP 의존성을 추가해야했지만 지금은 굳이 그럴 필요가 없어졌다.

그리고 운영과 관련된 액츄에이터(Actuator)에서 DropWizard에 맞춰 지원하던 형식이 Micrometer에서 쉽게 사용할 수 있도록 개편되었다. 더불어서 액츄에이터 기본경로에 /actuator가 접두사로 붙게 되었다.

그레이들 관련한 플러그인도 조금 더 개선이 될 것으로 보인다.

참고


아... 스프링 부트 프로젝트가 1.5.8 까지는 레파지토리에 하위 프로젝트들을 유지하는 형태였는데...

https://github.com/spring-projects/spring-boot/tree/v1.5.8.RELEASE

2.0.0에서는

https://github.com/spring-projects/spring-boot/tree/v2.0.0.M6/spring-boot-project

으로 spring-boot-project 디렉터리를 만드어서 거기에 몰아넣었구나....


`WebMvcAutoConfiguration` 의 경우

1.5.8.RELEASE 는 `org.springframework.boot.autoconfigure.web`

2.0.0.M6 는 `org.springframework.boot.autoconfigure.web.servlet`


패키지 경로가 변경되었다. @_@);

2.0 나오면 책에 걸어둔 소스코드 링크 변경해야하네...

책의 경로를... 뽑아낼 필요가 있겠어.

AWS Elastic Beanstalk 에서 실행중인 Spring Boot 앱에서 오랜만에 파일 업로드를 할 때 다음과 같은 장애가 발생했다.
스프링 부트에 내장된 톰캣 컨테이너에서 생성한 임시디렉토리가 한동안 사용하지 않으면서 사라진 것으로 보인다.

그래서 찾아보니 다음과 같이 스프링 부트쪽 프로젝트에 이슈로 등록이 되어 있었다.

https://github.com/spring-projects/spring-boot/issues/9616
org.springframework.web.multipart.MultipartException: Could not parse multipart servlet request; nested exception is java.io.IOException: The temporary upload location [**/tmp/tomcat.1220970741172837513.8080/work/Tomcat/localhost/ROOT]** is not valid at org.springframework.web.multipart.support.StandardMultipartHttpServletRequest.parseRequest(StandardMultipartHttpServletRequest.java:111)

#springboot #multipartfile



AWS Beanstalk 에서 실행중인 스프링부트 앱에서 오랜만에 파일을 업로드하는 과정에서 생긴 오류.

디렉토리를 별도로 지정하고 없으면 생성하고 하는 방식을 찾아봐야겠다.

http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/tmp.html
Linux Filesystem Hierarchy:
Chapter 1. Linux Filesystem Hierarchy

1.20. /tmp

This directory contains mostly files that are required temporarily. Many programs use this to create lock files and for temporary storage of data. Do not remove files from this directory unless you know exactly what you are doing! Many of these files are important for currently running programs and deleting them may result in a system crash. Usually it won't contain more than a few KB anyway. On most systems, this directory is cleared out at boot or at shutdown by the local system. The basis for this was historical precedent and common practice. However, it was not made a requirement because system administration is not within the scope of the FSSTND. For this reason people and programs must not assume that any files or directories in /tmp are preserved between invocations of the program. The reasoning behind this is for compliance with IEEE standard P1003.2 (POSIX, part 2).


별도로 관리를 안하면 재부팅할 때만 지워지는 것으로 생각했는데...

신경 좀 써야겠다.


앱을 재시작하는 것으로 간단하게 대응했다.

해결방법은 찾아봐야겠다.

+ Recent posts