Whiteship's Note


OSGi는 의미가 없다. OSGi is irrelevant

Spring DM/etc : 2008.04.15 23:32


http://rossmason.blogspot.com/2008/04/osgi-is-irrelevant.html

한참 재미있게 Spring DM for OSGi를 공부하고 있고, OSGi의 매력에 빠져들고 있는 요즘.. 갑자기 기운이 쭉빠지게 하는 제목의 글을 만났습니다.

그런데 왠 걸.. 내용은 제가 예상했던 그런 내용이 아니였습니다. Spring DM 공부하길 잘했다는 것을 결론으로 마무리가 되었습니다.

저 글을 쓰신분은 로존슨과 세미나에서 OSGi에 대해 갑론을박을 나눈 경험이 있으신가 봅니다. 어쨋거나 제가 이해한 주요 내용은 이러합니다.

OSGi가 뜨고 있다. ---> OSGi가 제공해주는 서비스들은 좋다. ---> 그 서비스들이 고객에게 의미가 있는 것이지 그 내부 동작 원리가 의미가 있는 것은 아니다. ---> 따라서 OSGi에 대해서는 점차 이야기 할 일이 줄어들 것이고 어떻게 하면 OSGi의 장점을 잘 살릴 수 있는 기반 애플리케이션을 설계할 것인가가 주요 이슈가 될 것이다.

Spring DM과 같은 OSGi 추상화 계층이 정말 제 역할을 다 해줘서 OSGi API와 자세한 동작 원리를 몰라도 될 정도로만 해 준다면, OSGi 가 제공하는 서버스와 그 기능에만 초점을 맞춰 학습하는게 효울적인 것 같습니다. OSGi 플랫폼 개발자 이거나 Spring DM과 맞먹는 프레임워크를 만들겠다면 모를까...

'Spring DM > etc' 카테고리의 다른 글

화이트보드 패턴  (2) 2008.06.06
Impala 프레임워크 "너무 빠르자나!!"  (0) 2008.05.14
스프링 OSGi 번들 저장소  (0) 2008.05.04
웹 애플리케이션과 OSGi  (0) 2008.04.30
Spring DM에 Spring MVC 연동 기능 추가됨.  (4) 2008.04.29
OSGi는 의미가 없다. OSGi is irrelevant  (2) 2008.04.15
Spring DM 소스코드 보기: fisheye  (0) 2008.04.09
OSGi 번들 만들기 2  (0) 2008.04.08
OSGi 번들 만들기 1  (0) 2008.04.08
스프링 DM 벌써 1.0.2  (2) 2008.03.26
Spring OSGi 관련 링크  (0) 2008.01.31
top


Managed dependency는 무슨 뜻인가요?

Build/Maven : 2008.04.14 21:43


스프링 DM을 읽다가도 managed destroy라는 단어를 보고.. 이게 무슨 말인가 곰곰히 생각을 한 적이 있었는데요. 오늘도 저 단어를 만나서 고생을 했습니다. Maven 2.0.9에 새로 추가된 import managed dependency를 적용해보려고 했는데, 한바탕 Maven 지옥에 들락거리다 지쳐서 오늘은 실패를 기록하고 이만 집에 들어가려고 합니다.

Managed Dependency 넌 대체 무엇이니?
As an example, consider the following projects:

   1. ThirdParty 1.0 - contains declarations of third party jars.
   2. Project A 1.0 - A project that uses declarations in ThirdParty and produces some number of versioned artifacts.
   3. Project B 1.0 - A project unrelated to Project A. It also uses declarations in ThirdParty and produces some number of versioned artifacts.
   4. Project C 1.0 - Has dependencies on ThirdParty, Project A, and Project B.

In Maven 2 it is not possible for Project C to use the managed dependencies from both A and B since neither has any direct relationship to the other.
참조: http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies

이게 무슨 이야기인지 이해가 안 되고 있습니다.

C가 A랑 B를 dependency에 추가하면, A와 B가 사용하는 dependency들도 C에 추가되어서 C프로젝트에서도 사용할 수 있는데, 대체 MD가 뭐길래.. C에서 사용하는게 불가능한 걸까요.
top


Commit comment template

Good Tools : 2008.04.14 16:37


Maven 2.0.9가 나왔다는 소식을 듣고 프로젝트를 좀 살펴보다가 Commit Message Template 라는 걸 발견했습니다. 커밋을 할 때 이슈 번호와 간략약 메시지를 남겼었지만 템플릿을 사용하지는 않았었습니다. 사람들이 여러명이면 커밋 메시지 작성하는 방법도 가지가지 일텐데, 템플릿을 사용하면 좋을 것 같네요.

[issue1, issue2] <<comment>>
Submitted by: (when it was a patch, put that persons name there)

샘플
[MNG-1456] Added the foo to the bar
Submitted by: Baz Bazman

이게 Maven의 커밋 메시지 템플릿입니다. 스프링의 커밋 메시지 템플릿도 찾아내고 싶었지만 저 정도면 되겠죠. patch가 아닌 경우에는 submitted by를 굳이 적어줄 필요는 없습니다. svn 계정으로 구분하면 되니까요.

이클립스에서 이녀석을 사용하려면 template에 등록하시고, 커밋할 때 Choose a previously entered comment or template에서 선택하면 됩니다.

사용자 삽입 이미지

'Good Tools' 카테고리의 다른 글

파이어폭스 3.0 용 All-In-One Gesture  (2) 2008.06.19
Terracotta  (2) 2008.05.19
SpringSource AMS 간단 사용기  (3) 2008.04.23
SpringSource Application Manager Suite  (2) 2008.04.22
Blip.tv 좋았어!!  (2) 2008.04.15
Commit comment template  (0) 2008.04.14
이클립스 SVN 플러그인 Subversive 설치  (2) 2008.04.04
Spring Tool Suite: Knowledge Base  (3) 2008.03.20
Maven + Clover  (1) 2008.03.18
Tomcat 6, MySQL에 JIRA(WAR/EAR 버전) 설치하기  (6) 2008.03.05
Bamboo 멋쟁이 - CI 와 테스트  (0) 2008.03.04
top


4.7. Stopping the extender bundle

Spring DM/Chapter 4 : 2008.04.13 12:41


Extender 번들이 멈추게stop 되면, Extender가 만든 모든 application context가 제거 될 것이다. Application context가 제거되는 순서는 다음과 같다.

1. 어떤 서비스도 export하지 않았거나, export 했지만 다른 번들들이 참조하지 않고 있는 application context를 가장 먼저 없앤다. 없앨 때는 번들 id의 역순으로 가장 최근에 설치된 번들의 application context부터 없앤다.

2. 1번 과정에서 import한 서비스들에 대한 레퍼런스가 끊기면서 새롭게 다시 1번 과정이 대상이 되는 application context가 생길것이다. 그렇다면 1번을 다시 수행한다.

