전체 글 (42) 썸네일형 리스트형 Cglib dynamic proxy 원래는 서드파티였으나 지금은 스프링이 기본으로 사용하는 방식 바이트코드를 조작는 방식이며 구체클래스 기반으로 동작한다. jdk dynamic proxy와 다르게 인터페이스가 필요하지 않으나 상속을 통해서 사용하다보니 class에 final이 붙은것은 프록시처리를 하면 예외가 발생한다 메소드도 마찬가지 그 외에 특이점은 인자에 들어있는 Method.invoke를 사용하기보단 MethodProxy를 통한 하용을 추천한다는 점 (성능상 이점이 있다고 한다.) import lombok.extern.slf4j.Slf4j; import org.springframework.cglib.proxy.MethodInterceptor; import org.springframework.cglib.proxy.MethodProxy.. JDK Dynamic Proxy 프록시를 관리할 떄 직접 target클래스를 상속받은 클래스를 만들 수 있으나 만약 만들어야할 프록시 클래스가 매우 많다면 마찬가지고 중복코드가 가득한 클래스가 많이 만들어지게 된다. 어차피 동일한 로직이 수행되는 프록시라면 Java의 Reflection을 이용해서 프록시를 동적으로 생성할 수 있다. Java에서 제공하는 동적 프록시를 이용해서 만들 수 있는데 JDK Dynamic Proxy는 인터페이스 기반으로 프록시 클래스를 만들어 준다. java.lang.reflect.InvocationHandler 인터페이스를 상속받아 클래스를 구현해서 invoke 부분을 작성하면 해당 프록시가 적용된 모든 인터페이스 기반 프록시에 invoke가 동작하게 된다. import lombok.extern.slf4j.S.. 인터페이스 기반 vs 구체 클래스 기반 프록시 프록시 패턴은 인터페이스 기반과 구체클래스 기반 모두 가능한데 인터페이스 기반의 단점은 매번 인터페이스를 생성해야 한다는 점 구체클래스기반의 단점은 불필요한 상속코드 super(null)을 작성해줘야 한다는 점 실무에서는 구체클래스 기반으로 많이들 쓴다. 실제로 인터페이스 기반 설계처럼 인터페이스 : 구현체가 1:N이 아니고 1:1인경우가 많아서 구체클래스 하나만 구현하는 방식이 널리 이용됨 이론상으로는 인터페이스 기반으로 가는게 맞으나 실용적으로는 꼭 그럴 필요는 없을 것 같다. 프록시 패턴 & 데코레이터 패턴 중요 구현체는 거의 비슷 프록시 패턴은 클라이언트 > 프록시 > 서버 데코레이터 패턴은 클라이언트 > 데코레이터 > 서버 클라이언트 > 데코레이터1 > 데코레이터2 > 서버 으로 유사하지만 의도가 다르다 프록시패턴은 접근에 대한 제어 호출부분에 값이 있거나 없거나 혹은 접근이 가능하거나 불가능하거나에 따라서 실제객체를 호출할지 혹은 프록시에서 이미 기억하고있는 처리를 할것인지에 대한 부분을 구현한다 데코레이터패턴은 호출부분에 결과값을 더한다던가 뺀다던가 혹은 다른 부가기능을 추가한다던가 해서 사용하는데 여러 데코레이터를 연속적으로 호출하게끔 하는 의도를 가진다. 중요부분 클라이언트는 서버에게 요청할 때 서버의 구현체에 의존하지 않고 인터페이스에만 의존하게 구현후 각 프록시와 데코레이터를 서버의 인터페이스.. 프록시 프록시의 개념은 클라이언트 > 서버 모델(요청주체 > (요청) > 요청이행자의 개념)에서 클라이언트가 서버에 직접적으로 요청을 하는 경우와 비교해 중간에서 요청을 대신 처리해주는 주체를 말한다 클라이언트 > 프록시 > 서버 의 형태로 변형되며 요청의 흐름에는 큰 변화가 없다 클라이언트는 요청이 어떻게 되는지 내부적인건 몰라도 내가 요청한거를 원하는 결과대로 받음 이런 프록시를 사용하는 패턴은 프록시 패턴과 데코레이터 패턴으로 나뉘는데 프록시 패턴은 요청에 대한 접근을 제어하는 데 주로 쓰이고 데코레이터 패턴은 요청에 부가적인 기능을 추가하는데 주로 쓰인다. 템플릿 메소드 패턴 부모클래스(추로 추상클래스)를 만들고 자식클래스를 만들어서 부모클래스의 필요한 부분만 재정의해서 사용하는 방식 변하는 코드에 집중할 수 있지만 부모클래스를 상속받아야 하는 단점을 그대로 유지한다. 즉, 부모클래스의 안쓰는 많으 부분도 가져가야 하는 셈 추가로 클래스를 매번 만들거나 익명클래스를 작성하는 부분도 단점이다. AWS Elastic Beanstalk + Java SE환경 API 서버 구축기 (3) AWS Elastic Beanstalk에 Java SE 플랫폼 기반으로 API 서버를 구축한 기록입니다 (2022.08.13 -Xms 관련 명령서 순서 변경을 확인해서 해당글에서 수정했습니다.) 아래와 같이 총 3가지 상황에 따른 구축 방법과 주의할 점에 대한 글로 나누어 작성할 예정입니다. 1편 실행 가능한 단일 JAR 2편 Procfile 기반 3편 Procfile 기반 다수 JAR + Arguments + ebextentions NGINX Reverse Proxy 설정 이번 포스팅에서 다룰 내용은 여러 JAR를 하나의 인스턴스에 배포해서 내부에서 location 기반으로 proxy 하는 방법을 소개할까 합니다. 이전 글에서 Procfile로 foo.jar를 실행하는 방법을 말씀드렸는데 이번 글에서는.. AWS Elastic Beanstalk + Java SE환경 API 서버 구축기 (2) AWS Elastic Beanstalk에 Java SE 플랫폼 기반으로 API 서버를 구축한 기록입니다 (2022.08.13 -Xms 관련 명령서 순서 변경을 확인해서 해당글에서 수정했습니다.) 아래와 같이 총 3가지 상황에 따른 구축 방법과 주의할 점에 대한 글로 나누어 작성할 예정입니다. 1편 실행가능한 단일 JAR 2편 Procfile 기반 3편 Procfile 기반 다수 JAR + Arguments + ebextentions NGINX Reverse Proxy 설정 이번 포스팅에서 다룰 내용은 Procfile 기반 실행 가능한 단일 JAR + Arguments입니다. 앞서 1편에서는 JAR 하나만 간단하게 배포했었고 포트는 환경변수로 수정해 봤습니다. 실제 운영환경에서는 저렇게 간단하게 하지 않고.. 이전 1 2 3 4 5 6 다음
