아침에 사부님께서 링크를 줘서 들어가봤다가 깜짝 놀랬습니다.

http://www.springsource.com/training/spr001/icn20090302

한국에서 3월 2~5일까지 4일 과정으로 스프링 Core 교육을 합니다.
교육비는 호주 달러로 약 3000달러.. 현재 환율로 280만원 정도.

또 하나의 거대한 지름신이 유혹을 하네요. 저 떄 한국에 있을지 없을지도 모르는데 질러야 하나 말아햐 하나 고민입니다.

교육에 대한 자세한 설명은

http://www.springsource.com/training/spr001/syllabus

여기에 있습니다. 재밌는 건 Assumptions 인데..

We assume participants have a good understanding of the core Java APIs, as well as a basic knowledge of general J2EE concepts and APIs such as JTA and the Servlet API. As we cover object-relational mapping technologies (ORM) in this course as well, we assume basic knowledge of ORM concepts.

자바와 JEE 개념을 그렇다치고 ORM 기본 개념이 필요하다는 것 있다는 것과..
교육 과정 설명 중에 Hibernate란 단어가 대 여섯 번 정도 포함되어 있다는 것입니다.
그래서 인지 더욱 끌리네요~

Analysis and tradeoffs of relevant persistence strategies, including Hibernate and Spring JDBC
...
Understanding ORM and Hibernate with Spring
...

스프링소스의 정책이 바껴서 커뮤니티 버전은 직접 빌드를 해야합니다. S2DS라는 멋진 툴 한 번 돌려 보시려면 얼마나 귀찮으세요. Ant로 빌드해야 되는데, readme.txt도 안 읽어보면 어디가서 빌드해야 되는지도 잘 모르겠고, 잘 찾아가서 ant를 실행한다고 해도 OutOfMemory라도 만나는 날에는 정말이지.. 아휴~.

그래서 저희 OpenSprout에서는 다운로드 후 바로 실행해 볼 수 있는 S2DS를 제공하고 있습니다. 빌드하기 귀찮으신 분들에게 이 보다 더 좋은 서비스는 없을 겁니다. 그냥 한 번 빌드해서 실행보려고 해도 갑작스런 에러때문에 당황스러울 수 있는데요. 그런 에러까지 이미 제가 마루타 삼아 겪어보고 빌드했기 때문에 믿고 사용할 수 있는 배포판입니다.

OpenSprout 빌드 서비스. S2DS뿐 아니라, 앞으로 SpringSource 모든 제품을 빌드해서 제공해 드리겠습니다. 완전 사랑스럽죠? 헤헷

다운받고 -> 압축풀고 -> bin/start.sh 실행 -> localhost:8080 접속.


짝짝짝짝짝짝..

다운로드

참조 : http://blog.springsource.com/main/2008/04/29/web-applications-and-osgi/

왜 WAR를 OSGi에 배포하려는가?

쉬운 질문이군. OSGi는 기본적으로 버전잉과 패키지 엮기 그리고 핫 릴로딩을 지원한다. 여러분의 애플리케이션이 이런 장점들을 얻을 수 있다는 것을 상상해보라. .. 나머진 생략 ..

왜 웹 애플리케이션이 OSGi에서 문제가 되는가?

- Servlet 스펙은 웹 컨테이너를 기준으로 하고있다. 라이프 사이클 관리, 동시성, HTTP 요청 처리 등고 같은 표준 서비스를 제공하는 웹 구성요소다.
- OSGi 플랫폼은 서비스 레지스트리, 패키지 엮기, 버전잉과 같은 managed environment다.
- OSGI는 서블릿을 지원하기 위해 HTTP Service를 설계했다.
- 위의 API를 통해서 간단하게 서블릿을 등록할 수 있다.
- 서블릿이 OSGi 내부에서 요청을 처리하려면, 반드시 프로그래밍을 좀 해서programmatically 서블릿 객체를 만들고 적당한 API를 통해서 등록을 해야한다. 게다가 HTTP 서비스는 오직 서블릿 2.1 스펙만 지원한다.
- 이 문제를 다음과 같이 해결할 수 있다.
    - web.xml을 해석하는 등의 선언적인 방법을 통해서 코딩 줄이기
    - 표준 API를 확장하거나 2.1 API 위에 뭔가 더 만들어서 Servlet 2.1 이상의 기능을 제공하기