3. 더이상 동작 중인 application context가 없다면, 멈춘다. 만약 여전히 남아있는 application context가 있다면, 이건 상호 참조cyclic depedency of references가 있다는 것이다. 이 경우에는 서비스 랭킹을 확인해서 랭킹이 낮은 녀석을 내린다. 그리고 1번부터 다시 한다.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.6. Application Context Destruction

Spring DM/Chapter 4 : 2008.04.13 12:34


application context의 삶은 자신이 포함되어 있는 번들에 달려있다. 따라서 만약에 번들을 제거uninstall 하면, application context도 제거되고, export 했던 서비스들도 레지스트리에서 내리고, import 했던 서비스들도 제거한다.

번들만 별도로 닫히거나 전체 OSGi 플랫폼을 끄는 것과 같은 매우 큰 이벤트의 일부로 닫힐 수가 있다. 이런 경우이거나 extender 번들이 닫히는 경우에는, 서비스들 사이의 종속성에 근거하여 관리하에 닫게 된다. 자세한 내용은 다음 섹션에서...

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.4. The Resource abstraction

Spring DM/Chapter 4 : 2008.04.12 18:00


스프링은 리소스 추상화 계층을 제공합니다.
- Application Context는 그 녀석을 기본으로 탑재하고 있습니다.
- 모든 리소스는 application context가 가지고 있는 org.springframework.core.io.ResourceLoader가 읽어옵니다. 물론 이 녀석을 별도의 bean에 주입하고 직접 코딩을 통해서 리소스를 읽어와도 됩니다.
- 리소스의 경로 앞에 classpath: 또는 file: 접두어prefix를 사용하여 가져올 리소스의 경로를 지정할 수 있는데, 사용하는 application context의 구현체에 따라 기본으로 사용하느 접두어가 다릅니다.

OSGi 4.0.X 스펙에는 리소스를 읽어올 세 종류의 공간space을 정의하고 있습니다.
- 스프링 DM은 이 모든 것들을 적잘한 OSGi 맞춤 application context와 적잘한 접두어를 사용하여 지원합니다.

접두어

OSGi 리소스 로딩 방법

설명

classpath:

Class Space

번들 클래스로더(the bundle, all imported packages and required bundles)를 찾는다. 해당 번들들이 RESOLVED 상태가 되도록 강제한다. 이 방법은 OSGi API Bundle 클래스의 getResource(String)과 유사한 방법이다.

classpath*:

Class Space

번들 클래스로더(the bundle and all imported packages and required bundles)를 찾는다. 해당 번들들이 RESOLVED 상태가 되도록 강제한다. 이 방법은 OSGi API Bundle 클래스의 getResource(String)과 유사한 방법이다.

osgibundlejar:

JAR File(or JarSpace)

번들 jar만 찾는다. 번들을 RESOLVED 상태로 만들 필요 없이 low-level 접근을 제공한다.

osgibundle:

Bundle Space

번들 jar와 그것에 붙어있는 조각(fragment)들까지 찾는다. 클래스로더를 생성하거나 번들이 RESOLVED 상태가 되도록 강제하지 않는다.



노트
만약 접두어를 붙이지 않으면, 기본으로 bundle space(osgibundle:)를 사용합니다.

노트
OSGi의 동적인 특징 때문에, 번들 클래스패스가 생명주기 동안 변경 될 수 있습니다. 이것으로 인해 실행 중이 환경 또는 타겟 플랫폼에 기반해서 패턴 매칭을 할 때 전혀 다른 클래스패스 리소스가 반환될 가능성이 있습니다.

file: 이나 http: 같은 일반적인 스프링 리소스 접두어들도 물론 지원하며, 리소스 로딩이 되는 대상은 위치에 있더라고 상관없습니다. resource-loading 번들 또는 거기에 붙어있는 fragment에 국한되진 않습니다.

OSGi 플랫폼들이 번들에 들어있는 내용물을 찾기 위한 자신들 만의 독특한 접두어들을 가지고 있을 수도 있다. 예를들어, Equinox는 bundleresource: 와 bundlentry: 접두어를 가지고 있다. 물론 이렇게 플랫폼이 정의한 프리픽스도 스프링 OSGi(여긴 DM이라고 안 했네.ㅋㅋ)과 함께 사용할 수 있다. (특정, OSGi 구현체에 여러분들이 직접 타이핑하는 수고는 해야하다.)

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.5. Accessing the BundleContext

Spring DM/Chapter 4 : 2008.04.12 07:58


스프링 DM을 사용하면 OSGi API에 의존하지 않아도 된다.
- 정말로 OSGi의 BundleContext 객체에 접근하고 싶다면, 스프링이 도와줄 것이다.
- Extender가 만들어준 application context에는 BundleContext 타입의 bean 하나를 bundleContext라는 이름으로 항상 가지고 있다.
- 이 bean을 application context내의 다른 bean에 얼마든지 중입inject 할 수 있다.
- 거기다가, BundleContextAware라는 인터페이스까지 마련해 뒀다.
- 이 인터페이스를 구현한 bean들은 스프링이 bundleContext를 끼워넣어줄 것이다. 이 기능을 사용하려면, org.springframework.osgi.context 패키지를 import 해야한다.

public interface BundleContextAware {
public void setBundleContext(BundleContext context);
}

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.3. Bundle Lifecycle

Spring DM/Chapter 4 : 2008.04.11 21:20


OSGi는 다이내믹 플랫폼으로, 프레임워크가 동작하고 있는 도중에 번들을 설치, 시작, 업데이트, 멈춤, 제거 할 수 있다.

번들이 멈추면be stopped
- 번들이 등록한 서비스들은 모두 등록이 해지되고unregistered 번들은 RESOLVED 상태가 된다.
- 번들이 가지고 있던 자원을 반납하고 쓰레드도 종료한다.
- 번들이 노출 시켰던 패키지들은 번들이 멈추더라도 계속해서 다른 번들들에 의해 사용될 수 있다.

번들은 RESOLVED 상태에서 업데이트 할 수 있다.
- 업데이트하는 과정은 같은 번들을 특정 버전에서 다른 버전으로 이관migrate하는 것이다.

번들은 RESOLVED 상태에서 시작be started 될 수 있다.
- 시작되면 번들은 ACTIVE 상태가 된다.

OSGi의 PackageAdmin refreshPackages 명령어
- 전체 OSGi 프레임워크 또는 설치되어 있는 번들들의 모든 패키지를 리프래시한다.
- 리프래시하는 동안에 그 대상이 되는 번들의 Application Context는 멈췄다가 재시작한다.
- refreshPackages 명령 처리 후, 수정된 번들의 이전 버전 패키지 또는 제거된 번들의 패키지는 더이상 사용할 수 없다. 자세한 사항은 OSGi 스펙 참조.

(다시) 번들이 멈추면..
- application context는 자동으로 제거된다.
- 서비스들도 OSGi 서비스 레지스트리에서 제거된다.
- application context의 종료 라이프사이클(DisposableBean, destroy-method, @Post머시기..)이 진행된다.
- 멈춘담에 바로 다시 시작시키면, 새로운 application context를 만든다.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.2. Application Context Creation

