JBoss 서버에 데이터소스를 설정하는 내용을 담은 글들이 매우 많으나, 사실상 적용이 안되는 경우가 많았다.

톰캣처럼 컨텍스트 추가하고 읽으면 바로 사용할 수 있는 방법은 없다.

JBoss 에서 데이터소스를 사용하는 순서는 다음과 같다.

1. 드라이버 모듈 추가

2. 데이터소스 드라이버 등록

3. 데이터소스 추가

4. 데이터소스 매핑 jboss-web.xml

1. 드라이버 모듈 추가

드라이버 모듈은 modules 에 디렉토리를 생성하고 module.xml 을 생성하여 넣는 방법이 대부분 소개되어있다. 그러나 간혹 jboss 에서 인식이 되지 않는 경우가 발생한다. 모듈이 없거나 존재하지 않는다는 경고가 발생한다. 공백이나 양식, 문법등의 문제겠지만 정확히 어떤것이 문제인지는 확인할 수 없었다.

여기서는 jboss-cli 를 이용한다. jbosscli 실행하여 해당 서버콘솔에 접속하고 다음과 같이 입력한다.

module add --name=com.mysql --resources={mysql connector jar file 경로} --dependencies=javax.api,javax.transaction.api

그러면 자동으로 modules 아래에 com 폴더 아래에 새로운 mysql 모듈이 등록이된다.

2. 데이터소스 드라이버 등록

/subsystem=datasources/jdbc-driver=mysql:add(driver-module-name=com.mysql,driver-name=mysql,driver-class-name=com.mysql.jdbc.Driver)

위와같이 입력하면 데이터소스드라이버가 등록이 된다.

3. 데이터소스 등록

standalone/configuration/standalone.xml 을 편집하거나 management Web 을 이용한다. 

필자의 경우 management Web 을 이용하였으나 standalone.xml 을 편집하여 등록하는 방법을 적어본다.

 
 
 jdbc:mysql://localhost:3306/DB명.....파라미터
 com.mysql.jdbc.Driver
 com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource
 mysql
 
  2
  30
 
 
  아이디
  패스워드
 
 
  false
  false
 
 
  true
 
 

위처럼 소스를 삽입한다.

4. war 파일에 web.xml 과 함께 jboss-web.xml 을 추가한다.

  /{context path}
  
    jdbc/jndi별명
    javax.sql.DataSource
    java:/jdbc/jndi별명
    Container
  

위와같이 설정후 context lookup 시 comp/env 를 통해 lookup 하는것은 제외하도록 한다.

war 를 배포하고 배포경로를 통해 확인한다.

Bcel 을 처음 다룰 당시에 만들었던 간단한 매개변수 출력하는 BCEL transform이다.

상당히 다듬어지지않은 막코드라서 감안해서 볼 필요가있다.

핵심부분은 밑줄과 주석을 달겠다.

이전글(http://blog.sanguneo.com/21) 에서 premain 을 이용한 javaagent 사용법은 간략하게 배웠는데. 

BCEL을 여기에 접목시킨다는것은 조금 고차원적인 접근이 필요하다.(필자의 생각)

우선적으로 소스를 펼치기에 앞서 이론설명을 하자면 자바의 .class 파일은 완전하계 기계어(?)로 번역된것이 아닌,

그렇다고 소스형태도아닌 그 중간어딘가의 형태로 볼수있다. 

javac 명령어를 실행하면 소스파일을 java컴파일하면 class 파일로 뱉어내게되는데, 이 class파일이 ByteCode의 목적집합코드인셈이다.(?)

길게 이야기할거없이 일단 class파일은 바이트코드로 되어있다고 보면 된다.

웹상의 대부분의 자료들(BCEL에 관련해서만) 은 BCEL을 이용한 정적인 BCI 기술을 보여준다. 

정적인 BCI기술이라함은 class 파일화된 바이트코드를 다루는것이라 하겠다.

하지만! 이 정적인 BCI기술은 엄청난 한계가있는데, 

상용프로그램에대한 라이센스문제(수정불가등의 조항), 묶여있는 클래스군 혹은 시스템클래스 에대한문제(rt.jar 등) 이 그것이다.

그렇다면 실시간으로 무엇을 어떻게 불러와서 사용할수 있을고 하니. 자바에서 기본적으로 Transform 을 지원한다.(since jdk1.5)

여기서 사용할것은 ClassFileTransformer 이다.

우선 클래스파일 트랜스포머 메소드는 아래처럼 implements 로 얻어와서 정의하여 사용한다.

주의) 소스가 동작하지않을 수 있음. 버그있으면 피드백 바랍니다. 원본 코드를 자꾸 수정해서 아래코드는 기억을 더듬어 작성했습니다.

