관련 게시물[디자인 패턴] 프록시 (Proxy)[Java] 프록시를 언제 생성할까? 원래 노션에 작성되어 있는 글은 Java 프록시 페이지 하나로 되어 있었다.근데 공부하다 보니 점점 양이 불어나기 시작하더니 그렇게 되었다. 앞전에서는 자바와 관련된 프록시 개요, 프록시가 어떻게 생성되는지에 대해 알아보았다.이번에는 진짜 목적이었던, 프록시 생성 방식에 대해 작성하고자 한다. 자바에서는 동적 프록시 생성 방식이 크게 두 가지가 있다.JDK Dynamic Proxy와 CGLib, 이 두 종류이다.JDK Dynamic Proxy인터페이스 기반 동적 프록시특징인터페이스 상속 기반객체 자체가 아닌 인터페이스와 Reflection API를 이용하여 프록시 객체 생성Target의 구현체를 상속하는 것이 아닌, ja..

진짜 이거 공부하는 데 시간이 얼마나 걸린지 모른다...물론? 내 나태함도 한 몫 했겠지만 많은 일들이 있었기 때문...관련 글[디자인 패턴] 프록시Java에서 프록시를 구현하는 방법정적 프록시일반적으로 정적 프록시는 코드를 직접 작성하여 프록시를 구현한 것이다.위의 [디자인 패턴] 프록시 게시물에서 작성했던 예제와 같은 내용을 생각하면 된다.// 대상 객체public interface TargetObject { String printMethod(String name);}// 대상 객체 구현체 (본체)public class TargetObjectImpl implements TargetObject { @Override public String printMethod(String name) { re..

트러블 슈팅을 하다가 어떻게 여기까지 왔나 모르겠는데, 여하튼 그렇게 되었다. 프록시 (Proxy)대리, 대리인단어의 의미만 보아도 짐작 가능하겠지만, 누군가를 대신해 그 역할을 수행하는 존재를 일컫는다. 현실 세계에서 누군가가 대리인을 두고 일처리를 한다는 것은, 굳이 본인이 아니어도 처리가 가능한 일들에 대해서는 대신 처리할 수 있도록 조치해 두었음을 의미한다. 혹은 법률 대리인처럼, 전문적인 분야에서 나 대신 더 효율적이고, 효과적으로 관련 업무를 처리할 수 있도록 하거나. 물론, 본인이 책임을 져야 하는 중요한 안건들은 대리인 측에서 "OO님, 와서 좀 보셔야 할 것 같습니다." 하고 연락할 것이다. 그제서야 본체는 이 무거운 엉덩이를 떼고 움직이면 된다. 객체 또한 그러하다, A 객체가 하는 일..

사실 이전까지는 자바의 버전 별 특징에 대해 크게 생각해 본 적이 없었던 것 같다.나는 언제나 새로운 버전을 썼고, 일단 자바는 최소 JDK 17 이상으로 썼었으니... 막 불편함을 느끼거나 하지 않았다. 생각을 해 보면 언제나 귀찮음을 느끼고 왜 이러지? 왜 이럴까? 왜 이렇게 생겨먹은거지? 하는 생각을 할 때마다 많은 것들을 배워갔기에 기왕 이렇게 생각이 들었으니 알아보지 뭐~ 라는 생각으로 버전 별 특징을 알아보기로 했다. 이번에 든 생각은 왜 이러지? 보다는 면접 준비나 이런거 할 때마다 자바 버전별 특징에 대해서는 알아두는 것이 좋다고 들었었고 겸사 겸사 어떤 차이가 있을까 살펴보기 위해서 훑어보다가 위의 '그' 질문, 왜지? 가 떠오르게 되었다. Java SE Support Roadmap에서 ..

이번에 프로젝트 리팩토링을 하면서, 개선하게 된다면 오류가 많이 일어날 것이라 생각했다. 그래서, 디버깅 등이 좀 더 편리하게 될 수 있도록 하고 싶다고 생각했다.디버깅하면 바로 생각나는 부분은 로깅이었고, 그래서 로그 관련된 부분을 개선해보고자 했다.프로젝트는 단순히 @slf4j를 이용하여 로그를 찍는 정도였고, 원래 리팩토링 계획은 그냥 스프링에서 제공해주는 logback을 통해 만들려고 했었다.하지만 찾아보니 Log4j2 등 다양한 프레임워크가 존재하여 조금 정리해보고자 한다. 로깅 (Logging)시스템 동작 시 시스템의 상태와 작동 정보를 시간에 따라 기록하는 것 왜 로깅을 하나요?애플리케이션에서 문제 발생 시, 원인 분석을 위한 정보로 활용하기 위함프로그램의 실행에 대한 흐름과 문제 확인 가능..

로그 관련 정리를 하다 이거도 집어 넣을까 했는데, 한 번에 넣기에는 너무 많아질 것 같아서 따로 글을 작성했다.로깅 프레임워크를 몰랐을 때, 나는 디버깅을 위해서 println()으로 확인하고자 하는 부분을 찍었었다. 바로 println을 로깅용으로 사용하는 것은 지양해야 한다는 피드백이 들어왔었다.그 당시에는 로그는 출력 레벨이 있어, 문제 상황을 더 확실하게 파악할 수 있다는 점, 저장되지 않는다는 점 정도로 생각했지만 찾아보니 이유가 더 있었다. 1. 휘발성파일로 저장되지 않음 로깅을 하는 이유는 뭔가 이슈가 발생하는 등의 상황에서 시스템 활동 정보를 보고 어떤 상황이고 어떤 조치가 필요할 지 파악하기 위함이다.그러기 위해서는 로그 파일을 봐야 한다. 그런데 sout은 터미널 혹은 콘솔에만 출력될..

레포지토리를 fork해서 활용하려고 하는 도중, 문제가 발생했다.더 이상 진짜 미룰 수 없어서 리팩토링을 하려고 내 fork한 프로젝트를 가지고 실행이 잘 되는지 해 보았다. 외부 API는 정말 변수가 많다.그런데 내가 기존에 사용했었고, 내가 발급한 날씨 예보 API인데 실행이 되지 않는 것이다!!!왜 안되나 곰곰히 생각해보다, 일단 내가 API를 발급받은 공공데이터포털에 들어가서 확인해보기로 했다.그리고 내게 다가온 것은 아래와 같았다.국가정보자원관리원 대전센터 화재로 인하여 공공데이터포털 또한 사용할 수 없는 상태가 된 것이다.그렇기 때문에 공공데이터포털에서 발급받은 나의 날씨 예보 API가 사용할 수 없는 상태에 놓인 것이다.저곳의 NIA 공지사항의 대체 사이트 전달 게시물을 통해 API를 개선..

fetch와 pull은 모두 변경 사항을 가져올 때 사용하는 명령어이다.이 두 명령어의 차이에 대해 알아보기로 했다. 너무 깊게는 말고 간단하게!git fetch원격 저장소의 최신 상태(이력) 만을 가지고 오는 것특징업데이트 한 사항들을 가져와 상태만 동기화 시킴안전하게 원격 저장소의 상태를 로컬에서 확인할 수 있다.git pull원격 저장소의 최신 상태(fetch)를 대상 브랜치로 자동 병합(merge)fetch + merge 라고 생각하면 편하지 않을까 싶다.특징병합 시 충돌이 발생하면 발생한 부분을 주석으로 표시해 충돌이 난 부분을 알려준다.그러면 이를 수동으로 해결하면 됨!나의 생각사실 나는 git pull을 많이 사용했다.이전에도 이에 대해 공부를 좀 했었는데, 사실 fetch가 가장 안정적인 ..