@Value 어노테이션(SpEL 이용)

@Component

public class Sample{

@Value("Some currency")

private String currency;

}

@Component

public class Sample{

@Value("#{configuration.environment}")

private String environment;

@Value("#{configuration.getCountry()}")

private String country;

@Autowired

public void printCountry(@Value("#{configuration.getCountry()}" String country)}

System.out.println(count);   =>메소드 및 생성자 인자에 @Value를 사용할때는 반드시 @Autowired, @Resource 등의 어노테이션이 존재해야한다.

}

}

@Component("configuration")

public class config{

public static String environment="DEV";

public String getCountry(){

return "Some Country";

}

}

위와 같이 @Value와 SpEL을 이용 할 수 있다. 그리고 SpEL 같은 경우는 xml 설정에서도 이용 할 수 있다.

<bean id="sample" class=".....Sample">

<property name="environment" value="#{configuration.environment}" />

<property name="country" value="#{configuration.getCountry()}" />

.....

</bean>

@Inject / @Named 어노테이션

JSR 330(자바 의존성 주입)은 자바 플랫폼을 위한 의존성 주입 어노테이션을 표준화해서 스프링의 @Autowired 및 @Qualifier 어노테이션과 비슷한 @Inject 및 @Named 어노테이션을 정의하고 있다.

@Service("abc")

public class A{

@Autowired

@Qualifier("bb")

private B b;

}

이러한 클래스와 대비해서 @Inject & @Named 어노테이션을 적용해보면

@Named("abc")

public class A{

@Inject

@Named("bb")

private B b;

}

이와 같이 동일하게 적용할 수 있다.

즉, @Named 같은 경우 클래스 레벨에 적용되면 @Component,@Service 등등과 같은 어노테이션과 동일하게 적용되며, 인스턴스 및 메소드,생성자 레벨에 적용된다면 @Qualifier 어노테이션과 동일하게 이름 기준으로 의존성을 주입하는 기능을 하게된다. @Inject 같은 경우는 @Autowired 와 거의 동일한 기능을 하며 변수의 형식을 기준으로 자동으로 빈주입을 하는 역할을 담당한다.

@Resource / @PostConstruct / @PreDestroy 어노테이션

@Service("abc")

public class A{

@Autowired

@Qualifier("bb")

private B b;

}

이러한 정의를 @Resource 어노테이션을 이용한다면

@Service("abc")

public class A{

@Resource(name="bb")

private B b;

}

이렇게 적용할 수 있다. 즉, @Resource 어노테이션은 이름을 기준으로 의존성을 주입할 때 사용 할 수 있는 어노테이션이다. 만약 이름을 기준으로 의존성을 주입할 경우에는 @Autowired & @Qualifier 를 이용하는 방법과 @Resource 를 이용하는 두가지 방법이 있지만, @Resource 어노테이션을 이용하는 것이 좋다. 전자와 같은 경우는 우선 형식이 동일한 빈을 찾는 과정이 선행된 후에 이름과 같은 빈을 찾지만, 후자 같은 경우는 바로 해당이름과 동일한 빈을 찾는 과정을 들어가기 때문이다.

@PostConstruct & @PreDestroy 어노테이션은 xml 설정에서 빈의 속성 중에 init-method와 destroy-method 와 비슷한 역할을 하는 어노테이션이다. 즉, 사용자 빈정의에서 초기화과정에서 어떠한 행위를 원한다면 행위를 정의한 메소드에 @PostConstruct를, 빈의 생명주기가 다해서 GC되기 전에 어떠한 행위를 원한다면 행위를 정의한 메소드에 @PreDestroy 어노테이션을 붙여주면 빈 초기화과정과 삭제과정에서 어떠한 행위를 정의 할 수 있다.

mac os 환경에서 docker를 이용한 oracle 11g 설치 

우선 진행하기 전에 자신의 os에 맞는 docker를 다운로드 해줍니다.

1)docker pull wnameless/oracle-xe-11g

=>oracle 11g 도커이미지 다운로드, 여기서 이미지란 컨테이너에서 oracle를 실행시킬 수 있는 모든 파일이 포함된 것이라고 생각하면 됩니다.(변하지 않는 파일)

    즉, 이 이미지 파일을 이용하여 컨테이너에서 oracle을 실행시킬 수 있는 것입니다.

2)docker run --name oracle11g -d -p 59161:22 -p 59162:1521 -p 59163:8080 -v ~/my/oracle/data:/var/lib/oracle -e ORACLE_ALLOW_REMOTE=true --restart=always wnameless/oracle-xe-11g

=>1번 과정에서 이상없이 이미지를 다운로드 했다면 그 이미지를 이용하여 컨테이너에서 oracle을 할당/실행시키는 명령어 입니다.(적절한 컨테이너를 할당)

--name =>이름을 정해줍니다. 앞으로는 이 이름으로 oracle을 실행시킵니다.

-d =>백그라운드에서 실행시킨다는 의미