즉, 위에서 사용한 방식을 요약하면

클래스 파싱->메소드 검사후 조건검색->새 메소드인스트럭션 생성->인스트럭션에 아규먼트출력절차 추가->원본 인스트럭션 추가->생성된 인스트럭션을 원본 메소드에 교체->메소드를 클래스젠에 추가->클래스젠으로부터 클래스를 받아 바이트코드로 출력 하게된다.

이를 지칭하여

BCEL on fly, dynamic BCEL 이라고 부르기도 한다.

최신 개발버전 스냅샷 위치는 다음과같음

http://repository.apache.org/content/groups/snapshots/org/apache/bcel/bcel/6.0-SNAPSHOT/

BCI(Byte Code Instrumentation) 란 *.class 와 같이 바이트코드로 컴파일된 자바 클래스파일을 수정하고 다루는 도구 혹은 기술이다.

자바는 javac 로 컴파일할때 완전한 기계어 코드가 아닌 소스와의 중간형태인 Byte Code 로 생성하게되는데 이게 도움을 받으면 어느정도 읽고 수정할수 있다.

자바에서도 클래스파일을 다루는 법을 제공하며 응용 라이브러리로는

Apache Commons 의 BCEL ( 정식 5.2, 개발버전 6.0)

Object Web 의 ASM

JBOSS 의 JavaAssist 

등이 있고 본 블로그에서는 APACHE의 BCEL을 주로 다룰 예정이다.

필자가 다루고있는 라이브러리는 BCEL (Byte Code Engineering Library) 인데 이름만큼이나 정석(?)의 사용법을 제공한다.

바이트코드를 수정하고 작업을 추가하는 등의 작업을 바이트코드엔지니어링 이라고 하는데 앞으로는 작업 이라고 줄여서 말하겠다.

추측하건데 BCEL설계할당시에는 이미 컴파일된 *.class 파일작업만을 염두해두고 만들어졌을것이라고 생각한다. 

라이브러리 측면에서 볼때 실시간으로 혹은 임시적으로 클래스파일을 작업하는 부분에대해선 제공되는 사항이 없는데,

이는 ASM 과 Javaassist 도 마찬가지.

그런데 자바1.5 부터 transform 등의 방법으로 런타임 작업이 가능해졌다. 

class 파일을 작업하여 영구적으로 저장하는것을 영구작업,

런타임에 작업하여 임시적으로 사용하는것을 임시작업 이라고 하고 이야기를 진행하겠다.

왜 굳이 BCI 기술을 이용해서 코드에 새로운 작업을 추가하는가?

BCI 기술에대해 처음 접하는 대부분의 사람들이 위와같은 질문을 한다. 

"왜 굳이 어려운기술을 써가며 작업을 추가하느냐", "소스를 추가하면 되는거 아니냐" 등의 많은 질문을 받는데, 반대로 질문을 던져보면 답은 쉽게 나온다.

만약에 소스가 없거나, 라이센스문제등으로 소스추가나 수정이 불가능한경우라면 어떻게 할 것인가 하는 질문이다.

BCI의 이점은 여기에있다. 소스가 필요없다. 어떤 라이브러리를 사용하건 타겟클래스와 메소드나 변수정보 등만 파악할 수 있으면 작업이 가능하다.

또한 반복적인 작업을 줄일수도 있다.

작업하는 메소드 를 만들어놓고 특징이 비슷한 여러개의 메소드에 적용 할 수도 있다.

그러나 가장 큰 메리트는 역시 '소스수정을 직접 하지 않아도 추가절차를 진행할 수 있다.' 는  점이다.

소스를 추가하는게 부담스럽지않은 소규모의 웹 어플리케이션에선 큰 차이가 없지만, 만약 컴파일된 코드만 수십 수백개가 되는 대형 어플리케이션이라면

이야기는 달라진다. 서비스를 제공하기위해 타겟 혹은 고객이 추가적으로 수고해야하는 일을 없앨 수 있다.