Spring DM/Chapter 4 : 2008.04.11 21:03


Extender 번들은 application context를 비동기적으로 생성한다.
- OSGi 서비스 플랫폼 시작 속도를 빠르게 해준다.
- 서비스들 간의 종속성으로 인한 데드락의 위험이 없다.
- 따라서 스프링 DM을 사용한 번들의 application context가 만들어지기 전에 STARTED 상태가 될 수 있다.
- 5.1을 참조하면, 동기적으로 번들을 생성하도록 설정하는 방법을 참조할 수 있다.
- 만약 application context를 무슨 이유에서건 생성하지 못했다면, 로그를 남기고 번들은 여전히 STARTED 상태다. 단, 해당 번들이 export한 서비스는 하나도 없는 상태로..

1. Mandatory Service Dependencies


OSGi 서비스의 가용성에 필수적인 mandatory 의존성을 선언하면, 해당 application context의 생성은 OSGi 서비스 레지스트리를 통해서 필수적인 의존성을 만족 시킬 때까지 대기 block 한다.
- 6장 서비스 레지스트리에서 필수적인 서비스 레퍼런스를 찾지 못할 때 어떤일이 벌어지는 지 설명한다.
- 이런 원리로 스프링 DM은 번들들이 어떤 순서대로 시작되는 상관없이 필수적인 종속성을 가지도록 보장한다.
- 타임아웃을 설정할 수 있다. 기본은 5분이다. timeout 지시자에 그 값을 설정할 수 있다. 5.1 참조.
- 해당 번들 실행시 필요한 서비스를 못찾으면 바로 application context 생성을 실패하도록 설정할 수 있다.(fail-fast) 이 경우 해당 번들은 ACTIVE 상태가 아니라 RESOLVED 상태로 남게 된다.

2. Application Context Service Publication


번들의 application context 생성이 완료되면, application context 객체는 자동으로 OSGi 서비스 레지스트리에 하나의 서비스로 등록이 된다.
- org.springframework.context.ApplicationContext 인터페이스 아래로 공개된다.
- 공개된 서비스들은 org.springframework.context.service.name 이라는 서비스 속성을 가지고 있다. 이 값은 해당 application context를 가지고 있는 번들의 Symbolic Name으로 설정된다.
- application context를 서비스로 등록하는 걸 막을 수도 있는데, 이건 5.1에서 살펴본다.

노트: Application context가 서비스로 등록되는 이유는 testing, administration, management를 하기 위해서다. context 객체에 런타임시 접근하여 getbean() 같은 것을 호출하는 행위를 하지 말기 바란다. 다른 번들의 application context에 등록되어 있는 Bean을 가져오고 싶을 때 권장하는 방법은 일단 OSGi 서비스로 해당 bean을 export하고, 그걸 참조하고 싶어하는 context에서 서비스로 import하는 것이다. 이렇게 서비스 레지스트리를 통해서 가져와야 그에 상응하는 버전에 해당하는 서비스만 참조하는 것을 보장하며, OSGi 플랫폼이 동적으로 관리하는 서비스를 가져올 수 있다.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


PostgreSQL DB 백업/복구

DB/실습 : 2008.04.11 09:59


su - postgres

pg_dump db이름 > 폴더/백업파일명

백업파일 다운로드

dropdb -U postgres db이름

createdb -U postgres -E 인코딩 db이름

psql -U postgres db이름

\i 백업파일명


'DB > 실습' 카테고리의 다른 글

PostgreSQL DB 백업/복구  (0) 2008.04.11
MySQL 인코딩 설정 바꾸기  (0) 2007.08.30
HSQL 데이터베이스 Persistent 모드와 In-Memory 모드  (2) 2007.07.25
MySQL DB의 데이터를 CSV파일로  (0) 2007.06.18
top


4.1. The Spring Dynamic Modules Extender bundle

Spring DM/Chapter 4 : 2008.04.10 22:41


스프링 DM은 org.springframework.osgi.bundle.extender라는 번들을 제공한다.

이 번들은 번들에서 사용할 스프링 application context를 생성해준다. 스프링 웹 애플리케이션의 ContextLoaderListener와 같은 역할을 한다.

extender 번들이 설치 installed 되고 시작 started 되면 이미 Activce인 상태의 번들 중에 스프링 DM을 사용하는 번들을 찾아서 application context를 만들어 준다.

또한, 번들 시작 이벤트를 주시 listening 하다가 스프링 DM을 사용한 번들이 시작되면 application context를 만들어 준다.

5.1에서 extender가 어떻게 스프링 DM을 사용한 번들로 인식하는지 알아본다.

Extender Pattern

"allow other bundles to extend the functionality in a specific domain"
특정 도메인에 있는 기능을 다른 번들들이 확장할 수 있도록 하는 패턴.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


Bundles and Application Contexts

Spring DM/Chapter 4 : 2008.04.09 23:08


OSGi 번들

OSGi에서 배포 단위는 번들.
번들은 런타임시에 세 가지 steady 상태 중 하나가 됨. installed, resolved, active.
번들은 서비스를 OSGi 서비스(객체) 레지스트리에 등록하여 다른 번들이 해당 서비스를 사용하도록 할 수 있슴.
번들은 패키지를 노출 시켜서 다른 번들들이 노출 된 타입들을 import 해서 사용하도록 할 수 있음.

스프링 Application Context

스프링의 기본적인 모듈화 단위는 application context.
이 안에 스프링이 관리할  빈들을 담고 있다.
상속 구조를 가질 수 있다. 하위 context에서 상위 context에 있는 빈들을 참조할 수 있지만, 그 반대는 안 된다.
(Spring MVC를 잘 보면 이 구조가 있죠.)
스프링의 exporter나 factory bean들은 외부 클라이언트쪽 application context에서 해당 bean에 대한 레퍼런스를 사용할 수 있도록 제공해준다.
(Spring의 Expoter들은 JMS나 RPC 쪽을 보면 잘 나와 있습니다. 아주 일관된 패턴으로 Exporter들을 제공해 줍니다.)

OSGi 번들과  스프링 Application Context

잘 어울린다.
스프링 DM을 사용해서, 번들은 번들 내부에 있는 객체들(bean)을 생성하고, 설정하고, 묶고, 꾸며줄 applicaion context를 가질 수 있다.
그런 Bean들 중에 일부를 선택적으로 OSGi 서비스로 노출시켜서 외부의 다른 번들에서 사용할 수 있도록 할 수 있고, 그런 빈들은 깔끔하게Transparently 다른 OSGi 서비스에 주입 될 수 있다.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


Spring DM 소스코드 보기: fisheye

Spring DM/etc : 2008.04.09 13:01


스프링의 모든 프로젝트 코드를 한 눈에 볼 수 있습니다.
http://fisheye3.cenqua.com/browse/springframework

이 중에서 Spring DM의 소스 코드는 하위 디렉터리로 들어가면 되는데, 폴더 이름은 예전 이름 그대로인 spring-osgi네요.

사용자 삽입 이미지

