Error/트러블슈팅

[JAVA] ENUM에 setter를 쓰면 생기는 일 (feat. 싱글턴)

⚠️운영 환경에서 Java enum의 상태 변경으로 인한 문제 발생Java에서 enum을 사용하여 미리 메시지를 설정해두고, 해당 메시지가 동적으로 변경되는 로직이 있었다. 그러나 운영 환경에서 간헐적으로 이상한 메시지가 내려가는 문제가 발생하였다. 👌문제찾기Issue에 사용자가 이상한 오류 메시지를 받는 문제가 있었다.간헐적으로 비정상적인 Validation 오류 메시지가 사용자에게 반환되었다. ex) 비밀번호를 입력해주세요 -> 잘못된 아이디 입니다처음에는 해당 메시지가 어디서 오는지 찾고 있었지만, 외부 API에서도 코드에서도 해당 메시지를 발견할 수 없었다. 하지만 DB에 특정 오류 상황에 해당 메시지가 저장되는걸 발견했지만, 해당 API에서 메시지가 변경되는걸 확인할 수 없었다.그렇다면 원인은..

2024. 12. 10. 20:16
Error/개발환경

[ElasticSearch] Spring data elasticSearch 인증 관련 오류 해결

개요엘라스틱 서치 환경을 구축하고, Spring Data Elasticsearch를 연결하는데 문제가 발생하였다.그 이유는 바로 로컬에서 테스트 할 때 와는 다르게 실서버에서는 인증(https, 인증서, Authorization)이 필요했다.하지만 해당 객체를 통해 해결할 수 있다는 기본적인 설정이 있었지만 https와 cert 인증서를 포함하여 Authorization을 모두 포함하는 코드는 찾아볼 수 없었다. 결국 하나씩 디버깅을 해가며 원인 분석을 한 내용을 공유하고자 한다.추가로 Spring data Elasticsearch는 처음 bean이 컨테이너에 생성되면서 handshake를 하게 되는데 이때 elasticsearch의 health를 하게 되는데 네트워크 in/out bound도 확인해야 ..

2024. 9. 6. 18:55
Study/Next Step

[Next Step] ATDD, 클린 코드 with Spring 8기 3주차 리뷰

🎈 테스트와 의존 의존은 무조건 나쁜가에 대해서 이야기했다. 물론 답은 아니다. 의존이 없으려면 하나의 객체가 모든걸 다 처리해야하고, 변경 요구사항이 발생할 때 복잡해진다. 이를 위해서 적절한 범위로 책임을 나누는게 좋고, 불필요한 의존 대상은 정리해야한다. 🔎 테스트와 관련한 궁금증 1.통합 테스트인 경우 외부 라이브러리를 테스트해야 할까? 외부 라이브러리의 기능을 검증할 필요는 없다. 하지만, 그 부분을 활용하는 로직에 대한 검증은 필요할 수 있고, 외부 라이브러리는 변경할 수 없으니 실제 객체를 활용하는게 좋다. 의존성 테스트를 할때는 실제 외부 의존성을 사용하거나, Stub 혹은 Fake로 대체하자. ❤️ 3주차 후기 외부에 의존하는 인수 테스트 미션을 통해 외부 의존성에 대한 고민을 했던 것 ..

2024. 3. 5. 19:13
Error/트러블슈팅

[Trouble Shooting] Spring boot 중복 파일 업로드시 file not found에러 발생

오늘은 프로젝트를 진행하며 겪었던 파일 업로드 관련 에러를 말해보려고 한다. 프론트단에서 아래와 같은 여러개의 파일을 업로드를 구현했을때, 백엔드에서 동일한 파일 저장시 file not found에러가 발생하는 문제가 생겼다. (왜 저장이 안되는거지?) 파일1 파일2 파일3 파일4 const fileInput = document.querySelector('input[name="uploadFile"]'); const uploadButton = document.querySelector('#uploadButton'); uploadButton.addEventListener('click', function() { const files = fileInput.files; const formData = new Form..

2023. 4. 26. 22:14
Languege/Java & Spring

[Spring Framework OPEN API서비스 교육] 1.API KEY란?

[API KEY] 특징 - 인증(X) : 식별만 수행한다. - 목적 : 통계와 사용량 제한 - 공용 데이터 조회시에 주로 사용 사이트 단위로 접근 허용 - 사용자별 로그인을 하지 않아도 접근 가능한 페이지에 적용 가능 - 1일 사용량 제한하는 경우가 많음 서명 키 없이 API KEY와 사이트 URL을 이용해 접근 제한이 가능하다. 1.클라이언트 개발자는 Provider에 hostName 및 기타 정보를 이용해 API KEY를 요청한다. 2.Provider는 API KEY를 생성하고 hostName 및 기타 정보를 DB에 저장하고 , API KEY를 발급한다. 3.클라이언트 개발자는 해당 API KEY를 통해 데이터를 요청한다. 4.Provider는 API KEY & Origin을 Validate하고 성공..

2022. 10. 4. 15:41