-p =>도커는 어떻게 보면 가상머신 위에서 돌아가는 것과 비슷한 의미입니다. 59162의 나의 로컬 port와 컨테이너에 할당된 가상환경의 1521 port를 연결시켜서 

나의 로컬과 컨테이너에 올라간 가상환경의 연결을 명시하는 것입니다.(실제로 sqldeveloper나 jdbc를 이용할때 1521이 아닌 59162으로 연결해줍니다.)

-v =>docker를 이용하여 데이터베이스를 이용할 때, 컨테이너를 실행시키고 데이터를 삽입하고, 수정하는 등의 작업을 진행한 후에 컨테이너를 종료했다가 다시

실행시키면 모든 데이터가 날라가게 됩니다. 즉, 이 옵션은 볼륨관련 설정인데 나의 local 디렉토리에 데이터를 유지해주는 역할을 합니다.(컨테이너를 종료

해도 데이터가 날라가지않음)

그 외 기타옵션

3)docker start oracle11g =>오라클 실행

4)docker logs oracle11g =>log를 볼 수 있는 명령어

5)docker stop oracle11g =>오라클 종료

6)docker rm oracle11g =>컨테이너 삭제

7)docker restart oracle11g =>오라클 재시작

이후에 만약 sqldeveloper로 오라클을 운영한다는 가정하에, locale관련 문제로 접속을 하지 못하는 일이 발생할수 있다.(port는 59162로 접속해야함)

이 문제는 맥에서 발생하는 문제인데,(다른 os에서 발생하는지는 모르지만 필자는 윈도우에서는 발생하지 않음) 맥 os 업그레이드 과정에서 locale이 

변경되어 반영되지 못하는 문제이다. 언어를 미국으로 바꾸었다가 다시 대한민국으로 바꾸면 locale 문제는 해결된다.

docker exec -it oracle11g bash

=>docker가 컨테이너를 할당 받아서 띄운 가상 OS 들어가는 명령

<bean>의 depends-on 속성

applicationContext.xml에 빈정의에 대한 설정을 모두 마치고 실행하게 되면 빈의 생성은 선언한 순서대로 생성이 된다.(만약 의존하는 빈이 다른 위치에 있다면 그 빈을 먼저 생성하고 다시 순서대로 내려온다.) 하지만 명시적으로 의존성이 들어나지 않고 암시적으로 빈이 어떠한 다른 빈을 의존하고 있는 경우가 있을 수 있다. 만약 명시적으로 의존이 들어나 있다면 스프링컨테이너는 알아서 순서에 맞춰 빈을 생성해 주지만 암시적으로 겉으로 들어나지 않은 의존성 같은 경우는 컨테이너도 어쩔수가 없다. 

예를 들면, 

eventSenderSelectorService라는 빈이 생성될때, appConfig.properties 파일에 어떠한 정보를 남겨준다. 그러면 service 빈이 그 appConfig.properties 파일에 작성된 정보를 이용하여 빈생성과정이 이루어진다. 위의 설정파일에서는 암시적으로 service 빈이 eventSenderSelectorService 빈을 의존하고 있는 것이다. 그래서 service 빈이 먼저 생성되는 과정이 된다면? 빈생성 과정에서 오류가 생기고 말것이다. (eventSenderSelectorService 빈 생성이 먼저 이루어져야함으로) 여기서 사용할 수 있는 속성이 depends-on 속성이다.

이렇게 depends-on으로 의존하고 있는 빈을 들어내줌으로써 eventSenderSelectorService 빈을 먼저 생성한 후에 service 빈을 생성한다.

depends-on속성에는 ","을 구분자로 여러개의 빈을 의존하고 있음을 명시할 수 있다.

하지만 이 속성은 자식 빈정의에는 상속되지 않는 속성임에 주의해야한다.(부모빈에 이 속성이 정의되어 있어도 자식에는 상속되지 않음)

스프링프레임워크 util schema

spring xml 빈설정을 할때 util 스키마를 이용하여 List,Map,Set,Property 타입 등 여러가지 타입들을 빈으로 노출시킬 수 있는 기능을 제공해준다.

이런식으로 빈으로 노출시켜서 빈정의에서 참조할 수 있다. 여기서 기본적으로 빈정의 안에서도 <list> 태그를 사용할 수 있는데 라는 이야기가 나올 수 있다. 하지만 util 스키마를 쓰면서의 장점은 list-class 속성으로 명시적으로 타입을 지정해줄 수 있어서 타입의 안정성이 있다는 것이다. 

스프링프레임워크 p & c schema

servlet context & servlet xml 설정파일에서 <property>,<constructor-arg> 로 속성을 정의하지 않고 간결한 표현을 제공하는 것이 p와 c schema이다.

말로 설명하는 것보다는 간단한 예제를 통해서 보는 것이 이해가 빠르다.

setter를 이용해 빈주입을 하는 예제이다. xml 파일에서는 원래라면 <property> tag를 이용하여 빈의 속성을 주입해줄 것이다.