http://fisheye3.cenqua.com/browse/springframework/spring-osgi


가장 최근에 수정한 코드 중에 DefaultOsgiApplicationContextCreator라는 녀석이 있군요.
소스코드를 보려면 일단 ~~.java 같이 링크로 되어 있는 녀석을 클릭합니다. 그러면 버전이 보이고,  annotated/raw라는 링크가 보이는데, 소스코드만 보고 싶으신 분들은 raw를 클릭하고, 이것 저것(누가 어디를 언제 수정했는지) 보고 싶으시 분들은 annotated를 클릭하면 됩니다.

사용자 삽입 이미지

음.. 대강 보니, 번들에서 스프링 설정 가져오과서 이게 스프링 DM이 지원하는 번들인지 본다음에, Spring DM이 지원하는 번들이면, ApplicationContext를 만들어서 서비스에 ApplicationContext를 등록하는 코드인가 봅니다.

와. 정말 깔끔하군요.


top


What is new?

Spring DM/Chapter 3 : 2008.04.09 12:35


스프링 DM이 젊은 프로젝트(young project)이다 보니, 매 버전 마다 새로운 기능이 추가 된다. 이 번 챕터에 그 내용들을 다룬다.

1.1.X

1. Web Support

찬욱군 블로그에서 본 내용이군요.

The biggest feature in Spring Dynamic Modules 1.1.x is the transparent support for web applications on OSGi platforms.

멋진 단어 중에 하나인 Transparent 나왔습니다. non-invasive와 같은 맥락으로 이해하면 되겠죠. 투명하게 지원한다.. 뭐 이렇게 해석하시거나 이해(?)하시면 곤란합니다. 톰캣이나 제티같은 웹 컨테이너를 직접 통합하여 WAR를 바로 배포할 수 있도록 했다고 합니다.

Chapter 8에서 자세히 다룬답니다.

2. Classpath Resource Abstraction

OSGi resource를 찾을 때 classpath: 나 classpath*:를 사용할 수 있다. 마치 스프링의 component scanning과 비슷한 것이다.

OSGi resource에 대해서는 다음을 참조.
- Section 4.4 "The Resource abstraction"
- 4.3.12 of the OSGi specification

(흠.. 뭐 천천히 살펴보죠. 레퍼런스가 어디로 도망가는 것도 아니고..)

3. Pluggable Extender Configuration

1.1.X는 스프링 DM에서 사용하는 extender(이 녀석은 지난 번 토비형님이 JCO에서 발표하실 때 봤었죠. 스프링 DM에서 가장 중요한 번들로, application context를 만들어 줍니다.) 기본 설정을 쉽게 변경할 수 있는 기능이 추가 됨.

fragment(자 어려운 용어 계속 나옵니다.ㅋㅋㅋ 단순하게 번들 상속이라고 할까요. 흠.. 빌붙기라고 할까요. 자신의 클래스로더를 만들지 않고 다른 번들에게 빌붙을 수 있습니다.)를 사용해서 애플리케이션 컨텍스트를 시작하는 방법, 웹 배포에 사용할 웹 컨테이너, 스프링 애플리케이션이 돌아갈 쓰레드 풀등의 설정을 사용자가 커스터 마이징 할 수 있다. 또한 OSGi 스프링 애플리케이션 컨테스트 라이프사이클에 대응하는 이벤트를 받는 것이 가능하다. 4.1에서 자세히 다룸.

'Spring DM > Chapter 3' 카테고리의 다른 글

What is new?  (0) 2008.04.09
OSGi 번들 상태 변화  (2) 2008.01.26
top


Requirements

Spring DM/Chapter 2 : 2008.04.09 12:02


스프링 다이내믹 모듈(DM) 1.0은 JDK 1.4 이상과 OSGi R4 이상을 지원한다.

스프링 DM을 사용해서 배포하는 번들은 반드시 MENIFEST.MF에 "Bundle-ManifestVersion: 2"라고 명시해야 한다.

저게 무슨 뜻이냐면, OSGi R4를 따르는 번들이라는 뜻이다. 스프링 DM이 OSGi R4 이상을 지원하니까 저렇게 해야한다. 2 말고 1이라고 할 수도 있는데 그건 OSGi R3 스펙을 따르는 번들이라는 뜻이다.

스프링 DM은 Continuous Integration의 일부로 Equinox 3.2.2, Felix 1.0.3, Knopflerfish 2.0.4에서 테스트를 한다고 합니다. 멋있어!

'Spring DM > Chapter 2' 카테고리의 다른 글

Requirements  (0) 2008.04.09
top


Why Spring Dynamic Modules?

Spring DM/Chapter 1 : 2008.04.09 11:55


스프링 프레임워크는 full-stack Java/JEE를 이끌고 있는 애플리케이션 프레임워크다.

스프링 다이내믹 모듈은 스프링 애플리케이션을 OSGi 실행 환경에 쉽게 배포 할 수 있도록 돕는다.

엔터프라이즈 애플리케이션은 스프링 다이내믹 모듈과 OSGi 플랫폼을 사용하여 다음과 같은 장점을 얻을 수 있다.
- 보다 나은 모듈화. (모듈이라는 경계를 강화하여 애플리케이션 로직을 모듈 단위로 경계를 긋는다.)
- 모듈을 버전에 따라 동시에 여러개를 배포할 수 있다.
- 동적으로(런타임에) 시스템에 있는 다른 모듈이 제공하는 서비스를 사용하고 발견할 수 있다.
- 동적으로 모듈을 실행 중에 설치, 업데이트, 제거 할 수 있다.
- 스프링 프레임워크를 사용하여 여러 모듈에 걸쳐 컴포넌트들을 생성하고, 설정하고, 묶고assemble, 꾸밀decorate 수 있다.
- 개발자들이 쉽게 OSGi 플랫폼의 기능을 사용할 수 있도록 간단하고 익숙한 프로그래밍 모델을 제공한다.

'Spring DM > Chapter 1' 카테고리의 다른 글

Why Spring Dynamic Modules?  (0) 2008.04.09
top


OSGi 번들 만들기 2

Spring DM/etc : 2008.04.08 21:54


참조 : Creating OSGi bundle

OSGi 메타데이터 작성하기

손으로
손수 OSGi 메타데이터를 작성하는 일은 비추.
한 줄당 72 스페이스를 넘으면 안 된다.
META-INF/MANIFEST.MF 파일이 압축파일 젤 위에 있어야 한다.
이 방법은 정말 정말 다른 방법이 없을 때나 사용하라.

Bnd
Bnd는 BuNDle 도구로 Peter Kriens(OSGi Technical Officer)님께서 만들었다. OSGi R4 번들용 메타데이터를 만들어주는 도구다. 멋진건 bnd.jar 파일 자체가 실행가능한 파일인데다가, Ant 태스크도 가지고 있고, 이 거 자체로 이클립스 플러그인이기 때문에, Eclipse의 plugins 폴더에 넣으면 번들 만들어 주는 메뉴가 생긴다.

