최근에 회사에서 Spring-Batch로 개발을 하면서 다음과 같은 오류를 보게되었습니다.org.springframework.dao.TransientDataAccessResourceException: Cannot change the ExecutorType when there is an existing transaction제가 당시에 사용하던 코드는 아래와 같은 모양이었습니다.@Beanpublic MyBatisPagingItemReader mybatisPagingItemReader() { ...}@Beanpublic ItemWriter itemWriter() { return (chunk) -> { modelMapper.insertModelList(chunk.getItems()); ..

기존에 제가 담당하던 시스템을 매우 Legacy한 시스템입니다.최근에 spring boot를 적용하고 생성된 jar 파일을 실행시키는데 profile이 제대로 적용되지 않는 상황이 발생했습니다.여러 자료들을 찾아보니 jar 파일을 실행새키면서 profile을 적용하는 방법은 총 2가지가 있었습니다.Java System Propertiesjava -jar -Dspring.profiles.active={프로파일} 파일위치 java option현 구조에서 주의해야할 사항은 -Dspring.profiles.active 옵션이 파일 위치보다 앞에 있어야 합니다. 만약 그렇지 않다면 실행시 profile을 인식하지 못 합니다.Program Argumentsjava -jar 파일 위치 --spring.profiles..

@Async 사용법 @EnableAsync @SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } } @Service public class MessageService { @Async public void print(String message) { System.out.println(message); } } @RequiredArgsConstructor @RestController public class MessageController { private final MessageService messa..

CSRF란 CSRF 링크 Rest API 에서 csrf를 disable하는 이유 CSRF의 취약점은 공격자가 사용자가 의도하지 않는 요청을 수행하게 하는 취약점입니다. 즉 공격자는 사용자가 가지고 있는 권한 범위 내에서 악의적인 행위를 할 수 있습니다. 일반적으로 해당 권한은 쿠키와 세션을 이용해서 인증을 하고 있기 때문에 발생하는 일입니다. 하지만 Rest API를 이용한 서버라면, session 기반 인증과는 다르게 stateless하기 때문에 서버에 인증 정보를 보관하지 않습니다. 일반적으로 jwt 같은 토큰을 사용하여 인증하기 때문에 해당 토큰을 Cookie에 저장하지 않는다면 csrf 취약점에 대해서는 어느 정도 안전하다고 말할 수 있습니다.

Spring MVC란 Spring MVC란 Front Controller Pattern에 기초한 웹 MVC 프레임워크입니다. Spring MVC는 Model, View, Controller를 명확한 클래스로 분할하고 losse coupling 시켜놓아서 매우 유연하고 확장성이 좋게 만들어 놓았습니다. Spring MVC의 구성요소 DispatcherServlet Spring MVC가 Front Controller Pattern에 기반하고 있는데 바로 그 Front Controller가 DispatcherServlet입니다. DispatcherServlet은 클라이언트의 모든 요청을 접수합니다. 그리고 받아들인 요청에 대한 처리를 다른 컴포넌트들에게 보내서 위임하고 있습니다. Infrastructure C..

Spring WebFlux Spirng WebFlux는 Event driven 방식이고 비동기 논블로킹 방식입니다. WebFlux는 Node.js처럼 이벤트 루프가 돌아서 요청이 발생할 경우 그것에 맞는 핸들러에게 처리를 위임하고 처리가 완료되면 callback 메소드 등을 통해 응답을 반환합니다. 그래서 이 방식의 경우 Spirng MVC에 비해 적은 스레드로 많은 사용자의 요청을 받아낼 수 있습니다. Spirng MVC Spring Mvc는 사용자의 요청이 들어왔을 때마다 Thread를 생성하여 요청을 처리합니다. 하지만 다수의 사용자 요청이 들어왔을 때, Thread를 계속 생성하는 것은 리소스가 굉장히 많이 들어갑니다. 그래서 Spring MVC의 경우 어플리케이션이 실행되면서 Thread Poo..