일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 자료구조
- 동시성
- 김영한
- 시작하세요 도커 & 쿠버네티스
- Collection
- container
- 중급자바
- java
- LIST
- 제네릭스
- 시작하세요! 도커 & 쿠버네티스
- Kubernetes
- 자바
- 스레드 제어와 생명 주기
- 도커
- 리스트
- 컨테이너
- 쓰레드
- 멀티 쓰레드
- 도커 엔진
- 쿠버네티스
- Docker
- 실전 자바 고급 1편
- 스레드
- 인프런
- Thread
- 오케스트레이션
- contatiner
- 알고리즘
- 실전 자바 중급 2편
- Today
- Total
목록TroubleShooting & 고민/BE (15)
쌩로그
목록포스팅 개요본론 요약1. 포스팅 개요컨트롤러 테스트를 하는 도중 ResponseEntity의 제너릭에 아무 타입도 지정해주지 않고 반환하려 한 요청 핸들러 메서드들이 있었다. 경고 줄이 나오는 게 조금 신경쓰였고, 수정, 삭제 같은 경우 HttpStatus 외에 메세지로 수정, 삭제가 완료되었다는 메세지를 응답 데이터로 넣어주는 게 좋을 거 같아서 아래와 같이 MessageResponse라는 커스텀 타입을 만들어서 반환하도록 했다. 그리고 컨트롤러 테스트를 하는 도중에 제너릭 타입을 바꾼 요청 매핑 핸들러 테스트만 실패했다. 이를 해결하고자 한 포스팅이다.2. 본론자 로그를 살펴보자.문제의 단서 첫 번째 200을 바랬지만, 406이 떴다.https://developer.mozilla.org..
목차포스팅 개요본론요약 및 참고 블로그1. 포스팅 개요해당 포스팅은 트러블 슈팅 포스팅이다.요즘 부트캠프 때 진행했던 메인 프로젝트르 리팩터링 하는 중이다.최대한 테스트 코드를 많이 짜고 있다.일단 내가 맡았던 도메인이었던 Borrow 라는 대여 CRUD를 지금 개발 & 구현 중인데,목록 쪽 개발중이다.여러 건의 게시물 목록을 응답하기 위해서 QueryDSL을 사용 중이다.(나중에는 JOOQ 배우고 JOOQ로 변경해볼 예정이다.)지금까지 트러블 슈팅 만난 배경이다.어디서 문제를 만났는지는 본론에서 살펴보자.2. 본론두 개의 코드를 아래에 쓸 것이다.근데 진짜 똑같다.한 군데가 다르다.근데 그 한 군데 때문에 테스트가 성공하거나, 테스트가 실패한다.(import와 패키지는 생략한다.)먼저 성공하는 코드다...
목록포스팅 개요본론결론 및 요약1. 포스팅 개요요즘 너무 인풋만 해서 output을 하려니 머리가 안 돌아가서 배운 걸 써먹기 위해서 부트 캠프 때 진행했던 메인 프로젝트를 리팩터링 중이다.테스트 코드도 일일이 다 작성하는 중이다.컨트롤러 Bean Validation 검증 테스트 중 강의 내용을 참고하는데도 컨트롤러 테스트에서 계속 성공하지 못 하길레 가만히 들여다봤더니, 컨트롤러에도 @Controller가 있고, 내부에 @ResponseBody를 가진 @RestController가 있듯이#ControllerAdvice에도 내부에 @ResponseBody를 가진 @RestControllerAdvice가 있다..@RestController를 몰라서 해맸다.그냥 잊지 않기 위해 포스팅 한다..레포 링크 :..
목록 포스팅 개요 본론 요약 1. 포스팅 개요 저번에 검색 조건을 가진 Condition클래스 작성시 바인딩 되지 않던 문제 해결이라는 주제로 포스팅을 했었습니다. 당시 검색조건을 필드로 가지던 클래스로 생성된 인스턴스를 계층별로 넘겨서 Repository 계층에서 받고, 인스턴스의 필드 값을 판별해서 데이터 조회결과를 반환하도록 했었습니다. 당시 그냥 구현에만 신경쓰다가 검색 조건 클래스에 @Setter를 무작정 쓰고, "와~ 됬다!"만 하고 끝냈었습니다. 그런데 @Setter를 쓰면, 객체의 변경 가능성의 여지를 열어두기 때문에, 다른 방법을 찾아봤어야 함에도 불구하고, 되었다고 기분이 좋아서 그냥 그대로 사용했었는데요. 이번에 @Setter를 제거하면서 객체의 변경가능성을 다시 닫고, GET매핑시 ..
목록 포스팅 개요 본론 2-1. N+1 2-2. 그럼 N+1은 과연 왜 발생 하게 된 걸까? 2-3. QueryDSL을 사용하므로 얻게 된 효과 요약 1. 포스팅 개요 저번에 N+1 문제가 터져서 QueryDSL을 해결했다고 했는데 자세히 들여다보니 N+1이 근본적으로 해결된 건 아니었다. 오히려 나의 無知(없을 무, 알 지)만 드러낸 포스팅이었다. 그래서 해당 포스팅은 살며시 삭제를 해줬다. 하지만, 나의 마크다운 폴더에는 남아있다... 그거도 나름 공들여서 쓴거라.. 이번에 나의 오점을 제대로 짚어보고자 해당 포스팅을 하게되었다. 2. 본론 2-1. N+1 연관 관계에서 발생하는 이슈로 연관 관계가 설정된 엔티티를 조회할 경우에 조회된 데이터 갯수(n) 만큼 연관관계의 조회 쿼리가 추가로 발생하여 데..
목록 포스팅 개요 본론 2-1. 문제 발생 2-2. 문제 해결 방향 2-3. 문제 해결 요약 1. 포스팅 개요 PostDto로 LocalDate를 받을 때 다음과 같은 코드로 (비슷하게) 작성되어있다. @JsonFormat(pattern = "yyyy-MM-dd") private LocalDate localDate;Spring Rest Docs를 이용해서 API문서를 작성하려고 하는데, Gson 라이브러리의 Gson객체로 toJson()메서드를 이용해서 자바코드로 생성된 클래스를 JSON으로 파싱했다. JSON으로 변환한 데이터는 API 문서에 정보를 넣어줄 때 다음과 같이 content에 넣는다. 이 때 PostDto를 생성할 때 LocalDate 값을 넣어주는데, 그냥 생성자 혹은 빌더패턴을 사용하더..
목록 포스팅 개요 본론 2-1. 구성 클래스 2-2. 문제 살펴보기 2-3. 문제 해결하기 2-3-1. 번외 @Getter 사용해보기 2-3-2. @Setter로 진짜 문제 해결하기 요약 1. 포스팅 개요 이번 프로젝트에서 동행 도메인 같은 경우, 쿼리스트링으로, 지역과 날짜(동행시작 날짜)를 검색해서 조회하는 기능을 구현했는데, 쿼리스트링으로 검색 조건을 넣더라도, 검색조건을 가지는 클래스(AccompanySearchCondition)의 필드와 바인딩 되지 않던 문제를 해결하는 포스팅이다. 결론부터 말하자면 @Setter를 쓰면 된다. 2. 본론 2-1. 구성 클래스 먼저 관련된 클래스 코드를 보면 다음과 같다. Controller // 동행 전체 조회(날짜, 지역) @GetMapping public ..
목록 포스팅 개요 본론 2-1. 일단 결론 2-2. 애플리케이션 로직 2-3. 문제 발생 2-4. 문제 해결 방향 2-5. 문제 해결 요약 1. 포스팅 개요 Entity 클래스에 @Builder 애너테이션을 클래스 레벨에 두었었는데, 클래스에 new ArrayList();를 다음과 같이 선언했음에도 불구하고, NullPointerException(이하 NPE)이 발생했다. 이를 해결한 포스팅이다. @OneToMany(cascade = CascadeType.ALL, mappedBy = "accompany", orphanRemoval = true) List 땡땡List = new ArrayList();예전에 봤던 글에서 @Builder를 주의해서 쓰자고 봤는데,,, 흠.. 이번에 마주쳤다. 2. 본론 2-1..
목차 포스팅 개요 본론 2-1. 문제가 무엇인가? 2-2. 문제 해결 2-3. 해결 결과 요약 1. 포스팅 개요 AOP로 AccessToken 검증(빡쳐서 만듬)이라는 제목으로 포스팅을 했다. AccessToken을 검증하는데 코드상으론 400대 에러를 던지도록 해야하는데, 왠지 모르게 500번대 에러를 던졌다. 이걸 AOP로 해결했었는데, 물론 구현한 부분에서는 나름 괜찮았다고 생각하지만, 사실 AOP를 사용할 필요가 없었고, 또 한 분은 감사하게도 댓글로 알려주시길.. 라고 남겨주셨다. 말씀하신 것처럼 AOP의 목적에 맞게 쓰이지 않았다. 이를 수정하고, 무엇이 문제였는지에 대한 포스팅이다. 2. 본론 2-1. 문제가 무엇인가? 먼저 당시 왜 500번대 에러가 발생했는지를 살펴보자. 먼저 Securi..
목록 포스팅 개요 본론 요약 1. 포스팅 개요 AccessToken을 검증하는데 코드상으론 400대 에러를 던지게 해놨지만, Spring Security 설정 때문인지 내부적으로 500대 에러를 내보낸다. 그래서 살짝 빡쳤다... 계속 살펴보고 살펴보다가 생각해낸 것이 AOP였고, AOP를 이용해서 AccessToken에 대한 검증을 하게 되었다. 지금은 잘 나온다. 토큰 만료시("Token is expired") 토큰 일부러 이상하게 준 뒤 결과("Token is INVALID") 2. 본론 2-1. 발생한 문제 현재 JWT 관리를 어떻게 해야할지 고민 중이다. Redis를 이용해서 AccessToken이 만료될 때 어떻게 해야할지, 로그아웃 처리는 어떻게 해야할지 고민중이었다. 고민을 해결해나가기 위..