(와.. 정말 죽인다.)

이걸 사용해서, 클래스들을 OSGi 번들로 만들 수도 있고, 이클립스 프로젝트를 OSGi 번들로 만들 수도 있고, 기존의 JAR 파일을 OSGi 번들로 만들 수 도 있다.

예제가 있는데 이건 실습하면서 해보게 생략합니다.

java -jar bnd.jar print c3p0-0.9.1.2.jar

java -jar bnd.jar wrap c3p0-0.9.1.2.jar

java -jar bnd.jar wrap -properties c3p0-0.9.1.2.bnd c3p0-0.9.1.2.jar

Maven용 번들 플러그인

Apache Felix Bundle Plug-in은 Bnd와 Maven2를 연동할 수 있는 메이븐 플러그인이다. 메이븐의 POM에 해당 프로젝트가 필요로 하는 라이브러리 정보가 들어있기 떄문에, Bnd가 MANIFEST를 작성할 때 필요한 추가 정보를 POM을 보고 생성할 수 있다.

예제가 있는데.. 이것도 실습해보기 위해 생략합니다.

(아.. 정말 Maven의 POM이 유용하게 쓰이겠군. 버전도 있지, optional인지도 있지, 캬.. 죽이는데.. OSGi랑  Maven 이랑 찰떡궁합이였군!!!)

Bnd가 번들로 패키징 할 때, 클래스패스에 있는 모든 클래스를 묶어버리는 것을 주의해야 한다. Bnd가  Export/Import 패키지를 보고서 생성할 jar파일에 추가할 라이브러리를 추가/제거 하긴 하는데, 패턴 매칭을 잘 해서 실제로 포함할 패키지만 가지고 묶을 수 있도록 설정을 잘 해야한다.

별도 개발, in-house 툴

바이트코드 분석을 기반으로 새로운 툴을 만들어 사용해도 된다. 스프링은 ASM 기반 바이트 코드 파서를 사용해서 테스트 프레임워크를 만들었다. 보다 효율적으로 간단한 MENIFEST.MF 파일을 만들려고..

OSGi 저장소 사용하기

기존의 JAR를 Bnd를 사용하여 새로운 OSGi 번들로 만들기 전에, 이미 OSGi 저장소에 존재할 수 있으니 거기서 찾아서 사용해도 된다.

OSGi Bundle Repository(ORB)
Eclipse Orbit
Apache Felix Commons
Apache OSGified projects

top


OSGi 번들 만들기 1

Spring DM/etc : 2008.04.08 21:16


참조 : Creating OSGi bundles

OSGi를 접할 때, 가장 먼저 익혀야 할 단어는 바로 번들(bundle). 이 아티클에서는 번들이 뭐고 어떻게 일반 Jar 파일을 OSGi 번들로 변환할 수 있는지 살펴본다.

번들은 무엇인가?

OSGi 스펙에서는 번들을 "모듈화 단위 Unit of modularization"이라고 표현하고 있다. 모듈은 다시 사용자에게 어떤 기능을 제공하기 위해 필요한 클래스와 리소스들을 뭉친것. 이라고 한다. 좀 더 정확히 번들은 무엇인가?

번들은 다음의 것들을 가지고 있는 JAR 파일들이다.
- 리소스들을 가지고 있다.
- JAR 파일의 내용과 번들에 대한 정보를 나타내는 menifest 파일을 가지고 있다.
- OSGi-OPT 폴더 또는 그 하위 폴더에 에 부가적인 문서를 가지고 있을 수 있다.

(그렇다고 JAR 만 번들이 될 수 있는 건 아닌데... WAR도 번들이 될 수 있는데.. Costin Leau님께서는
쉽게 설명하려고 그런 것 같다.)

번들 = JAR + OSGi 정보(META-INF/MANIFEST.MF)

OSGi 메타데이터

OSGi 메타데이터는 menifest 구성요소로 표현하며, 스펙에는 20가지 정보 되는 헤더를 설명하지만 여기서는 가장 자주 사용하는 것들 몇개만 살펴본다.

Export-Package
- 어떤 패키지를 노출시켜서 다른 버들들이 가져다 사용할 수 있는지 명시한다. 여기에 명시한 패키지만 노출시키고 나머지는 다른 번들들이 참조할 수 없다.

Import-Package
- 번들에서 참조할 패키지를 나타낸다. 여기에 명시한 것들만 참조할 수 있다. 기본으로, 여기에 명시한 패키지들은 필수mandatory가 된다. 따라서 명시한 패키지가 존재하지 않으면 해당 번들을 실행할 때 fail 하게 된다. 예외 발생.

Bundle-SymbolicName
- 유일한 필수 항목으로, 번들을 식별하기 위한 유일한 값이다. 컨벤션은 도메인 명 거꾸로 사용하기. 패키지 이름처럼..

Bundle-Name
- 사람들이 읽기 편한 이름을 정의한다. 공백이 없어야 한다. Bundle-SymbolicName보다 더 의미있는 정보를 짧게 표현할 수 있기 떄문에 이 헤더를 추가하는 것을 권장한다.

Bundle-Activator
- BundleActivator는 OSGi 스펙 인터페이스로 번들이 OSGi 프레임워크 위에서 가동Start 되거나 멈출Stop 때 실행되는 자바 코드를 정의할 때 사용한다. 여기에 적어줄 클래스는 풀 패키지 경로를 붙여줘야 하며, public  클래스여야 하고, 인자가 없는 public 생성자를 가지고 있어야 한다.

Bundle-Classpath
- 해당 JAR 파일이 여러 폴더에 클래스 패키지나 jar 파일을 라이브러리로 참조할 때 기본 패키지 경로(jar 파일 루트에서 도달할 수 있는 클래스들)를 확장하기 위해 사용한다.

Bundle-ManifestVersion
- OSGi release 3을 사용하면 1이라고 적어주고, OSGi release 4(이게 최신 스펙)를 쓰려면 2라고 설정한다. 기본값이 1이기 때문에, OSGi release 4를 사용할 땐 반드시 2라고 설정해준다.

예제
Bundle-Name: spring-core
Bundle-SymbolicName: org.springframework.bundle.spring.core
Bundle-ManifestVersion: 2
Export-Package:org.springframework.core.task;uses:="org.springframework.core,org.springframework.util";version=2.5.1 org.springframework.core.type;uses:=org.springframework.core.annotation;version=2.5.1[…]
Import-Package:org.apache.commons.logging,edu.emory.mathcs.backport.java.util.concurrent;resolution:=optional[…]

Export-Package:org.mypackage 라고 설정하면, org.mypackage에 있는 클래스들만 Export한다. org.mypackage.util에 있는 클래스들은 Export하지 않는다.

(패키지로 클래스를 Export 하는 거 말고 서비스를 Export/Import하는 설정은 왜 설명 안하지.. 그것도 많이 쓸텐데..)

Package consideration

