DevBoi

스프링 관련 주요 어노테이션을 정리하면서 스프링 전반적인 개념을 좀더 쌓아보자 1. @Configuration 스프링에서 설정 클래스를 선언하는 어노테이션이다. 우선 스프링 빈을 만드는 방법은 @Bean, @Configurtaion, @Component 3가지 어노테이션을 사용하면 된다. Configuration을 클래스 파일에 달게 되면, 이 클래스는 빈등록하기 위한 파일이라는 것을 가시적으로 알려준다. @Configuration을 붙인 class를 java config파일이라고 생각한다면 @Configuration에 대한 클래스 파일 하위에 객체에 대한 return을 해주는 메소드에 빈을 해주면, ApplicationContext 중, AnnotationConfigApplicationContext는 ..

Pointcut : JoinPoint : 조인포인트는, 특정 aop가 발생되는 지점을 이야기한다. 이전 포스팅에서, 조인포인트를 지정하지 않아, 모든 메소드가 자동으로 걸렸던걸 이해하면 편하다, 이 조인포인트는 advice별로 적용이 가능하다. weaving : 위빙은 뜨개질하다라는 의미이기도 하다, 실제로 메소드나 특정 클래스가 호출될때 프록시를 통하게 되는데 해당 위빙은 프록시와, 이 타겟에 대한 동작과정을 엮는것을 의미한다. 이러한 Pointcut과 advice를 연결해주는 것을 advisor라고 한다. 시점, pointcut과 advice (행위) 를 서로 연결해 주는 중간 매개체라고 하면된다. 요런식으로 해당 매핑되는 메소드를 리스트 형태로, 세팅 할수도있다. 추가로 property name으로..

before advice는 생각 보다 단순하다. 해당 과 같이 생성하고, xml 파일에서 빈을 불러와서 로드한다. 단순히 클래스에 대한 빈등록을 하고, 해당 인터셉터 리스트에 추가해준다. 참고로 beforeAdvice는, MethodBeforeAdvice를 구현한다. AfterReturningAdvice, returnValue로, 해당 파라미터에 대한 사용도 가능하다 추가로 예외에 대한 핸들러도 등록이 가능하다. 강제로 쓰로우를 시키고 해당 쓰로우때, 빈을 등록하면, 해당 쓰로우 이후에는, 해당 인터셉터가 돈다 advice_throwing이라는 것을 볼수 있다. 여러가지의 advice를 활용하여 인터셉터를 구현해봤다. beforeAdvice,afterReturning,afterThrowing,around..

AOP 관련된 지식에 대해서 공부해보자 주 업무 비즈니스 로직의 전, 후, 전+후에 필요한 개발자 관점, 운영자 관점에서 필요한 업무가 있다 (로깅, 사용자 체크 등등) 해당 비즈니스 로직에 대한 처리 이후에 이런 공통된 작업을 해주는 것을 하는 행위를 AOP라고 한다. 이제 스프링 관련 AOP의 소스코딩을 해보자 우선 스프링 AOP를 사용하지 않았을때의 코딩 방법이다. 결과를 출력해주기 전에, 해당 과같이 작업을 해준다고 생각해보자 아니면 클래스 내에서 해당 소스를 나눴다고 생각해보자, 해당 AOP는 좋은 예로, 테스트에 대한 수행시간이다. 해당 과 같이 AOP적인 로직을 수행한다고 하면 모든 함수에, 작성해야한다. 소스를 나눈다고해도, 시점, 범위에 대한 일일히 설정하는 건 운영자로써 말도안되는 짓이..

여태까지 Config파일을 등록해서 bean을 등록 하고, 해당 config에 빈을 등록한걸 사용도 해보고 했다. 근데 결정적으로 왜? 왜 빈을 사용할까? ioc에 들어가서 관리의 대상이 되는건 알겠는데.... 굳이 왜쓰지? class로 쓰면 되는거 아닌가? 싶다 그래서 좀더 딥한 개념의 이유와 사용목적에 대해서 공부를 해보자. 우선 해당 개념을 이해하기 위해서는 자바빈 vs 스프링 빈에 대한 차이를 알아야 한다. 자바빈은 DTO,VO와 같이 getter,setter로만 접근이 가능한 자바 파일을 의미한다. 반면 스프링 빈은 IOC컨테이너가 관리하는 JAVA 객체를 의미한다. 쉽게 말하면, Bean, Component등을 등록하면 IOC 컨테이너에서 관리가 된다는 의미이다. 그러면 스프링에 제어권을 넘긴..

