리승자이의 삽질 그리고 정리

저번 포스팅의 마지막 마무리가 바로 이 에러를 찾지 못했던 것이다. Kafka 에러를 고치게 된 시점 처음에 특정 Consumer만 consume을 못한다고 했었는데, 이는 당연 잘못된 것이었다!!! 그냥 로그를 좀 더 세세하게 찍고 검토를 더 열심히 했어야 했다! 우선 대략적으로 코드를 보면 아래와 같다. @KafkaListener(topics = "topic", properties = { "spring.kafka.consumer.properties.spring.json.type.mapping=com.github.lsj8367.MessageReq" }) public void consumeSomething(final MessageReq req, Acknowledgment acknowledgment) { ..

일전에 카프카 에러 포스팅 에서 Configuration 설정을 자바 클래스에서 해주었다. 그것도 클래스별로!! 에러 포스팅과 더불어 This error handler cannot process 'SerializationException's directly; please consider configuring an 'ErrorHandlingDeserializer' in the value and/or key deserializer 이런 문구도 출력해줬었다. 근데 저 에러 포스팅을 보면서 좀 더 공통화할 수 없을까에서 찾아보다가 ErrorHandlingDeserializer 관련 검색을 해보다가 문서에서 찾게 되었던게 있는데, 기존의 설정을 이미지로 한번 가져와봤다. 그런데 이 방법을 Listener가 늘어나..

모든 코드는 깃허브 에 있다. Validation Validation의 사전적 정의는 확인 이다. 프로그래밍을 하면서 Validation을 한다고 하면 유효성 검증, 즉, 수없이 싸우는 null과 빈 값에 대해 검증을 한다. 뭐 때에 따라서는 조건에 맞는 값이 들어와야 한다는 것도 포함이다. 유효성 검증 애초에 검증을 한다는 것을 단순하게 생각하면 스프링에서 어떤 요청이 하나 들어왔다고 치자. @RestController public class Hello { @GetMapping("/hello") public String hello(@RequestParam String name) { return "hello " + name; } } /hello?name=이름이라는 주소로 호출을 한다면 파라미터에 name..

HandlerMethodArgumentResolver 이 HandlerMethodArgumentResolver에 정의되어있는 자바독을 읽으면 주어진 요청의 컨텍스트에서 메소드 매개변수를 인수 값으로 해석하기 위한 전략 인터페이스라고 설명되어 있다. 이 HandlerMethodArgumentResolver에는 이렇게 두개의 메소드가 있는데 supportsParameter()로 메소드의 매개변수를 처리할 수 있는지 여부를 판단한다. @RequestBody @RequestBody 어노테이션을 읽으려면 HandlerMethodArgumentResolver AbstractMessageConverterMethodArgumentResolver AbstractMessageConverterMethodProcessor R..

@RequestParam을 처리해주는 아규먼트 리졸버 = RequestParamMethodArgumentResolver RequestParamMethodArgumentResolver는 AbstractNamedValueMethodArgumentResolver를 상속한 콘크리트 클래스고, resolveArgument를 오버라이딩 하지 않았기 때문에 AbstractNamedValueMethodArgumentResolver.resolveArgument가 호출된다. 흐름도 일단 흐름도는 이러하다. 어제 살펴봤던 내용은 DispatcherServlet 이전의 처리내용이었다. 스프링 MVC에 대해서 교환대라고 할 수 있는 DispatcherServlet 이 클래스가 HandlerAdapter 등.. 조건에 부합하는 ..

얼마만의 포스팅인지 모르겠다. 일단 바로 스타트 ❗❗❗ 깃허브를 원래 올리는게 맞지만 회사 코드라서 따로 올리지는 못한다. 😥😥😥 테스트 @GetMapping에 대해서 어떻게 돌아가는지 궁금해서 무작정 실행을 시켜봤다. 지금 보이는 이미지는 톰캣에서 HTTP 메세지를 받아오는 구간이다. 그러니까 DispatcherServlet전에 수행되는 구간이다. 어떻게 저걸 담고있냐는 localhost:8081/swagger-ui.html 이라는 곳에서 크롬브라우저를 이용한 HTTP 통신을 하려고한다 라는 헤더를 추출한것이다. 여기서 api를 호출하고 GET방식으로 조회하는것 까지 확인했다. 오해했던 부분 처음에 나는 @GetMapping이 GET메소드를 만들어준다? 라고 생각했다. HTTP 완벽 가이드를 읽으면서도..

삽질기 모든 코드는 깃허브에 있다. 일단 저번에 마이그레이션 1탄을 했었는데 의존성이 겹쳐서 다시 리팩토링 하려고 보니까 에러가 많았다. 의존성 겹침 에러 일단 의존성이 겹쳐서 생긴 에러가 조금 있다. 부분만 적은 gradle 일부이다. plugins { id 'org.springframework.boot' version '2.5.3' id 'io.spring.dependency-management' version '1.0.11.RELEASE' } dependencies { implementation ( 'org.springframework.boot:spring-boot-starter-web', //이부분 'org.spring..