export 할 떄는 별로 신경 쓸 것이 없는데,  import 할 때는 신경 쓸 께 좀 있다. 바로 어떤 구현체 어떤 버전을 사용할꺼냐는 것인데, logging(JDK 1.4것을 쓸꺼냐 Log4J를 쓸꺼냐),  정규표현식(Jakarta ORO를 쓸꺼냐 JDK 1.4+를 쓸꺼냐) 등등...

optional을 사용해서 패키지 가용 여부에 따라 사용하도록 설정할 수 있다. 즉 필수mandatory가 아니도록 설정할 수 있다.

예제
Import-Package: […]edu.emory.mathcs.backport.java.util.concurrent;resolution:=optional

여기서는 java.util.concurrent가 가용하면 그것을 쓰고, 만약에 없으면 없는대로 번들을 가동 시킨다.

OSGi에서는 같은 클래스가 서로 다른 버전으로 여러개 존재 할 수 있다. 따라서 Export/Import에 명시하는 모든 패키지명 뒤에 버전을 명시해주는 것이 좋다. 베스트 프랙티스다.

OSGi에서 버전은 다음과 같이 구성된다.

<major>, <minor>, <micro>, <qualifier> 알것으로 생각하고 생략...

명시하지 않았을 때, 기본 버전은 "0.0.0"다.

import 할 때 특정 범위의 버전을 명시하고 싶다면, [], (), (], [) 를 사용할 수 있다. [] 는 초과 미만, () 는 이하, 이상을 뜻한다. 수학에서 동그라미를 까맣게 칠한거랑 하얀거 차이. 하얀게 [], 까만게 ()

버전을 저렇게 표시하지 않고 하나만 달랑 표시하면, 그 버전 이상을 뜻하는 것이다.

예제
Import-Package: com.mypackage;version="1.2.3"
즉 이녀석은
Import-Package: com.mypackage;version="[1.2.3, ∞)"
이거랑 같다.


기네;; 한 번 끊어서 갑니다.
top


ControllerClassNameHandlerMapping 잘 되네~

모하니?/Coding : 2008.04.08 14:54


@Controller
public class MemberController {

    @Autowired
    private MemberService memberService;

    @RequestMapping
    public ModelAndView list(){
        return new ModelAndView("member/list")
            .addObject("members", memberService.getAll());
    }
}

요렇게만 해두면, /member/list.xxx 라는 요청이 오면 알아서(Conversion) 저 메소드가 처리하도록 합니다. ㄴXxx-servlet.xml에는 XML에는

<bean class="org.springframework.web.servlet.mvc.support.ControllerClassNameHandlerMapping" />

애만 등록해주면 됩니다. 저 한 줄의 XML로 URL 맵핑을 손수 적는 수고를 덜 수 있습니다.

계속해서 진화하는 Spring MVC 어디까지 갈텐가~~ 멋있어 멋있어 끝까지 가는거야~~

2008/04/08 - [모하니?/Coding] - ControllerClassNameHandlerMapping가 찾아 준댔는데...
ps : 새벽에 괜히 삽질만 하고... 잠이나 계속 잘껄..
top


ControllerClassNameHandlerMapping가 찾아 준댔는데...

모하니?/Coding : 2008.04.08 04:27


어젠가 오늘 배포된 Spring 2.5.3부터는 ControllerClassNameHandlerMapping의 기능이 확장되서, @Controller로 만든 컨트롤러들도 인식한다고 합니다.

ControllerClassNameHandlerMapping는 스프링의 막강한 CoC 기능 중에 하나로 매번 귀찮게 요청과 요청을 처리할 클래스 맵핑을 하지 않아도 되는 매우 편리한 클래스입니다.

@Controller를 사용하면, 요청을 처리할 클래스나 메소드 위에 @RequestMapping을 사용해서 요청 맵핑을 해야만 했는데, 이제는 저 클래스를 사용해여 Conversion을 적용하면 @RequestMapping을 일일히 안적어 주고, 메소드 이름을 요청의 이름이랑 맞춰주면 됩니다.

그러나.... 테스트 해봤더니 못 찾습니다. 에구구.. 다시 자야지.. 왜 안 돼지; 되면 정말 편한데..

2007/06/19 - [Spring/Chapter 13] - 13.11. Convention over configuration 1
2007/03/02 - [Hibernate/study] - Convention over Configuration




top


이외수의 생존법 하악하악

모하니?/Reading : 2008.04.07 18:21


사용자 삽입 이미지


아.. 오늘은 감기 때문에 하루종일 해롱거리다가 평소보다 일찍 퇴근하고 병원에 다녀왔습니다. 병원 가는 길에 "하악하악"을 집어들고 버스에서 읽었습니다. 정말 모든 글들이 하나같이 주옥같은 글들이었습니다.

책의 제목은 첨에 좀 두려웠습니다. 이걸 들고 다니면, 버스나 지하철에서 여자들이 날 뭐라고 생각할까. 변태라고 하진 않을까... 그래도 책이 재밌어서 들고나갔습니다. 그리고 읽어나갈 수록 남들의 시선은 별로 신경쓰지 않게 되었습니다. 오히려 제목이 정말 잘 어울린다는 느낌이 들더군요. "하악하악"보다 이 책을 읽으며 제가 느끼는 무언가 표현하기 힘든 이 생동감(?)을 정말 잘 대표하는 단어는 없겠다 싶을 정도입니다.

누군가 저에게 이 책의 제목만을 보고 뭐 이런 책을 읽냐고 물어본다면, 전 아무 페이지나 열어서 한 단락만 읽어보라고 권하고 싶습니다. 최고입니다.

맛보기로 아직 몇 페이지 안 읽었지만, 그 중에 가장 필이 꽂힌 명언은 다음과 같습니다. 소위 전문가라는 직종을 선택한 제 앞길에 반드시 명심하고 있어야 할 자세라는 생각이 들기 때문입니다.

"인간이라는 이름으로 살아가면서 진실을 못 보는 것은 죄가 아니다. 진실을 보고도 개인적 이득에 눈이 멀어서 그것을 외면하거나 덮어버리는 것이 죄일 뿐이다." -이외수 -

SES, 잭키, 핑클, HOT도 좋아하지 않던 내가. 할아버지의 팬이 되버리다니. 하하하핫..

'모하니? > Reading' 카테고리의 다른 글

TDDBE 2부 xUnit 실습  (0) 2008.09.08
도와주세요! 팀장이 됐어요  (0) 2008.08.25
내가 시집을 읽게 될 줄이야...  (4) 2008.08.05
불신자를 위한 JSF 시리즈  (0) 2008.07.22
Java Concurrency In Practice 번역서 등장  (0) 2008.07.18
이외수의 생존법 하악하악  (0) 2008.04.07
책 지름신 오셨네~  (0) 2007.12.26
Head First SQL  (4) 2007.12.21
읽을 책 정리  (2) 2007.12.21
괴짜경제학  (4) 2007.12.10
Head First OOAD 3,4장 요약  (0) 2007.12.09
top


이클립스 SVN 플러그인 Subversive 설치

Good Tools : 2008.04.04 22:52


참조 : http://www.eclipse.org/subversive/downloads.php

