경험의 연장선

Gradle Test Fixture 사용해서 테스트 중복코드를 줄일 수 있어요. 멀티모듈 구조에서 다른 모듈의 Test 폴더를 사용할 수 없으니, 중복되는 클래스가 각각의 모듈의 Test 폴더에 포함되었어요. 저는, Gralde 멀티모듈 구조에서, 의존을 하는 모듈의 Test 폴더까지 사용하고 싶었어요. 이때 사용할 수 있는 것이 Gradle Test Fixture입니다 ㅎㅎ TestFixutre 적용 먼저 test fixture를 사용할 모듈에서 testfixture 의존성을 넣어요. (domain-cvi/build.gradle) plugins{ id 'java-library' //**new**!! id 'java-test-fixtures' //**new**!! id &#3..

콜백이란 어떤 이벤트가 발생했거나 특정 시점에 도달했을 때 시스템에서 호출하는 함수를 말해요. Bean 생명주기 콜백(Bean LifeCycle Callback)이란 단어를 들으면, 머릿속에 딱 와닿는 느낌이 없는듯해요. 각 단어에 많은 의미가 있기 때문이라 생각해요. 생명주기 콜백을 알아보기 전 각 용어에 대해 짚고 가볼 필요가 있어요. 스프링 빈 (Spring bean) 빈 또는 빈 객체는 스프링이 IoC 방식으로 관리하는 오브젝트라는 뜻이에요. 주의할 점은 스프링을 사용하는 애플리케이션에서 만들어지는 모든 객체가 다 빈은 아니라는 사실이에요. 그중에서 스프링이 직접 생성과 제어를 담당하는 객체만을 빈이라고 불러요. Bean 생명주기 Bean 객체가 생성되어 소멸하기 전까지의 모든 과정을 이르는 말이..

블로그를 작성하고, 테코톡을 진행했어요. 더 쉽게 이해하고 싶다면 아래 영상을 시청해주세요! [10분 테코톡] ☂️ 검프의 Logging(로깅) #2 Logback 로깅 프레임워크 중 하나로, SLF4J의 구현체에요. SLF4J에 관한 설명은 앞선 포스팅으로 대신할게요. [Logging] SLF4J란? Logback 구조 Logback은 아래 3가지 모듈로 나뉘어요 logback-core logback-classic logback-access logback-core: 다른 두 모듈을 위한 기반 역할을 하는 모듈이에요. Appender와 Layout 인터페이스가 이 모듈에 속해요. logback-classic: logback-core에서 확장된 모듈로, logback-core와 SLF4J API 라이브러리..

블로그를 작성하고, 테코톡을 진행했어요. 더 쉽게 이해하고 싶다면 아래 영상을 시청해주세요! [10분 테코톡] ☂️ 검프의 Logging(로깅) #1 SLF4J(Simple Logging Facade for Java)는 이름에서 확인할 수 있듯이. java.util.logging, logback 및 log4j와 같은 다양한 로깅 프레임 워크에 대한 추상화(인터페이스) 역할을 하는 라이브러리에요. SLF4J는 추상 로깅 프레임워크이기 때문에 단독으로는 사용하지 않아요. 즉, 최종 사용자가 배포시 원하는 로깅 프레임워크를 결정하고 사용해도 SLF4J가 인터페이스화 되어있기에, SLF4J를 의존하는 클라이언트 코드에서는 실제 구현을 몰라도 돼요(의존관계 역전 법칙). SLF4J 동작과정 SLF4J은 간략히 아..

Handler Interceptor 전반적인 클라이언트 요청흐름 그림에서 확인해보면, Spring Container내에서 Handler Mapping(수행할 handler 결정) 이후 HandlerAdaptor(결정된 핸들러 수행) 전/후 과정에서 수행됨을 확인할 수 있어요. 주 사용 목적은 핸들러(컨트롤러)의 수정없이 핸들러 수행 전/후처리 동작을 추가하여 핸들러(컨트롤러)의 반복적인 코드를 제거하기 위함이에요. 쉽게 말해, HandlerMapping이 결정한 handler을 HandlerAdapter 수행 전, 후로 가로체어 추가적인 작업이 가능해요. 또한 View 렌더링 이후 클라이언트에게 Response를 전달하기 전에 추가적인 작업이 가능해요. 어디에 사용될까? 가만보니, Filter와 매우 유..

스프링 mvc의 전반적인 요청과정은 이전에 정리했어요 [Spring] 쓰레드 관점에서 본 Spring MVC HTTP 요청과정 Servlet Filter 요청을 받은 WAS가 Servlet Container에게 Request, Response를 던져주면, 이를 먼저 Filter에서 받아. Request에 대한 필터링를 진행하고, 서블릿에게 ServletRequest, ServletResponse를 건네요. 요청에 대한 작업이 끝난 후 Response에 대한 필터링를 진행해요. 쉽게말해, 요청과 응답에 대한 필터링을 진행해요. 동작과정 import javax.servlet.*; import java.io.IOException; public class GumpFilter implements Filter { ..

우선 스프링 MVC의 요청과정을 큰 그림으로 보기로 해요. 큰 흐름으로, 클라이언트가 HTTP 요청을 보내면, WAS는 TCP/IP 연결 대기 과정(welcome 소켓)에서 클라이언트를 위한 소캣(연결 소켓)을 생성해서 연결해요. 연결 이후 많은 과정이 일어나요. (다음 과정으로 간다는 것은, 반환되지 않았다는 얘기에요) WAS는 HTTP 메시지를 파싱해서, Web Server에서만 필요한 정보면, 정적 페이지를 반환해요. Request, Response 객체를 만들어 Filter 객체에 던져줘요. Filter에서 요청된 내용을 변경(인코딩 변환 처리)하거나, 여러가지 체크(XSS 방어)를 해요. 여기서 체크에 걸린다면, 예외를 반환해요. WAS에서 HttpServletRequest, HttpServle..

@Service public class PathService { private static final Logger logger = LoggerFactory.getLogger(PathService.class); private final LineService lineService; private final StationService stationService; private final PathFinder pathFinder; ... @Transactional(readOnly = true) public PathResponse findPath(Long departure, Long arrival, LoginMember loginMember) { try { logger.info("캐시 되에에엠~"); List li..

애플리케이션 컨텍스트 오브젝트 팩토리(직접 설정 정보를 넣어주는 것, DaoFactory)에 대응하는 것이 스프링의 애플리케이션 컨텍스트예요. 스프링에서는 이 애플리케이션 컨텍스트를 IoC컨테이너라 하기도 하고, 간단히 스프링 컨테이너라고 부르기도 해요. 또는 빈 팩토리라고 부르기도 해요. ApplicationContext는 빈 팩토리가 구현하는 BeanFactory 인터페이스를 상속했으므로, 같이 봐도 괜찮아요. 특정 클래스를 설정정보를 등록하고, @Bean이 붙은 메소드의 이름을 가져와 빈 목록을 만들어줘요. 애플리케이션 컨텍스트의 getBean() 메소드를 호출하면 자신의 빈 목록에서 요청한 이름이 있는지 찾고, 있다면 빈을 생성하는 메소드를 호출해서 오브젝트를 생성시킨 후 클라이언트에게 돌려줘요...