- Spring DM은 위와는 다르고 독특한 접근 방법을 체택했다.

웹 컨테이너를 직접 통합하기

- Spring-DM은 OSGi와 컨테이너 사이의 다리 역할을 한다.
- WAR를 그냥 컨테이너에 배포하듯이 배포하면 된다.
- OSGi와 컨테이너 둘 다 크게 변경될 것이 없다.
- Spring DM은 다음과 같은 것들을 지원한다.
    - 서블릿 2.4/2.5, JSP 2.0/2.1 스펙 지원
    - availability of the container capabilities (blocking vs non-blocking IO, allocated threads in the thread pool and so on)
    - web.xml 을 사용한다. 이걸 Spring DM이 파싱하는게 아니라 컨테이너에게 그 일을 위임한다. 원래 하던 녀석이 잘 할테니까..
    - 컨테이너 스펙 설정 파일(톰캣의 META-INF/context.xml 과 같은..)
- 현재 톰캣 5.5.x/6.0.x 와 제티 6.1.x 이상의 버전의 컨테이너를 사용할 수 있다.
- 웹 컨테이너가 웹 애플리케이션을 관리하고 컨테이너가 지원하는 모든 것들은 OSGi 번들들에게 가용하다.

1.1 최종판이 아직 발표되진 않았지만, M2를 접해보길 권장한다. 상당히 그대로 배포될 가능성이 많은 API들이며 새 기능들은 문서화해두었다. 도움이 필요하면 포럼으로 오고 메일링 리스트를 이용하라. 마지막으로 자바원에 온다면 SpringSource 부스에서 만나볼 수 있다.

ps: 알았다. 오바.

회사에서 돌려보려고 헀지만.. 일도 있고 저녁에 스타리그도 봐야해서 집에와서 스타 본다음에 돌려봤습니다. 돌리는 방법은 약간 복잡하지만, 제공해주는 기능에 비하면 간단한 것 같습니다.


대략 위와 같은 순으로 진행하면 됩니다.

참조
SpringSource Application Management Suite (AMS) Released
위 문서보다 좀 더 설치 방법에 대해 잘 설명한 페이지가 있었는데 링크를 못 찾았습니다. 흠..STS에 등록하는 화면 어딘가에서 링크를 타고 갔었던 것 같은데.. 기억이...

너무 간단한 걸 돌려봐서 그리 볼만한 데이터는 안나온 것 같습니다.

5번 과정을 마치고 나면 왼쪽 영역의 Recently Agent뭐시기가 한 줄 생깁니다. 참조의 링크에 저렇게 등록하는 방법이 설명되어 있습니다. 그냥 4번 과정에서 Agent만 실행하면 바로 등록되는게 아니라 Add to 머시기 버튼을 한 번 눌러줘야 합니다.

모니터링은 플랫폼(OS인듯..), 서버(현재 2개- 하나는 웹 애플 돌고 있는 서버, 하나는 AMS 서버), 그 위에 돌고 있는 서비스들.. 이렇게 구성되어 있는 듯 합니다.
복잡복잡..
다양한 종류의 리포트도 제공해주며.. SMTP를 설정해두면, 리포트를 메일로 보내주기도 한다는데 안 해봤습니다.

ps : 한글은 깨져요...OTL

이건 뭘까요?

일단 설치해 봤습니다. 내일은 회사에 가서 한번 설치해서 사용해봐야겠습니다.
이 녀석의 정체는 스프링 애플리케이션 관리자 스위트

참조 : 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

참조 : 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라고 설정해준다.

예제

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가 아니도록 설정할 수 있다.

예제

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

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

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

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

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

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

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

예제


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