업데이트 사이트 두 개 추가.

Subversive plug-in
http://download.eclipse.org/technology/subversive/0.7/update-site/

Subversive SVN Connectors
http://www.polarion.org/projects/subversive/download/eclipse/2.0/update-site/

사용자 삽입 이미지
그림출처: http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/update_eclipse.php

끝!

'Good Tools' 카테고리의 다른 글

Terracotta  (2) 2008.05.19
SpringSource AMS 간단 사용기  (3) 2008.04.23
SpringSource Application Manager Suite  (2) 2008.04.22
Blip.tv 좋았어!!  (2) 2008.04.15
Commit comment template  (0) 2008.04.14
이클립스 SVN 플러그인 Subversive 설치  (2) 2008.04.04
Spring Tool Suite: Knowledge Base  (3) 2008.03.20
Maven + Clover  (1) 2008.03.18
Tomcat 6, MySQL에 JIRA(WAR/EAR 버전) 설치하기  (6) 2008.03.05
Bamboo 멋쟁이 - CI 와 테스트  (0) 2008.03.04
Eclipse의 막강한 Ctrl + h  (4) 2008.02.15
top


1장~6장 정리

AJAX/JavaScript : 2008.04.04 19:46


자바스크립트는 Unicode를 사용함.

대소문자를 가림. HTML은 대소문자를 안 가리는데..

공백 상관없음.

세미콜론 안 붙이면 알아서 붙인걸로 인식한다. 붙여주는게 좋음.

주석은 자바랑 같음.

변수명 규칙도 자바랑 같음.

세 가지 primitive 타입이 있음. number, string, boolean. 이 들의 Wrapper 클래스들 있다. AutoBoxing/unBoxing 해준다.

자바스크립트는 function도 Object. 따라서 메소드의 인자로 넘길 수도 있다.

Function 만들 때 Function Literal 형태로 만들 수 있다.
var square = function(x) { return x*x; }

Object 만들 때도 Literal 형태로 만들 수 있다.
var point = { x:2.3, y:-1.2 };

초기화 안 한 변수는 undefined.

변수를 선언한 위치에 따라 Scope이 결정되는데, local에서 var를 사용하지 않고 변수 선언하면 전역변수가 된다. 변수 선언은 항상 함수 맨 위에 하는 것이 좋고, var는 맨날 붙이는게 좋다.

==은 자바의 equals()랑 비슷하고, ===는 자바의 ==랑 비슷하다.

for/in 루프가 있군.

with라는게 있군.

'AJAX > JavaScript' 카테고리의 다른 글

1장~6장 정리  (0) 2008.04.04
자바스크립트 튜토리얼 정리 끝  (4) 2007.07.10
JavaScript Create Your Own Objects  (0) 2007.07.10
JavaScript Timing Events  (0) 2007.07.10
JavaScript Animation  (2) 2007.07.09
JavaScript Form Validation  (2) 2007.07.09
JavaScript Cookies  (0) 2007.07.09
JavaScript Browser Detection  (0) 2007.07.09
JavaScript HTML DOM Objects  (2) 2007.07.09
JavaScript Math Object  (0) 2007.07.09
JavaScript Boolean Object  (0) 2007.07.09
top


스프링 하이버네이트 사용시 insert 문은 안 날아가고 select만 될 때..

모하니?/Coding : 2008.04.02 08:29


Nontransactional 상태에서 SQL을 날리면 그런 일이 발생합니다.

하이버네이트는 Flush 시점에 꼭 필요한 SQL만 날립니다. 그 전에 프로그램에서 필요로 하는 데이터를 위한 SQL 역시 날아갑니다. 이것에 관한건 이전에 Flush에 관한 부분을 정리해두었으니 그 부분을 참조하시면 됩니다.

문제는, get() 류의 SQL들은 바로바로 날아가는데, insert와 update류의 SQL들은 바로 날아가지 않고 Persistence Context에 담겨 있다가 가장 나중에 Write behind 쓴다는 것입니다. 이 때, 만약 트랜잭션 경계를 지정해두지 않고 코딩을 했다면 문제가 복잡해 질 수 있습니다.

트랜잭션 범위를 명시적으로 정해주지 않으면, 사용하는 DB에 따라 동작하는 방식이 다른데, 오라클의 경우 트랜잭션 범위 없이 커넥션을 닫아버리면 그냥 커밋해버립니다. 다른 DB들은 롤백해버립니다. 오라클이 아닌 DB를 사용할 때는 결국 select문만 날아가고 insert 문이 안날아 가는 상황을 목격할 수 있습니다. 이것도 이렇게 단순한게 아닙니다. 주키 생성방식에 따라 insert문이 날아갈 수도 있고 안날아 갈 수 도 있습니다. 주키를 sequence를 사용해서 생성할 때에는 insert문이 날아가지 않고 sequence를 구해오는 SQL 함수만 호출합니다. 주키를 indentity 방식으로 생성할 때에는 insert문을 날려서 주키 값을 가져옵니다.

이렇게 복잡한 상황을 면하려면, 트랜잭션 경계를 잘 설정해 주어야 합니다. 스프링을 사용해서 가장 간단하게 트랜잭션 경계를 설정하는 방법은 다음과 같습니다.

1. sessionFactory 빈 등록
2. <context:annotation-config /> 추가.
3. 트랜잭션 경계가 되는 클래스 위에 @Transactional 애노테이션 붙이기

1, 2번은 간단합니다. 아주 쉽죠. 3번도 간단해보이지만 그렇게 간단하지 않습니다. 아니, 단일 클래스를 사용했을 때는 간단합니다. 그런데 최소한 인터페이스는 사용하겠죠. 그래서 다음과 같은 구조가 있다고 생각해 봅시다.
사용자 삽입 이미지

MemberService는 인터페이스고 그 아래는 그것을 구현한 클래스입니다. 둘 중 어디에 @Transactional을 붙여야 할까요? 스프링 팀은 Concrete 클래스에 @Transactional을 붙이는 것을 권장합니다. 그 이유는 스프링 AOP와 Proxy 그리고 애노테이션과 관련된 것인데, 생략하겠습니다. 암튼 Concrete 클래스에 붙이면 만사 OK 끝입니다.

그럼 인터페이스를 구현한게 아니라, 클래스 상속 구조에서는 @Transactional을 어디에 붙여야 할까요?

사용자 삽입 이미지

고민입니다. 어디에 붙여야 할지...
1. 일단 MemberServiceImpl에만 붙이면 안 됩니다. 그럼 AbstractMemberService에 있는 메소드들은 트랜잭션 경계를 설정하지 않은 꼴이 됩니다.

2. 그렇다고 AbstractMemberService에만 붙이자니 그것도 안 됩니다. MemberServiceImpl에만 있는 메소드들에는 마찬가지로 트랜잭션 경계를 설정해주지 않을 꼴이 되니까요.

