키자드에 등록된 총 243개의 포스트를 확인하실 수 있습니다.
2021 마이 블로그 리포트 2021년 당신의 블로그 스타일을 확인하고 네이버페이 GET하세요! campaign.naver.com
요즘 #NoCode 가 trend 되고 있는것 같습니다. #RPA , #workflow , #ETL , #스크레치 등등 #noCode 혹은 #LowCode 를 이용한 생산성 향상 툴 들이 많이 나옵니다. 이번 포스팅에서는 #azure (#애저) 에서 제공하는 workflow 인 #logicApps 에 대해 알아보겠습니다. no code 라서 코딩은 하나도 없으나 대신 마우스 클릭처럼 화면 조작이 엄청 많습니다. 그러므로 아래 동영상으로 학습하는걸 추천드립니다. https://youtu.be/YAhd21sB4Lc 우선 azure portal에 들어간 후 logic app 이라고 검색을 하고 logic app 하나를 생성합니다. 아래처럼 세팅할건 거의 없습니다. 단순 테스트 용도라서 consumption type을 선택했습니다. 이건 사용할때만 비용이 나가는 옵션이라서 혹시 모르고 리소스를 지우지 않았더라도 비용이 얼마 안나가니 좋습니다. reivew + create 를 클릭해서 리소스
#windows 용 #IntelliJ #Community 버전 설치 및 java 설정, 그리고 spring boot 프로젝트 생성 및 구동까지 해보겠습니다. 아래 사이트에서 community 버전(=무료버전)을 다운로드 합니다. ultimate 는 유료버전입니다. https://www.jetbrains.com/ko-kr/idea/download/#section=windows 다운로드 IntelliJ IDEA: 우수성과 인체 공학이 담긴 JetBrains Java IDE 최신 버전 다운로드: IntelliJ IDEA (Windows, macOS, Linux) www.jetbrains.com exe 파일 다운로드 후 클릭하면 설치가 완료됩니다. 그냥 클릭만 하면 됩니다. windows PC에는 당연히 java 가 설치되어 있어야 하고 JAVA_HOME과 PATH 설정도 해둬야 합니다.(당연히 아실거라고...) 자 이제 intelliJ 시작해보겠습니다. community 버전은 무료이므로
실무에서는 개발용, 운영용, QA용 과 같이 다양한 환경에서 spring boot 를 구동시킵니다. 따라서 각 환경에 맞는 application-{profile}.yml 파일을 만들어서 환경설정을 합니다. IntelliJ 에서 각 환경에 맞게 구동을 시키고자 할 경우 spring boot 의 active profile 을 설정해야 하는데 community는 무료버전이라서 유료버전과 약간 다릅니다. 정확히는 spring boot active profile 이라는 메뉴가 없고 vm option 설정을 통해 active profile을 설정해 줍니다. 사실 spring boot active profile 이라는 것도 vm option 으로 설정하는 것이긴 합니다. spring boot 를 한번 실행시켰으면 아래처럼 우측 상단의 콤보박스(?) 에 main 함수가 있는 클래스 이름이 나옵니다. 그걸 클릭하면 아래에 Edit configuration 이라는 서브 메뉴가 나오는데 그걸 클릭합니다
제목에는 spring boot 개발시 유용한 설정이라고 했지만 java 프로그램 개발시 동일하게 유용한 설정들이 되겠습니다. 1) 자동 import ObjectMapper mapper; <-- 이런식으로 코딩을 했을때, ObjectMapper 라는 클래스가 현재 설정된 의존성내에서 단 하나밖에 없다면, 즉 명확하다면 자동으로 import xxx.ObjectMapper; 라는 import 문을 넣어주는 기능입니다. 아래처럼 우측 상단의 설정 아이콘을 클릭하고 그 아래의 Settings 를 클릭합니다. 이후 아래처럼 Editor > General > Auto import 메뉴에서 Add unambiguous import on the fly 를 체크해주면 됩니다. 2) 사용하지 않는 import 문 자동 삭제 위 1번과 동일한 메뉴에서 Optimize imports on the fly 를 체크해주면 됩니다. 이러면 코딩 후 저장할때가 아닌, 코딩하면서 자동으로 import 문을 삭제해줍니
로컬이나 remote 에 설치된 RDB가 없을 때 간단한게 h2 DB를 spring boot 에서 내장 실행할 수 있습니다. 여기서 내장이란 따로 h2 를 설치할 필요없이 pom.xml 이나 build.gradle 에 의존성을 추가하는 것만으로 spring boot 실행시 h2 를 함께 구동시켜 주는 걸 말합니다. 내장 tomcat 이 spring boot 구동시 함께 구동하는 것과 같은 의미입니다. build.gradle 에 아래처럼 추가해줍니다. spring boot 에서 h2 에 대한 버전을 관리해 주므로 버전을 명시하지 않으면 spring boot 버전에 맞는 적당한 버전으로 설정이 됩니다. dependencies { (생략) runtimeOnly 'com.h2database:h2' } application.yml 에 h2 관련 설정을 해보겠습니다. 아래에 각 항목마다 주석을 달았기에 자세한 건 주석을 참조 하세요. spring: # h2 DB 는 개발용도로만 사용하고 운영에
spring boot 에서 JPA 사용시 application.yml 설정을 정리합니다. 각 항목별 상세한 설명은 각 라인별 주석을 넣었으면 참고하세요. spring: jpa: open-in-view: false # 디폴트 true 인데, 일반적으로 false가 맞음. transaction내에서만 영속성 상태유지 여부. hibernate: ddl-auto: create # 시작시 새로 테이블 생성함. 최초에만 create 로 하고, 그 이후는 none 으로 하면 생성된 DB를 지우지 않음. naming: # 엔티티 클래스명, 변수명을 실제 DB의 컬럼,테이블명으로 변환하는 규칙. implicit-strategy: org.springframework.boot.orm.jpa.hibernate.SpringImplicitNamingStrategy # 기본값 # 논리명을 실제 물리명으로 변환하는 규칙. ex) user -> usr physical-strategy: org.springframe
@Entity 클래스에는 @Setter 를 넣지 않습니다. 대신 별도의 set용 함수를 만들어서 set 을 호출하는 부분이 어디인지 확인 및 제어를 해야 합니다. 그래야 값이 마구마구 변경되는걸 막을 수 있고 디버깅시 해당 set 함수를 기준으로 찾으면 되기에 편합니다. 클래스에는 @Transactional(readOnly = true) 을 적어주고 write 가 필요한 함수에서만 @Transactional 을 적어줍니다. read 만 하는 할 경우 readOnly 를 사용하면 약간의 성능 향상이 될 수 있기 때문입니다. 클래스와 함수에 @Transactional 이 모두 들어가 있으면 함수에 있는게 우선순위가 높게 동작하므로 위와 같이 적는게 가능합니다. @GeneratedValue 를 사용합니다. "pk 변경할 일이 생겨서 일주일 정도 작업해야 합니다." 이런걸 1년에 한번 은 듣는것 같습니다. 절대 변경될 일 없을것 같으나, 우린 이미 그건 그저 희망사항일 뿐이라는걸 압니다.
아래 강의 내용중 핵심만 간추려서 정리합니다. https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8 스프링 핵심 원리 - 기본편 - 인프런 | 강의 스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런... www.inflearn.com #SOLID : 객체지향의 5가지 원칙. OCP 와 DIP 가 특히 중요 #SRP : 단일책임. 하나의 책임이라는게 모호한데, 수정이 필요할때 영향도가 적은것. 즉 적은 클래스만 변경할수록, 클래스내에서도 적은 함수들만 변경할수록 좋은 설계임 #OCP : 개방 폐쇄. 다형성을 통해 구현체의 확장/변경이 쉽고(=확장에 열려있고), 이를 이용하는 코드는 변경되지 않아야 한다.( =변경에는 닫혀있고) L
아래 강의 중 jsp, 타임리프 와 같은 view 를 제외하고 정리합니다. 최근에는 view 보다는 rest api 로 데이터만 내려주고, ui는 #react.js 와 같은 SPA 를 사용합니다. 그래서 admin page 용도와 같이 용도가 제한된 view 부분은 skip 합니다. https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의 웹 애플리케이션을 개발할 때 필요한 모든 웹 기술을 기초부터 이해하고, 완성할 수 있습니다. 스프링 MVC의 핵심 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니다., - 강의 소개 | 인프런... www.inflearn.com https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 -
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
보통 사내 시스템을 만들면 사내 SSO ( single sign on )가 이미 구축되어 있기에 이걸 이용해서 로그인처리를 하게 됩니다. 굳이 사내시스템이 아니더라도 같은 계열의 사이트이면, 한곳에서 로그인하면 나머지 사이트는 로그인 추가로 안해도 로그인이 되는 경우가 많습니다. 이 또한 SSO 를 이용했을 확률이 높습니다. 이번 포스팅에서는 sso를 위해 cookie 와 session 를 어떻게 사용하는지 알아보겠습니다. 쿠키와 세션에 대한 내용은 아래 유명한 노마드 아저씨의 영상을 꼭 보시기 바랍니다. 최고의 쿠키 세션 설명 영상입니다. https://www.youtube.com/watch?v=tosLBcAX1vk&t=8s 위 영상 봤다고 가정하고, 중요내용만 정리하겠습니다. 쿠키는 클라이언트(브라우저)에 저장되는 데이터입니다. 아래처럼 id,pw 를 넣어서 로그인시도 하고, 성공하면 서버에서는 Set-Cookie 라는 http 헤더에 쿠키값을 넣어서 리턴해줍니다. 쿠키는 key
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. servlet 개요 https://blog.naver.com/semtul79/222660730634 2. spring mvc 호출구조 https://blog.naver.com/semtul79/222661350643 3. controller 상세 정리 https://blog.naver.com/semtul79/222662125630 4. argument resolver, return value handler 그리고 message converter - https://blog.naver.com/semtul79/222664395210 5. validation ( 입력값 검증 ) 1/2 - https://blog.naver.com/semtul79/222667766751 6. validation ( 입력값 검증 ) 2/2 - https://blog.naver.com/semtul79/222669271920 7. filter 필터 - https://blog.naver.com/semtul79/2
1. spring boot + mybatis - 기본 설정/사용법 - https://blog.naver.com/semtul79/222687917255 2. spring boot + mybatis - parameterType, resultType , typeAlias - https://blog.naver.com/semtul79/222688684376 3. spring boot + mybatis - Transaction - https://blog.naver.com/semtul79/222689712876 4. spring boot + mybatis - log4jdbc-log4j2 - https://blog.naver.com/semtul79/222689762891 5. spring boot + mybatis - multi DB ( 여러개의 DataSource ) - https://blog.naver.com/semtul79/222689953891 #spring #boot 에서 #mybatis
1. spring boot + mybatis - 기본 설정/사용법 - https://blog.naver.com/semtul79/222687917255 2. spring boot + mybatis - parameterType, resultType , typeAlias - https://blog.naver.com/semtul79/222688684376 3. spring boot + mybatis - Transaction - https://blog.naver.com/semtul79/222689712876 4. spring boot + mybatis - log4jdbc-log4j2 - https://blog.naver.com/semtul79/222689762891 5. spring boot + mybatis - multi DB ( 여러개의 DataSource ) - https://blog.naver.com/semtul79/222689953891 지난 포스팅에 이어 mybatis 에 대해 좀
1. spring boot + mybatis - 기본 설정/사용법 - https://blog.naver.com/semtul79/222687917255 2. spring boot + mybatis - parameterType, resultType , typeAlias - https://blog.naver.com/semtul79/222688684376 3. spring boot + mybatis - Transaction - https://blog.naver.com/semtul79/222689712876 4. spring boot + mybatis - log4jdbc-log4j2 - https://blog.naver.com/semtul79/222689762891 5. spring boot + mybatis - multi DB ( 여러개의 DataSource ) - https://blog.naver.com/semtul79/222689953891 DB 작업을 하다보면 #Transaction
1. spring boot + mybatis - 기본 설정/사용법 - https://blog.naver.com/semtul79/222687917255 2. spring boot + mybatis - parameterType, resultType , typeAlias - https://blog.naver.com/semtul79/222688684376 3. spring boot + mybatis - Transaction - https://blog.naver.com/semtul79/222689712876 4. spring boot + mybatis - log4jdbc-log4j2 - https://blog.naver.com/semtul79/222689762891 5. spring boot + mybatis - multi DB ( 여러개의 DataSource ) - https://blog.naver.com/semtul79/222689953891 #mybatis 를 쓸 경우 아래처럼 appl
1. spring boot + mybatis - 기본 설정/사용법 - https://blog.naver.com/semtul79/222687917255 2. spring boot + mybatis - parameterType, resultType , typeAlias - https://blog.naver.com/semtul79/222688684376 3. spring boot + mybatis - Transaction - https://blog.naver.com/semtul79/222689712876 4. spring boot + mybatis - log4jdbc-log4j2 - https://blog.naver.com/semtul79/222689762891 5. spring boot + mybatis - multi DB ( 여러개의 DataSource ) - https://blog.naver.com/semtul79/222689953891 #spring #boot #mybatis 시리
#spring #boot 에서 각 http 요청별 데이터 저장을 위해 MDC 를 사용하는 방법. spring cloud sleuth 를 이용해서 로그 trace 하는 방법에 대해 사용법 및 원리를 알아보겠습니다. 우선 테스트를 위해 start.spring.io 에서 아래와 같이 프로젝트를 생성합니다. spring boot 버전, java 버전등은 각자 학습하는 시점의 적절한 것을 쓰면 무관합니다. MDC 는 동일 쓰레드 전용 map 자료구조를 제공합니다. 보통 http 요청이 오면 하나의 쓰레드가 할당되고, 그 쓰레드를 통해 #필터, #인터셉터 , #controller , #service , #mapper 등이 수행됩니다. 이런 여러 함수에서 공통으로 필요로 하는 데이터를 공유하려면 전역변수를 쓰거나 각 함수 호출시 파라미터로 넘겨줘야 합니다. 전역변수를 쓸 경우, 동시에 여러 쓰레드가 실행될 경우 데이터가 망가지므로 사용할 수 없고 각 함수 호출시 파라미터로 값 넘겨주려니 너무 귀
#spring #boot 에서 자주 사용되는 #design #pattern ( #디자인패턴 ) 에 대해 알아보겠습니다. 궁극적으로는 #AOP 와 AOP에서 사용하는 패턴을 설명하기 위한 선행 학습을 위한 포스팅입니다. 구체적으로 MyHttpClient 라는 클래스가 있다고 합시다. 이 클래스는 이름처럼 HTTP 요청을 보내는 client용 라이브러리입니다. 이 라이브러리에는 HTTP 요청시 기본적인 HTTP 헤더 세팅 및 로깅 등 있어야 할 기능들이 모두 구현되어 있습니다. 그러나 예외처리는 실제 사용하는 쪽에서 구현하도록 만들지 않았다고 합시다. 즉 retry를 할건지, 그냥 무시할건지 , 예외를 throw 할건지 등등은 "난 모르겠으니 알아서 해라" 라고 했다고 합시다. 이에 대한 방법은 아래와 같습니다. 첫번째 방법. 상속 - 템플릿 메서드 패턴 public abstract class MyHttpClient { protected abstract void handle(); //
#spring #boot 의 #AOP 는 #프록시패턴 을 이용해서 원본 로직 수행 전후에 로직을 넣습니다. AOP 설명에 앞서 프록시패턴에 대해 알아보겠습니다. #proxy 라는 말은 web 환경에서 많이 들어봤을 겁니다. 원본 사이트의 내용을 cache 하여 proxy 사이트를 여러개 만들어서, 원본 사이트에 접근하는게 아니라, 지리적으로 가까운 proxy 서버로 접속하여 빠른 속도를 보장합니다. 이렇게 사용자 가까운 곳에 위치한 걸 proxy 라고 말하며 사용자 -- 인터넷 -- web server(apache) --- was ( tomcat ) 에서 web server 를 reverse proxy 라고 부릅니다. 사용자를 위한게 아니라 was 를 위한 proxy 라는 뜻이어서 reverse proxy 라고 부릅니다. 암튼 중요한건 이렇게 원본 + proxy 형태로 구성되어 있습니다. 그리고 모든 요청은 원본에게 바로 가는게 아니라 proxy 를 거친다는 겁니다. 중요! 개념은
#spring #boot #AOP 에 사용되는 proxy 기술 전반에 대해 다뤄보겠습니다. #reflection 에 대해 우선 알아봅시다. reflection 은 C/C++ 의 포인터처럼 막강한 기능을 제공합니다. 그만큼 잘못쓰면 디버깅도 어렵다는 말이기도 합니다. 일반적인 application을 개발할때는 리플렉션을 쓸 이유가 없습니다. 만약 쓰고 있다면 정말 이게 필요한건지 생각해봐야 합니다. 보통은 프레임워크와 같이 어떤 app 과 함께 쓰일지 모르는 상황에서 유연하고 동적인 처리를 위해 리플렉션을 사용합니다. test 클래스 하나에 아래 코드들을 넣어서 테스트 해보겠습니다. // 어노테이션 여부에 따라 동작을 다르게 할것이라서 임의의 어노테이션 생성 @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) static @interface MyAnnotaion { } 위와 같이 임의의 어노테이션을 하나 만들었습니다. 쓰임
이번 시간에서는 인터페이스 없이 구체클래스만 있는 경우 #CGLIB 이라는 오픈 소스를 이용해서 proxy 를 만드는 방법에 대해 알아보겠습니다. 동적 jdk 프록시에는 아래 인터페이스를 이용해서 프록시를 만들었습니다. CGLIB 에서는 아래 인터페이스를 이용합니다. 패키지명을 보니 springframework 의 것입니다. 원래는 오픈소스인데 스프링에서 내장시켰습니다. 그래서 따로 의존성을 넣을 필요가 없습니다. 메서드의 모양이 동적 jdk 프록시와 유사합니다. 파라미터로 수행할 함수 정보를 받아오고 실행결과를 Object 타입으로 리턴합니다. 즉 템플릿콜백 패턴과 유사하게 파라미터를 통해 수행할 함수 정보를 받아오는 방식입니다. 스프링에서는 CGLIB 을 직접 사용해서 프록시로 만들 필요가 없습니다. 편리하게 사용하라고 #ProxyFactory 를 제공해주고 있고 이걸 통해서 동적 JDK 프록시나 CGLIB을 통한 구체클래스 프록시를 모두 만들 수 있기 때문입니다. 여기서는 사용
인터페이스 기반 동적 JDK 프록시와 구체 클래스기반 CGLIB 에 대해 알아봤습니다. 인터페이스 기반 클래스는 동적 JDK 프록시를 써야 하고, 구체 클래스만 있는 경우는 CGLIB 를 써야 했습니다. 즉 if ~ else 처럼 클래스를 확인하고 필요한 기술(라이브러리)을 써야 했습니다. 스프링에서는 #ProxyFactory 라는걸 제공해서 이 클래스가 원본 target 을 확인하고 스스로 동적 JDK 프록시 혹은 구체 클래스기반 CGLIB을 이용해서 proxy 를 만들어줍니다. ProxyFactory 에서는 아래 인터페이스를 이용합니다. CGLIB 때와 같은 이름의 인터페이스이나 패키지명이 다릅니다. aop 어쩌구 저쩌구 클래스입니다. 앞의 포스팅을 쭉 봤다면 이젠 보자마자.. "대충 알겠음" 이라는 생각이 들겁니다. 아래와 같이 구현합니다. 이전과 다르다면 원본 target 을 생성자 주입받았는데 여기서는 그 부분이 없습니다. invoke() 라는 메서드의 파라미터로 원본 ta
이전 포스팅에서 #ProxyFactory에 대해 알아봤는데 #AOP 에서 자주 사용하는 #pointcut, #advice, #advisor 에 대해 좀 더 알아보겠습니다. pointcut : 포인트컷, 대상 클래스 / 대상 메서드 즉 프록시를 적용할 대상을 뜻합니다. advice: 어드바이스, 프록시 코드를 뜻합니다. 즉 캐시, 로깅 등 프록시 용도로 추가한 코드를 뜻합니다. advisor: 어드바이저, pointcut + advice 를 묶어서 advisor 라고 합니다. 어디에 어떤 코드를 넣을지 .. 이렇게 "어디에.. " 와 "어떤 코드를... " 이 조합되어야 프록시가 완성되므로 역할에 맞게 용어를 분리하였고 하나로 뭉쳐야 실제 의미가 있으니 뭉친걸 advisor 라고 합니다. 지난 포스팅에서 ProxyFactory 를 통해 프록시를 만들었는데, 프록시는 프록시 메서드가 아니가 아니라 프록시 클래스 입니다. 즉 클래스 단위로 만들어집니다. 만약 OrderService 라는
proxy 사용시 원본 target 과 proxy 객체, 이렇게 2가지가 생성됩니다. proxy는 빈에 등록되어야 하고 원본 target 은 new 로 생성만 되어야 하지 빈으로 등록되면 안됩니다. 직접 수동으로 target 은 new 로 생성만 하고 , proxy 는 빈으로 등록하고... 식으로 구현할 수도 있으나 spring 에 등록되려는 모든 빈 들중에서 proxy 대상이 되는 빈만 골라서 proxy 를 new 하고 이를 빈으로 등록해주는 작업을 해주면 좋겠습니다. 즉 생성된 객체가 빈으로 등록되기 직전에 그 객체 대신 proxy 객체를 빈으로 등록해주는(=바꿔치기하는) 기능이 있습니다. BeanPostProcessor 라는 인터페이스가 있는데 이걸 구현하면 spring boot 에서 빈들이 등록되기 전을 후킹해서 뭔가 처리를 해줄수 있습니다. 아래처럼 BeanPostProcess 를 implement 한 클래스를 빈으로 등록해줍니다. import lombok.extern.sl
이전 포스팅에서 Advisor 를 직접 빈으로 등록하면 AnnotationAwareAspectJAutoProxyCreator 라는 빈후처리기가 proxy 로 등록해주는걸 알아봤습니다. 스프링에서는 이 방식보다 더 편리한 @Aspect 라는 어노테이션을 통해 proxy 를 적용할 수 있습니다. 간단히 그림으로 아래처럼 표현할 수 있습니다. <출처: 인프런 - 김영한 강사님의 스프링 핵심원리 - 고급편 교재 > 위와 같이 @Aspect 라고 클래스에 적어주면 빈후처리기에서 "이 클래스의 코드를 기반으로 advisor 를 만들어야 겠다" 라고 판단하고 advisor를 생성하고 proxy 까지 생성해서 빈으로 등록해줍니다. 코드로 한번 알아보겠습니다. 기존에 만든 Advisor 등의 proxy 코드들은 주석처리 혹은 삭제등을 해주세요. @Aspect 라고 적어줘야 빈후처리기에서 Advisor 및 proxy 생성을 해줍니다. 빈후처리기에서 처리되려면 빈이어야 합니다. 따라서 @Componen
app을 개발하다 보면 "아~ 여러군데에서 같은 코드가 실행될 곳이 많네. 함수를 하나 만들고 이걸 필요할때마다 호출하도록 해야지.." 라는 생각이 들때가 많습니다. 상세코드 복붙보다는 함수로 하나 만들고 함수호출 코드만 복붙하는게 좀 나은 방법이긴 합니다. 그러나 여러 메서드의 실행시간을 로깅하고 싶을 경우, 위 방법으로 하면 메서드 앞부분에 시작시간용 코드, 메서드 뒷부분에 시간계산용 코드, 이렇게 2군데 넣어야 합니다. 게다가 예외가 발생해도 일괄되게 동작하려면 try ~ catch 도 넣어야 합니다. 이런 어려움이 있으며 이를 해결하기 위해 나온 것이 #AOP 입니다. < 출처: 인프런 - 김영한 강사님의 스프링 핵심원리 - 고급편 교재 > 위와 같이 별개의 클래스들이지만 공통적으로 로그 추적 로직을 넣고 싶을때, AOP 를 이용하면 이런 횡단 관심사 부분에 공통 로직을 적용할 수 있습니다. OOP 에서 부족한 부분을 AOP를 통해 보조/보완 해줄수 있게 되었습니다. AOP
이제 실제 spring boot 에서 #AOP 를 구현하는 방법에 대해 알아보겠습니다. 가장 간단한 형태는 아래와 같습니다. @Aspect 를 넣어서 advisor 대상임을 표시하고 @Component를 통해 빈으로 등록합니다. @Around 를 통해 pointcut 을 지정해주고 바로 아래 메서드를 통해 advice 를 정의합니다. @Slf4j @Aspect @Component public class LogAspect { @Around("execution(public * dev.developery.mdc.reflection..*(..))") public Object advice(ProceedingJoinPoint proceedingJoinPoint) throws Throwable { StopWatch sw = new StopWatch(); sw.start(); ////// 여기가 원본 target ////////// Object result = proceedingJoinPoint.
AOP 적용 지점을 가리키는 #포인트컷(#pointcut) 을 실습을 통해 자세히 알아보겠습니다. 아래와 같이 의존성을 넣어줍니다. <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency> 포인트컷 테스트를 할 인터페이스를 아래처럼 하나 만듭니다. package me.test.intellij.service; public interface TestService { String dummyMethod(String name); } 위 인터페이스를 implement 한 클래스도 하나 만듭니다. package me.test.intellij.service; import org.springframework.stereotype.Service; @Service public class TestServiceImpl implements TestServ
#spring #boot #proxy 기술 시리즈 마지막 편입니다. #AOP 를 활용해서 사용되고 있는 실제 기술들, 그리고 실제로 쓸만한 AOP 예제, 마지막으로 제약사항에 대해 알아보겠습니다. #Retryable 이라는 어노테이션이 있습니다. 이걸 통해 특정 메서드에서 exception 발생시 여러번 retry 해주는 어노테이션입니다. AOP 설명을 위해 @Retryable 사용법을 잠시 살펴보겠습니다. 아래처럼 retry 하고 싶은 메서드에 @Retryable 을 적어두고 value 에 retry 대상 Exception 을 적어줍니다. 대상 메서드를 보니 현재 시간(ms)이 5의 배수이면 성공, 그외이면 RuntimeException을 발생하도록 했습니다. retry 되는걸 봐야 하므로, 확률적으로 80% 예외가 날라가게 해두었습니다. import lombok.extern.slf4j.Slf4j; import org.springframework.retry.annotation.En
이제 프록시 기술의 한계점에 대해 알아보겠습니다. JDK 프록시와 CGLIB 프록시.. 이렇게 2가지 방법이 있으며 spring boot는 기본적으로 CGLIB 프록시를 이용합니다. 만약 JDK 동적 프록시를 쓰고 싶다면 아래처럼 proxyTargetClass 에 false 로 세팅하면 됩니다. ( 이 부분은 이전 포스팅에서 모두 다루었던 내용입니다. ) Retry target = new Retry(); ProxyFactory proxyFactory = new ProxyFactory(target); proxyFactory.setProxyTargetClass(false); // 여기를 false 로 세팅하면 JDK 동적 프록시로 생성 Retry retryProxy = (Retry)proxyFactory.getProxy(); JDK 동적 프록시는 인터페이스 기반으로 동작합니다. 만약 아래 4번째 코드처럼 프록시객체를 인터페이스가 아닌 구체 클래스로 타입 캐스팅을 하면 Exception
yes24 에서 아래처럼 꽤 인기있고 평이 좋은 #소프트웨어 #아키텍처 서적에 대해 후기 + 내용 요약을 해보겠습니다. 한줄 후기 일반 개발자입장에서 아키텍트에 대한 이해를 할 수 있었고, 언젠가 될수도 있는 아키텍트 라는 role 을 위해 어떤 걸 준비해야 하는지, 이런 저런 기술을 깊게 아는게 전부가 아닌 기술을 넓게 알고, 인간관계와 같은 비 기술적 요소도 점점 중요해져 가는걸 알게되었습니다. 개인적으로 여전히 "좁지만 깊게 알아야 하는" 일반 개발자가 좀 더 매력적으로 느껴지지만, 시간이 흐르면서 자연스레 아키텍트쪽으로 더 많은 관심이 가져지지 않을까 생각해봅니다. 아래부터는 제 기준에서 중요하거나 복습(?)에 도움된다고 생각되는걸 요약했습니다. 책내용+개인생각을 적었기에 일부 잘못된 내용이있을수도있습니다 기술도 중요하나 대인관계/처세술도 필요하다 아키텍트에게 필요한 것은 다양한 경험을 쌓아왔고, 최신 트렌드를 잘 알고, 아키텍처를 잘 분석할줄 알고, ... 와 같은건 사실
spring boot 에서 #http #basic #authentication 을 적용하고 #react, vue 와 같은 #frontend 에서 #axios 등으로 json 형식의 body를 http request 를 보냈을때 CORS 에러가 나는 원인과 그 해결책에 대해 정리합니다. #CORS 는 너무나 유명하니 구글에서 CORS 라고 검색하면 자세하게 나오니 그걸 참고하시고 spring boot 에서 http basic authentication 적용하는 것도 구글링하면 차고 넘기게 나오니 그걸 참고하세요. 이번 포스트에서는 react, vue 와 같이 spring boot 에서 제공하는 ui 가 아니라, 별도 서버 혹은 프로세스에서 제공되는 ui 에서 spring boot로 HTTP request 를 보낼 경우 CORS 문제가 발생하는데, 이렇게 인증 + CORS 가 복합된 것에 대해 해결하는 방법에 대해 기술합니다. axios 같은 javascript의 http 라이브러리에서