기록

request 스코프 예제 개발 동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다. 이럴때 사용하기 딱 좋은것이 바로 request 스코프이다. 다음과 같이 로그가 남도록 request 스코프를 활용해서 추가 기능을 개발해보자. [d06b992f...] request scope bean create [d06b992f...][http://localhost:8080/log-demo] controller test [d06b992f...][http://localhost:8080/log-demo] service id = testId [d06b992f...] request scope bean close 기대하는 공통 포멧: [UUID][requestURL] {message} UUI..

ObjectFactory와 ObjectProvider가 있는데 ObjectProvider가 ObjectFactory를 상속 받고 있고 ObjectProvider가 기능이 더 많아서 이걸 사용한다. 사용법 @Autowired private ObjectProvider prototypeBeanProvider; public int logic() { PrototypeBean prototypeBean = prototypeBeanProvider.getObject(); prototypeBean.addCount(); int count = prototypeBean.getCount(); return count; ObjectProvider객체로 getObject()를 해주면 항상 새로운 프로토타입 빈이 생성된다. Object..

1.보안성 쿠키를 전달하지 않아도 된다. 기존보다 보안성을 조금 더 높일 수 있다. 중간에 누군가 토큰을 탈취하지 못하게 토큰 만료시간을 적게 설정할수있다. 유효시간이 끝나면 새로운 Access Token을 발급 받는다. 2.무상태 & 확장성 세션을 사용한다면 세션이 저장되어있는 서버로 요청을 해야하는데 서버를 옮기거나 서버가 죽는다면? 토큰은 이런 문제를 해결 할 수 있다. 3.Access Token 과 Refresh Token Access Token은 보안성을 높이기 위해 만료 시간을 설정해 놓았다. 토큰 사용기간을 길게 잡으면 보안에 좋지 않고, 보안상 만료 시간을 짧게 해놓으면 그 만큼 사용자가 자주 로그인을 해서 새롭게 Access Token을 발급 받아야하는 번거로움이 있다. 그래서 나온게 R..

생성자 주입을 선택해라! 그 이유는 예전에는 수정자 주입과 필드주입을 많이 사용했지만 최근 스프링에서는 생성자 주입을 권장한다. 그 이유는 불변. 대부분 의존 관계는 한번 주입이 되면 애플리케이션이 종료될때까지 변경할 일이 없고 변경해서도 안된다. 수정자 주입은 setXxx메서드를 public으로 열어 두기 때문에 다른곳에서 주입할수가 있어서 변경될 가능성이 높다. 그에 반에 생성자 주입은 객체를 생성할때 단 1번만 호출이 되므로 이후에는 호출되는 일이 없다. 따라서 불변하게 설계가 가능하다.

@ComponentScan으로 여러가지를 할 수 있는데 그 중 @ComponentScan( basePackages = "hello2.core2", excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class) ) excludeFilters 를 사용해서 @Configuration 어노테이션이 붙은 클래스를 막을 수도 있고 basePackages를 해서 탐색 위치를 정할수있다. basePackages = {"hello.core", "hello.service"} 이런식으로 여러 시작 위치를 정할수도 있다. basePackage를 만약 정해주지 않는다면 자동으로 @ComponentScan이 붙은 설정 정보 클래스의 패키지..

스프링에는 빈스코프 중에 프로토타입 스코프와 싱글톤 스코프가 있다 싱글톤 스코프는 싱글톤 스코프 빈을 스프링 컨테이너에 요청하면 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환한다. 이후에 스프링 컨테이너에 같은 요청이 와도 계속 같은 스프링 빈을 반환한다. 프로토 타입 빈을 스프링 컨테이너에 요청을하면(요청 시점에 프로토타입 빈이 생성된다) 빈을 생성하고 필요한 의존관계 주입을 하고 초기화 메소드까지 불러주고 끝낸다. 요청이 올때마다 계속해서 새로운 프로토타입 빈을 생성해서 반환하고 끝낸다. 즉 스프링에서 관리하지 않는다. 그래서 프로토타입을 관리할 책임은 프로토타입을 요청한 클라이언트에 있기 때문에 빈 생성주기를 관리하는 @PreDestory 같은 종료 메소드가 호출되지 않는다. PreDestor..

DB LOCK란 데이터베이스를 이용할때 데이터를 업데이트를 하고 롤백이나 커밋을 하지 않으면 그대로 락이 걸린다. 이 실행이 끝내기 전까지 계속 그 상태가 되는것이다. 락이 걸려있는 상태에서는 실행을 시켜도 계속 로딩만 돈다. 트랜잭션이 걸려있기 때문이다. 이 트랜잭션이 끝나야 다른 트랙잭션이 실행 되니까. 아무튼 그래서 커밋이나 롤백을 해줘야 제대로 업데이트가 되면서 락이 풀린다.

ApplicationContext는 스프링 컨테이너이다 스프링 컨테이너의 최상위 클래스인 BeanFactory를 상속받고 있다. BeanFactory는 getBean() 같은 많은 것들을 제공해 준다. 그런데 ApplicationContext를 쓰는 이유는 ApplicationContext는 다른 여러가지 기능들을 제공하기 때문이다. ApplicatonContext가 제공하는 부가기능 메시지소스를 활용한 국제화 기능 예를 들어서 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력 환경변수 로컬, 개발, 운영등을 구분해서 처리 애플리케이션 이벤트 이벤트를 발행하고 구독하는 모델을 편리하게 지원 편리한 리소스 조회 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회 를 할 수있다. 그리고 어떤 ..

AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는것을 IOC컨테이너 또는 DI컨테이너라고 한다. 어셈블러또는 오브젝트 팩토리라고 부른다. TDD란 틀을 먼저 만들어 놓고 개발을 하는것 즉 테스트케이스를 먼저 작성후 개발을 하는 방식이 TDD이다.

제어의 흐름을 내가 컨트롤 할 수 있으면 라이브러리, 내가 로직을 짜고 실행은 알아서 시켜주는건 프레임워크이다.(junit같은)