3. 그럼.. AbstractmemberService와 MemberServiceImpl에 있는 모든 public 메소드에 @Transactional을 붙여줄까요? 이 애노테이션은 public 메소드 위에도 붙일 수 있습니다.(사실 모든 메소드 위에 붙일 수 있지만, public 메소드에만 트랜잭션 경계를 적용시켜주고 다른건 무시합니다.) 귀찮습니다. 메소드 추가할 때마다 애노테이션 한 줄씩 넣기가 귀찮습니다.

4. 그럼 두 개의 클래스 위에 다가 @Transactional을 붙여버리자!! 빙고.. 그런데 프록시 많이 사용하는건 그다지 성능에 안 좋지 않나. 게다가 프록시는 self-invocation문제도 있는데..

5. 그럼 @Transactional을 두 개의 클래스 위에 붙이고 Spring AOP말고 AspectJ를 써야겠다. 근데 AspectJ 사용이 2.5에서 편해지긴 했는데 여전히 뭔가 귀찮단 말이지..

여기까지가 고민의 끝입니다.
top


세상은 무섭다...

모하니?/Thinking : 2008.04.01 21:57


지난 일요일 정말 정말 오랜만에 친구 두 명을 만나서 저녁을 먹고 맥주 딱 한잔을 마셨습니다. 마시면서 그동안 어떻게 지내고 있는지, 세상은 어찌 돌아가는지 얘기를 들었는데 정말 놀라운 이야기를 들었습니다.

개성공단에 있던 사람들은 모두 내쫓고 서해바다에서 미사일을 쐈었다면서요? 헐.. 아니 제가 아무리 뉴스를 싫어한다지만, 요즘 뉴스 화두는 납치사건인걸로 알고 있습니다. 이게 도대체 세상이 어떻게 돌아가는 건지 모르겠습니다. 물론 납치사건도 흉흉합니다. 그런데 그런 사건이 평소에도 많을텐데 남북 불화를 이런식으로 언론에서 덮어버리는건지도 모르겠다는 생각입니다.

참 무섭습니다. 남한이랑 북한이 마치 남한과 일본같이 쌩판 상관없는 나라면 몰라도, 둘이 전쟁 중에 잠시 쉬고 있는 중인데 이렇게 막나가도 되는건지 모르겠습니다. 그동안 김대중 전 대통령과, 노무현 전 대통령이 북한에 방문했던 일을 물거품으로 만드는 일이 현 정부에서 발생한다면, 정말 이지... 무섭습니다.

전쟁이 날까봐 무서워서 섬뜩해져 보는게 국민학교 시절 이후 얼마만인지 모르겠습니다.


ps: 쒯... 공부할 것도 많은데 이딴 글이나 올리게 하다니.. 암튼 뉴스는 인생에 도움이 안 돼..

'모하니? > Thinking' 카테고리의 다른 글

Anyframe 보다가 흥분 해버렸네요.  (11) 2008.07.17
감독과 선수의 관계  (4) 2008.06.18
아.. 우울해..  (2) 2008.06.16
고객이 너무 바빠서 새로운 시스템에 적응할 시간조차 없다면  (0) 2008.06.11
한국 왜 이래...  (0) 2008.06.01
세상은 무섭다...  (0) 2008.04.01
IT 신조어가 필요한 시대  (0) 2008.03.28
바보  (2) 2008.03.25
블로그가 점점 이상해져가고 있습니다.  (15) 2008.03.21
헉.. 스팸이 아니였네;;  (8) 2008.03.15
My 2008 will be..  (0) 2008.02.06
top


하이버네이트에서 Nontransactional data access

Hibernate/Chapter 10 : 2008.04.01 17:11


Session session = sessionFactory.openSession();
session.get(Item.class, 123l);
session.close();
  1. Session이 열리고 이 순간 Connection을 얻어오진 않는다.
  2. get()을 호출하는 순간 Select 문을 날리는데, 이 때 Connection을 pool에서 꺼낸다. 하이버네이트는 기본으로 그 즉시 autocommit mode를 끈다. setAutoCommit(false). 이렇게 효율적으로 JDBC 트랜잭션을 시작한다.
  3. SELECT는 JDBC 트랜잭션 내부에서 실행된다. 하이버네이트는 Connection의 close()를 호출하여 Connection을 poll에 반납한다. 이 때 남아있는 트랜잭션은 어떻게 될까?
  • 사용하는 DB에 달려있다. JDBC 스펙에서는 이 것과 관련되서 정해논게 없다.
  • 오라클은 트랜잭션을 커밋한다.
  • 다른 많은 JDBC 밴더들은 트랜잭션을 롤백한다.
  • 위는 Select 문이라서 상관없지만, sequence를 가져온 다음에 INSERT은 날리지 않고 flush 될 때까지 기다린다. 그러다 그냥 끝나게 되니까 INSERT 문이 날아가지 않는다.
  • idendity 전략으로 PK를 생성할 때에는 DB에 들어가야 얻을 수 있으니까, INSERT문이 바로 날아간다.
  • 이렇게 트랜잭션 경계를 설정하지 않으면 위와 같은 일이 발생하는데, 이때에는 JDBC 커넥션을 오토커밋 모드로 설정해준다.
<property name="connection.autocommit">true</property>
  • 즉 DB Connection을 가져올 때 setAutoCommit(false) 이걸 호출하지 않는다.
top


autocommit에 관한 오해

Hibernate/Chapter 10 : 2008.04.01 17:11


트랜잭션 없이 쿼리를 날릴 수 있는가?

  • 트랜잭션 범위 밖에서 DB와 뭔가를 할 수가 없다. 불가능하다. 어떤 SQL 문도 DB 트랜잭션 밖에서 날릴 수는 없다.
  • nontransactional은 명시적인 트랜잭션 경계가 없다는 것이다. 시스템 트랜잭션이 없다는 것이다. 그렇게 하면 데이터에 접근할 때 autocommit 모드로 실행된다.

성능 향상

  • 잘 생각해봐야한다. 모든 SQL 문마다 트랜잭션을 열고 닫고 할 텐데 아마도 성능이 떨어질 것이다.

애플레이션 확장성 증가

  • 잘 생각해봐야한다. DB 트랜잭션이 길어지면 분명 락을 가지고 있는 시간이 길어지니까 확장성이 안 좋을 수 있다. 하지만 하이버네이트의 persistence context와 write-behind 특징을 생각해보면 모든 쓰기 락들은 매우 짧은 기간 동안만 가지고 있게 된다. isolation level을 높였을 때 사용하게 되는 읽기 락의 비용은 무시해도 좋은 수준이다. 아니면 아예 읽기 락이 아닌 multiversion concurrency를 지원하는 DB(오라클, PostgreSQL, Infomix, Firebird)를 사용하면 된다.

포기해야 하는 것들

  • SQL 문장들을 그룹핑하여 원자성을 보장하는 것이 불가능.
  • 데이터가 병렬적으로 수정될 때 isolation level이 낮아진다. repeatable read가 불가능하다.

Data Access Type

  • 보통의 트랜잭션
  • Read-only 트랜잭션
  • Nontransactional
top