하지만 p schema를 이용하면 훨씬 간결한 표현이 된다.

여기서 p schema를 사용하기 위해 네임스페이스를 추가해주는 설정이 필요하다. 단순 값은 p:bankName="value" 형태이고, 다른 빈을 참조할 경우는 

p:branchAddress-ref="빈id"이다.

생성자로써 의존주입을 할때 예시이다.

p schema와 방법은 차이가 없다. 하지만 여기서는 constructor 매개변수들의 이름을 지정하였다.(@ConstructorProperties 어노테이션을 이용하여 디버그플러그를 비활성화 시켰을 때, 생성자의 매개변수 이름을 지정하여 참조할 수 있게 설정하였다.) 하지만 index로 참조하려고 할 경우도 있을 것이다. 그럴경우에는 c:_0-ref="bean id" 이런 식으로 작성하면 된다. _를 포함하는 인덱스넘버를 넣어줘야함에 유의하면 된다.

스프링 빈 정의 상속

applicationContext.xml에서 2개 이상의 빈에서 같은 타입의 빈을 의존하고 있다면, 각각의 빈에서 <property> 혹은 <construct-args>로 빈을 일일이 의존할 필요가 없이 빈 정의 상속을 받을 수 있다.(사실 코드 길이가 확 줄지는 않지만 이런 방법도 있다라는 것을 보여주고 싶었다.)

이렇게 DatabaseOperations이라는 빈을 의존하는 클래스가 2개 있다고 가정해보자. 그렇다면 보통 xml 빈설정 파일에서 setter 의존 주입을 이용하여 각각의 빈정의 설정에서 DatabaseOperations 빈을 참조할 것이다.(보통 이렇게 한다. 하지만 자바에서 없어서는 안되는 상속이 있기에 여기서도 한번 이용해 보았다.)

이 xml 설정파일을 보면 DatabaseOperations 빈을 정의하고 daoTemplate이라는 추상화 빈정의를 하고 DatabaseOperations 빈을 참조하였다. 그리고 DatabaseOperations를 의존하는 2개의 빈에 <property>(setter빈주입) 없이 parent="daoTemplate" 속성을 추가함으로써 빈 주입이 가능하다. 여기서 추상화 빈정의를 한 빈은 인스턴스를 생성하지 않는다. 하지만 이 추상화 빈정의를 상속받는 빈정의는 반드시 구체적인 구현 클래스가 명시되어있어야한다.(이말은 추상화 빈정의에 추상화 빈정의를 상속 할 수 없다는 뜻)

부모의 빈에서 상속받는 요소들

-속성 - <property> 요소

-생성자 인자 - <constructor-arg> 요소

-메서드 재정의 

-초기화 및 소멸자 메서드

-팩터리 메서드

이런식으로 같은 빈을 여러개의 빈들이 의존하고 있다면 사용할 수 있는 방법중 한가지이다. 하지만 이렇게 빈의 정의가 적고 같은 빈의 의존하는 경우가 많지 않다면 그닥... 쓸 일이 있을지는 모르겠지만 이런 방법도 있다라는 것을 알아두면 좋을 것 같다.

빈 정의를 상속하는 여러가지 예제(부모 빈정의가 추상정의가 아닐때 포함)

여기서는 조금 다른 방법이다. 추상 빈정의가 아니라 클래스가 선언된 빈 정의도 상속 받을 수 있다. 만약 personalBankingService가 부모 빈정의인 serviceTemplate를 상속 받기 위해서는 serviceTemplate의 실제 클래스를 extends하거나 setter,construct를 serviceTemplate에 선언된 클래스에 맞게 선언 해주어야 한다.

Elasticsearch local 환경에서 하나의 클러스터에 n개 이상의 노드(인스턴스)생성

데이터 경로는 다른 클러스터의 여러 노드에 의해 공유 될수 있다. 이는 개발 시스템에서 장애 조치 및 다른 구성을 테스트하는데는 유용하다. 하지만 운영환경에서는 하나의 서버당 하나의 노드만 실행하는 것이 좋다. 즉, 하나의 서버에 하나의 노드만 실행시키기 위해서는 node.max_local_storage_nodes:1 로 설정하고, 만약 하나의 머신에서 여러 개의 노드를 실행시키기 위해서는 설정을 1 이상으로 조정해야된다. 만약 한 머신에서 두개 이상의 노드를 운영한다면 샤드들은 elasticsearch에서 자동으로 분배해준다.

elasticsearch.yml의 적당한 위치에 node.max_local_storage_nodes를 생성할 노드수 만큼 설정을 해준다. 그래서 한 데이터를 여러노드가 공유할 수 있게 설정을 해주면 된다. 그리고 여러개의 터미널을 켜서 node 인스턴스들을 생성하면 생성된 샤드가 자동으로 각 노드에 분배가 된다.

culr "localhost:9200/_cat/shards?v" 명령어를 실행시켜서 shard들의 분배상태를 확인할수 있다.