기존에는 xml에서 특정 빈에 대한 설정을 하고, 해당 설정을 통해서 관리가 되었다. 해당 xml에서 빈을 생성하고, set으로 특정 빈을 넣고, 그리고 리스트 형식으로 넣기도하고 등등 이방식에서 어노테이션 방식으로 편하게 변화했기 때문에 해당 내용으로 변경해보자 쉽게 말하면 , config 파일을 xml 파일이 아닌, 자바 파일로 설정하는 것이다. 이런식으로 하면, 우선 빈이 생성된다. 단 주의 점이, @Bean에서의 생성자는 예를 들면 exam() exam이 bean id가 되는 것이다. 쉽게 말하면 bean어노테이션으로 붙으면 메소드 명이 bean id 가 되고, 명사형이 아니다. 우선 config 파일을 바꿨다. 기본 생성자가 아닌, console에서는 exam이 필요하기 때문에 해당 autowi..

이전에는 이렇게 특정 빈을 만들고, 해당 빈을 사용할수 있도록, context:annotation-config를 통해서 autowired에서 자동으로 빈에 대한 탐지를 할수 있도록 해줬다 그래서 Autowired를 붙이면 변수명이 같거나, 해당 관련 구현체에 대한 것을 가져오거나 Quailifier를 통해서 빈을 선별해서 가져왔다. 그런데 빈에 대한 생성을 어노테이션을 하고, 스프링에다가 스캔방식으로 찾아라~ 라고 한다면? 위와 같이 찾거나 해당 Exam도, 빈으로 생성해서, GridConsole에서 Autowird하는 부분에서 가져올수 있도록 설정 할수있다. 컴포넌트 스캔에 대한 경로 지정은 특정 하위로 다 지정할수도있다. 근데 빈에 대한 초기값을 굳이 저렇게 해야할까?? 요로케 하면, 특정 값에 대한..

이전의 xml에서 설정을 해서 빈을 바꿔주었다. 그런데 이건 예전 방식이고, 어노테이션으로 DI로 많이 사용한다. 우선 property 를 사용해서, 특정 빈에서 다른 빈으로 DI를 하는 방식을 어노테이션으로 바꿔보자 저번의 set함수에서 오토와이얼드를 사용해서 주입을 하고, xml의 프로퍼티를 삭제 하였다. 추가로, xml에 context를 추가하여, 해당 어플리케이션에서는 @autowired어노테이션을 찾아줘라는 설정을 이렇게 한다. 근데 자동으로 주입해주는 빈의 기준은 뭘까?? 왜냐면, 별도로 빈 id를 지정하지 않았기 때문에, 빈이 여러개라면 어떤 빈으로 주입이 될까? 우선 bean의 아디기준으로 바인딩 되는게 아니라, class 타입 기준으로 바인딩이 된다. 그러면 만약에 동일 빈이 아래와 같이..

특정 빈에 상수값 세팅 하는 방법 생성자에 대한 값을 넣어서 빈을 주입 하는 방법 특정 빈에, 해당 값을 가지는데, 여러가지 생성이 필요하여, 네임스페이스를 사용하는 경우 컬렉션 타입으로 빈을 생성 및 사용방법 두가지 방법이 있다. 한가지는 빈과 생성자를 통해서 컬렉션 안의 타입 빈을 선언 하는 것이고 하나는 util을 추가해서 해당 유틸을 사용하는 것이다. 사용 방법은 같다. 실제로 값을 확인하면 정상적으로 확인이 가능하다.

DI 관련 그리고 스프링 설정 관련, ApplicationContext 인터페이스를 구현한 구현체들이 여럿 있다 각각은 해당 context를 구현한 위치에 따른 정보 전달에 따라서 다르게 사용한다 (FIleSystem은 컴퓨터 절대 경로, xmlWeb은 특정 Url을 통해서 해당 config 파일을 받아옴 등등) 무튼 기본 java project로 생성 했던 프로젝트를 프로젝트 오른쪽 버튼 configuration > convert to Maven project를 하게되면 기본 자바 프로젝트 > 메이븐 프로젝트로 변경이 된다. 변경이 되면, Maven 방식의 pom.xml이 생성이 되고 이런 프로젝트 구조에서 pom.xml에서 디펜던시를 추가한다. (add로 maven 관련 검색이 안되면, show vi..