Sun Developer Network 공식 블로그

수동으로 네트워크 설정하는 방법

(Sun) — Thu, 17 Dec 2009 15:43:36 +0900

수동으로 네트워크 설정하는 방법

Sun Wiki, 2009년 7월 14일

일반적으로 NWAM 서비스는 정상적으로 여러분의 네트워크 접속을 설정합니다. 이 글에서는 여러분이 예를 들어, 정적 IP 를 네트워크 인터페이스에 설정하고 싶은 경우 같이 접속을 수동으로 설정하는 방법에 대해 알아 봅니다. 이 과정은 유선 네트워크를 설정할때와 무선 네트워크를 설정할때 모두 적용 됩니다.

여러분은 네트워크 설정을 수동으로 할때 두가지 중에 한가지 방법을 택할 수 있습니다:

오픈솔라리스 GUI 를 이용해서
터미널 윈도우에서 커맨드를 이용해서

다음의 단계들이 오픈솔라리스 GUI 를 통해서 수행할 때 입니다.

Desktop 메뉴에서, System > Administration > Network 를 선택합니다.
자동으로 설정할지 수동으로 설정할지 물어 보는 프롬프트가 나타 납니다.
네트워크를 수동으로 설정하기 위해 적절한 옵션을 선택합니다.
NWAM 서비스는 비활성화 되어 있고 네트워크 설정 윈도우가 나타 납니다.
Network 설정 윈도우의 Connections 탭에서, 여러분이 설정하고자 하는 인터페이스에 따라서 다음중에 하나를 수행합니다:

만약 유선 네트워크 설정을 수동으로 설정하고자 할 경우에는, 유선 인터페이스를 선택하고 Properties 를 클릭합니다.
만약 무선 네트워크 설정을 수동으로 설정하고자 할 경우에는, 무선 인터페이스를 선택하고 Properties 를 클릭합니다.
각각의 인터페이스 속성 윈도우가 다음의 그림 처럼 나타납니다.

인터페이스 속성 창에서, 정적 IP 주소를 설정할지 혹은 DHCP 를 설정할지를 선택합니다.
해당 인터페이스를 시스템이 부팅될때 마다 활성화 하기 위해서 Activate on boot 를 선택합니다.
만약 정적 IP 주소를 설정한다면, IP 주소를, 서브넷 마스크, 게이트웨이 주소를 적절한 필드들에 입력하고 OK 를 클릭합니다.
호스트 이름을 설정하려면 General 탭을 선택해서 필요한 정보를 제공합니다.
DNS 설정을 위해서 DNS 탭을 누르고 필요한 정보를 제공합니다.
호스트 추가를 위해서 Hosts 탭을 누르고 필요한 정보를 제공합니다.
OK 를 클릭합니다.
(무선 네트워크 설정에만 적용) 접속하고자 하는 무선 네트워크를 선택합니다.
시작시에 무선 네트워크 접속하는 방법 을 보시기 바랍니다.

다음의 예제는 터미널 윈도우에서 커맨드를 입력하는 방법으로 수동으로 네트워크를 설정하는 예제를 보여드리고 있습니다. 커맨드는 권한이 부여된 쉘을 시작시키고, NWAM 서비스를 중지시키고, 정적 IP 주소를 선택된 유선 혹은 무선 인터페이스에 설정합니다. 이 예제는 유선 인터페이스를 사용합니다. 추가적으로 파라미터들은 설정 파일에 저장되서 영구적인 설정으로 사용할 수 있습니다.

다음의 예제는 호스트 이름이 sys001 이라고 가정합니다. 다음의 커맨드를 터미널 윈도우에서 입력합니다.

 
user@opensolaris:-$ pfexec bash
#
# svcadm enable network/physical:default 
# svcadm disable network/physical:nwam
#
# dladm show-phys
LINK        MEDIA        STATE     SPEED     DUPLEX     DEVICE
e1000g0     Ethernet     up        1000      full       e1000g0
e1000g1     Ethernet     down      1000      full       e1000g1
ath0        Wifi         up        1000      full       ath0
#
# ifconfig e1000g0 plumb 192.168.10.10/24 up
# ifconfig e1000g0
e1000g0: flags=201100843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6
        inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
        ether 2:8:20:b2:f1:76
#
# echo sys001 > /etc/hostname.e1000g0
# vi /etc/hosts
...
192.168.10.10   sys001   loghost
#

만약 무선 네트워크를 설정한다면, 다음의 추가 작업을 수행합니다.

 
# dladm scan-wifi
LINK     ESSID     BSSID/IBSSID          SEC      STRENGTH      MODE     SPEED
ath0     net1      00:0e:38:49:01:d0     none     good          g        54Mb
ath0     net2      00:0e:38:49:02:f0     none     very weak     g        54Mb
ath0     net3      00:0d:ed:a5:47:e0     none     very good     g        54Mb
#
# dladm connect-wifi -e net3
# dladm show-wifi
LINK       STATUS        ESSID     SEC     STRENGTH   MODE   SPEED
ath0       connected     net3      none    very good  g      54Mb

필요로하는 다른 네트워크 설정 작업들을 수행 합니다.
예를 들어 만약 라우터가 존재한다면 라우터의 IP 주소를 /etc/defaultrouter 파일에 설정합니다. 만약 네이밍 서비스를 이용한다면 네이밍 서비스의 설정 파일을 복사 합니다. 예를 들어 /etc/nsswitch.dns 를 /etc/nsswitch.conf 로 복사합니다.

좀 더 자세한 정보는 다음의 링크를 참조하시기 바랍니다:

[원문]
How to Manually Configure Network Settings
http://wikis.sun.com/display/opensolari ··· settings

"오픈솔라리스" 카테고리의 다른 글

수동으로 네트워크 설정하는 방법 (댓글 0개 / 트랙백 0개) 2009/12/17
Indiana 란 무엇이고 어떻게 참여할 수 있나요? (댓글 0개 / 트랙백 0개) 2008/04/17
Xen: 다운로드, 설치 및 설정 정보 (댓글 0개 / 트랙백 0개) 2008/01/21
존 클로닝하기 (댓글 0개 / 트랙백 0개) 2009/08/27
오픈솔라리스에서 복수개의 부트 환경 구성하기 (댓글 0개 / 트랙백 0개) 2009/01/16
향상된 리소스 관리 및 존 통합 (댓글 0개 / 트랙백 0개) 2008/06/16
오픈솔라리스 Bug 보고하기 (댓글 0개 / 트랙백 0개) 2009/12/17
리눅스 가이가 썬에서 무슨 일을 하고 있나요? (댓글 1개 / 트랙백 0개) 2008/05/19
Inside OpenSolaris: 솔라리스 드라이버 프로그래밍 Part 2 of 2 (댓글 1개 / 트랙백 0개) 2006/05/23
OpenSolaris Project: Visual Panels (댓글 0개 / 트랙백 0개) 2007/10/22

오픈솔라리스 Bug 보고하기

(Sun) — Thu, 17 Dec 2009 15:42:29 +0900

오픈솔라리스 Bug 보고하기

Brian Leonard, 2009년 11월 16일

오픈솔라리스 유저로써, 커뮤니티에 기여할 수 있는 가장 최고의 방법은 제품에서 찾은 버그들을 제출하는데에 시간을 사용하는 일일 것입니다. 여러분은 아마 동일한 이슈를 포럼에 제기하는 것보다 훨씬 더 나은 오픈솔라리스 엔지니어링 팀의 주목을 받게 될 것입니다 - 버그의 갯수는 주단위로 리뷰 되지만 포럼의 글은 그렇지 않기 때문입니다.

오픈솔라리스 프로젝트는 버그질라 를 추적 시스템으로 사용하고 있으며 홈페이지는 http://defect.opensolaris.org 입니다. 참고로 해당 시스템은 opensolaris.org 와 분리된 등록 데이타베이스를 사용하고 있으므로, 반드시 새로운 계정을 생성 하셔야 합니다.

버그를 등록하기 전에 먼저 검색을 해서 이미 추적되고 있는 버그 인지를 확인합니다. 만약 그렇다면, 추가적인 정보를 더하시거나, 여러분 자신을 버그의 참조자로 등록해서 그것에 진행상황에 대한 알림을 받으시기 바랍니다. 예를 들어 저는 제 자신을 참조로 약 140건의 버그들에 등록하였습니다.

Advanced search 폼은 매우 강력 합니다, 그러나 한편으로는 위압적이기도 합니다. 저는 주로 홈페이지 의 단순 문자 검색 폼을 주로 이용합니다. 여기서 단순 문자 검색에서 최고의 결과를 이끌어 낼 수 있는 몇가지 기본 팁들을 알려 드립니다:

기본적으로, 오직 오픈된 버그들 만이 표시 됩니다. 여러분이 찾고 있는 버그가 이미 개발 빌드에서 수정되었을 수도 있기 때문에, 여러분의 검색의 앞부분에 ALL 을 붙입니다, 예를 들어, ALL mouse wheel.
대소문자에 연연하지 않습니다 - table, Table 과 TABLE 은 모두 동일합니다.
서브스트링들은 검색됩니다. - 그러므로 localize 혹은 localization 로 검색하는 대신에 두개 단어에서 모두 나타나는 localiz 를 대신 사용합니다.
정확한 단어 혹은 구문 검색을 위해서 따옴표를 이용 합니다.

버그질라 QuickSearch 페이지에서 더 많은 팁들을 확인하시기 바랍니다.

여러분은 검색 결과의 가장 하단에서 "Remember search as" 옵션이 있음을 보실 수 있습니다:

이것은 매우 간편합니다. 특히 여러분이 advanced search 를 하고자 시간을 보낼때에 더 그렇습니다. 저장된 검색들은 페이지의 하단에 링크로써 설정 가능합니다. 위의 이미지에서 여러분은 현재 제가 2개의 검색을 저장하고 있음을 보실 수 있습니다:"My Bugs" 와 "My CC'd Bugs".

여러분이 찾은 버그가 아직 제출되지 않았음을 충분히 확신한 다음에는, 홈페이지 에서 File a Bug 버튼을 클릭합니다. 여러분은 분류를 선택하기를 요구 받는데 여기서 Distribution 을 고르시면 됩니다.

이 것은 버그 폼을 입력하는 화면으로 여러분을 안내 합니다:

여러분의 문제와 가장 가까운 Component 를 선택합니다. 여러분이 컴포넌트를 고르면, 오른쪽의 문자열 박스에 그에 대한 설명을 보실 수 있습니다. 만약 여러분이 확신이 들지 않는다면, 검색했을때 찾았던 것들과 유사한 버그들을 살펴 보시기 바랍니다. 잘못된 분류에 대해서 걱정하지 마시기 바랍니다 - 이것은 수정될 것입니다.

여러분이 사용하고 있는 오픈솔라리스의 Version 을 선택한 다음, Severity 를 선택합니다. 비록 모든 버그들이 여러분이 느끼기에는 미션크리티컬을 방해하는 것이라고 느끼시겠지만, 최대한 현실에 맞게 선택해 주시기 바랍니다:

Blocker	개발 그리고/혹은 테스팅 작업을 방해함
Critical	크래시, 데이타 손실, 심각한 메모리 누수
Major	주요한 기능 상실
Normal	일반적인 이슈, 특정 조건하에 몇가지 기능 상실
Minor	마이너한 기능 상실 혹은 간단한 워크어라운드가 존재하는 상황에서 또 다른 문제
Trivial	잘못된 스펠링이나 잘못 배치된 문자열 같은 문제
Enhancement	기능 향상 요청

Enhancement 값을 참고하시기 바랍니다. 저는 제품에서 앞으로 보고 싶은 기능들을 요청하기 위해 이것을 많이 사용했습니다.

두가지 가장 중요한 필드는 Summary 와 Description 입니다. 잘 정리된 요약은 빠르게 그리고 유일무이한 버그를 찾아 줄 것입니다. 요약 필드에 최대한 많은 요약을 제공 해 주시기 바랍니다, 이상적으로 버그를 재현해볼 수 있는 정확한 단계를 제공하고 여러분이 발견한 가능한 워크어라운드를 제공하는 것입니다(문서화된 워크어라운드가 버그 데이타베이스를 검색함으로써 얻을 수 있는 가장 큰 이득중에 하나 입니다). 마지막으로 Description 필드를 많은 양의 출력 결과 혹은 로그 문자로 어지럽히지 마시기 바랍니다. 대신에, 첨부 버튼을 이용해서 텍스트 혹은 로그를 첨부하시기 바랍니다. 마찬가지로 여러분은 문제의 스냅샷을 떠서 첨부하실 수 있습니다 (스크린샷 툴이 Applications > Graphics > Save Screenshot 에 존재합니다).

버그 작성 가이드라인 에서 좀 더 자세한 정보를 살펴보시기 바랍니다.

모든 것이 만족되면 Commit 을 눌러서 여러분의 버그를 제출하시기 바랍니다. 그리고 감사합니다! 여러분은 방금 오픈솔라리스에 가치 있는 공헌을 하셨습니다.

[원문]

Defects

http://blogs.sun.com/observatory/entry/defects

"오픈솔라리스" 카테고리의 다른 글

수동으로 네트워크 설정하는 방법 (댓글 0개 / 트랙백 0개) 2009/12/17
Indiana 란 무엇이고 어떻게 참여할 수 있나요? (댓글 0개 / 트랙백 0개) 2008/04/17
Xen: 다운로드, 설치 및 설정 정보 (댓글 0개 / 트랙백 0개) 2008/01/21
존 클로닝하기 (댓글 0개 / 트랙백 0개) 2009/08/27
오픈솔라리스에서 복수개의 부트 환경 구성하기 (댓글 0개 / 트랙백 0개) 2009/01/16
향상된 리소스 관리 및 존 통합 (댓글 0개 / 트랙백 0개) 2008/06/16
오픈솔라리스 Bug 보고하기 (댓글 0개 / 트랙백 0개) 2009/12/17
리눅스 가이가 썬에서 무슨 일을 하고 있나요? (댓글 1개 / 트랙백 0개) 2008/05/19
Inside OpenSolaris: 솔라리스 드라이버 프로그래밍 Part 2 of 2 (댓글 1개 / 트랙백 0개) 2006/05/23
OpenSolaris Project: Visual Panels (댓글 0개 / 트랙백 0개) 2007/10/22

맥 OS X(호스트) 와 오픈솔라리스(게스트) 간 데이타 공유하기

(Sun) — Thu, 17 Dec 2009 15:39:38 +0900

맥 OS X(호스트) 와 오픈솔라리스(게스트) 간 데이타 공유하기

Sriram Natarajan, 2009년 7월 17일

썬 xVM Virtual Box 는 여러분이 여러분의 랩탑에서 오픈솔라리스 를 실행할 수 있도록 도와 줍니다(그리고 공짜 입니다!). 그러나 꽤 오랜시간동안, Virtual Box 는 여러분의 호스트(MacOS X/리눅스/윈도우즈) 와 오픈솔라리스 게스트 간의 데이타를 공유할 수있는 간편한 방법을 제공해 주지 않았었습니다. 마침내 오랜 기다림 끝에 썬 xVM Virtual Box 는 이 둘간에 데이타 공유를 할 수 있는 기능을 제공하게 되었습니다.

이 글에서는 제가 어떻게 공유를 했는지에 대해서 설명드립니다.

여러분의 포스트 머신(Mac OS X 혹은 윈도우)에서 게스트 이미지의 Virtual Box 설정을 열어서, Shared Folders 를 클릭하고 여러분이 공유하고자 하는 위치를 선택하여 공유 합니다.

.

이제 오픈솔라리스를 게스트로서 부팅 시키고 새로운 게스트 Addition 을 추가시켜줘야 합니다. 방법은 아래와 같습니다.

a) 최상의 Virtual Box 메뉴에서 Devices 를 클릭하고 그 다음에 Install Guest Additions 를 클릭합니다. 이것은 Virtual Box 가 게스트 addition ISO 이미지를 마운트 하도록 합니다.

b) 이제 커맨드 라인 터미널을 열어서 새로운 게스트 addition 을 설치 합니다.

새로운 버전의 게스트 addition 을 설치 하기 전에, 시스템에 기존에 설치한 버전이 있는지 확인 해 봅시다.
- sriramn@opensolaris:-~$> pfexec pkginfo -i | grep SUNWvboxguest
- 만약 위의 커맨드가 어떠한 출력이라도 리턴해 준다면, 여러분은 이전의 게스트 addition 을 다음과 같이 제거 시켜주어야 합니다 :
- sriramn@opensolaris:-~$> pfexec pkgrm SUNWvboxguest

이제 여러분은 최신 Virtual Box 게스트 addition 패키지를 설치해야 합니다. 설치를 위해서는 'Install Guest Additions..' 을 VirtualBox -> Devices 메뉴 에서 선택합니다.
- sriramn@opensolaris:-~$> pfexec pkgadd -d /media/VBOXADDITIONS*/VBoxSolarisAdditions.pkg

c) 여러분의 설정에 따라서 오픈솔라리스 게스트를 재부팅 시켜줘야 합니다.

만약 오픈솔라리스를 여러분의 랩탑에서 최초로 시도해보려고 한다면, Virtual Box 가 최고의 방법입니다.

d) 마지막으로 다음의 커맨드들을 오픈솔라리스에서 입력함으로써 여러분의 호스트로부터 공유를 위해 지정했던 위치를 마운트 하도록 합니다(필자의 경우는 Mac OS'의 ~/Public 이였습니다) 아래와 같이 진행하였습니다.

또한 여러분이 이 특정 장소를 오픈솔라리스 게스트를 부팅할때마다 마운트 하길 원한다면 아래의 라인을 여러분의 /etc/vfstab 밑에 삽입합니다.

이제 여러분은 여러분의 오픈솔라리스(게스트)에서 어떠한 파일이라도 호스트 머신에 복사 하려면, 단순히 다음의 커맨드를 사용 하시면 됩니다.

sriramn@opensoaris:~$ pfexec cp ~/Documents/foo /Public/Drop\ Box/

이 글이 여러분에게 유용했기를 바랍니다.

"오픈솔라리스" 카테고리의 다른 글

수동으로 네트워크 설정하는 방법 (댓글 0개 / 트랙백 0개) 2009/12/17
Indiana 란 무엇이고 어떻게 참여할 수 있나요? (댓글 0개 / 트랙백 0개) 2008/04/17
Xen: 다운로드, 설치 및 설정 정보 (댓글 0개 / 트랙백 0개) 2008/01/21
존 클로닝하기 (댓글 0개 / 트랙백 0개) 2009/08/27
오픈솔라리스에서 복수개의 부트 환경 구성하기 (댓글 0개 / 트랙백 0개) 2009/01/16
향상된 리소스 관리 및 존 통합 (댓글 0개 / 트랙백 0개) 2008/06/16
오픈솔라리스 Bug 보고하기 (댓글 0개 / 트랙백 0개) 2009/12/17
리눅스 가이가 썬에서 무슨 일을 하고 있나요? (댓글 1개 / 트랙백 0개) 2008/05/19
Inside OpenSolaris: 솔라리스 드라이버 프로그래밍 Part 2 of 2 (댓글 1개 / 트랙백 0개) 2006/05/23
OpenSolaris Project: Visual Panels (댓글 0개 / 트랙백 0개) 2007/10/22

MySQL Innodb ZFS 베스트 프랙티스

(Sun) — Thu, 17 Dec 2009 15:35:16 +0900

MySQL Innodb ZFS 베스트 프랙티스

NEELAKANTH NADGIR, 2009년 5월 26일

ZFS 상에서 실행되는 MySQL 퍼포먼스를 얘기할 때 가장 멋진 것은 거의 튜닝할 부분이 없다는 것입니다. 보통 ZFS 를 튜닝 하는 것은 악으로 간주 됩니다. 그러나 종종 필요할 때도 있습니다. 이 글에서는 ZFS 에서 좀 더 좋은 퍼포먼스를 이끌어 낼수 있는 튜닝 포인트와 몇가지 퍼포먼스 버그들에 대해 지적할 것입니다. 이러한 버그들은 수정이 이루어 졌을때 제시해 드린 튜닝은 필요 없어질 것입니다.

참을성이 부족한 분들을 위해서 요약본을 먼저 제시해 드립니다. 이러한 권고사항과 관련된 이유들은 아래에서 확인하시기 바랍니다.

ZFS recordsize 를 이노디비 페이지 사이즈와 일치 시킵니다 (이노디비 데이타파일들은 16KB, 로그파일들은 128KB)
만약 쓰기 작업이 많은 워크로드라면, Separated ZFS Intent Log 를 유지 합니다.
만약 데이타베이스 워킹 셋 사이즈가 메모리에 맞지 않는다면, SSD 를 L2ARC 로 사용함으로써 큰 이득을 얻으실 수 있습니다.
배터리에 의해 백업되는 캐시를 가진 스토리지 디바이스를 사용하거나 ZFS 를 다른 파일 시스템들과 비교할때 캐시 flush 를 끕니다.
ZFS Adaptive replacement cache(ARC) 대신에 MySQL/이노디비 캐시를 사용합니다.
ZFS prefetch 를 끕니다.
이노디비 double write buffer 를 끕니다.

각각의 항목을 자세히 살펴 봅시다.

What	ZFS recordsize 를 이노디비 페이지 사이즈와 일치 시킵니다 (이노디비 데이타파일들은 16KB, 로그파일들은 128KB)
How	`zfs set recordsize=16k tank/db`
Why	퍼포먼스의 가장 큰 이득은 ZFS 레코드 사이즈를 IO 의 사이즈와 일치 시킴으로써 얻을 수 있습니다. 이노디비 Page 는 16KB 이고 대부분의 읽기 IO 가 16KB 사이즈 (몇몇 합쳐질 수 있는 prefetch IO 를 제외한) 이기 때문입니다. ZFS 의 기본 레코드 사이즈는 128KB. 입니다. 읽기 사이즈와 ZFS 레코드 사이즈의 불일치는 심한 IO 를 유발할 수 있습니다. 만약 16KB 읽기 작업을 수행하고 해당 데이타가 ARC 에 아직 존재하지 않는다면 데이틀 얻기 위해서 128KB 를 읽어야 합니다. ZFS 는 작은 읽기 작업을 수행할 수 없습니다. 왜냐하면 체크섬이 전체 블럭에 의해서 계산되기 때문에 데이타의 무결성을 검증하기 위해서 모두 읽어 들여야 합니다. IO 사이즈와 ZFS 레코드 사이즈를 일치 시키는 또 다른 이유는 읽기-수정-쓰기 패널티 때문입니다. ZFS 레코드 사이즈가 128KB 이고 이노디비가 페이지를 수정할때, 만약 ZFS 레코드가 아직 메모리에 존재하지 않는다면 해당 데이타는 디스크로 부터 읽어져야 하고 디스크에 쓰기 전에 수정되어야 합니다. 이것은 IO 레이턴시를 크게 증가시킬 수 있습니다. ZFS 레코드 사이즈와 IO 사이즈를 일치 시킴으로써 이러한 문제를 없을 수 있습니다. 이노디비 로그 파일들은 쓰기 작업이 보통 순차적으로 이루어 지고 사이즈도 다양합니다. 기본적으로 ZFS 레코드 사이즈 128KB 를 사용함으로써 읽기-수정-쓰기 작업의 비용을 줄일 수 있습니다.
Note	데이타베이스 파일을 생성하기 전에 레코드 사이즈를 지정해 주어야 합니다. 만약 이미 파일들을 생성하였 다면 파일들이 새로운 레코드 사이즈를 얻을 수 있게 복사해 주어야 합니다. `stat(2)` 커맨드를 이용해서 레코드 사이즈를 조사해 보실 수 있습니다 (`IO Block:`)

What	만약 쓰기 작업이 많은 워크로드라면, Separate ZFS Intent Log 를 유지 합니다.
How	`zpool add log c4t0d0 c4t1d0`
Why	쓰기 레이턴시가 다수의 MySQL 워크로드에서는 아주 중요합니다. 일반적으로 쿼리는 몇몇 데이타를 읽고 계산을 하고, 데이타를 업데이트를 한 다음에 트랜잭션을 커밋 합니다. 커밋을 위해서 이노디비 로그가 수정 됩니다. 많은 트랜잭션들이 동시에 커밋될 수 있습니다. 커밋에 대한 이러한 "대기" 시간이 짧은 것이 중요 합니다. ZFS 에서는 동기화 쓰기가 Separate Intent Log 를 사용함으로써 빨라질 수 있습니다. Sysbench 읽기-쓰기 로 테스트 한 결과 약 10-20% 정도의 속도 향상을 얻을 수 있었습니다.(slog)
Note	만약 여러분의 쿼리 실행이 디스크에서의 물리적인 읽기가 수반된다면 쓰기 시간은 별로 중요하지 않을 수 있습니다. 이 제안을 반드시 여러분의 실제 워크로드에서 테스트해 보시기 바랍니다. Bug 6574286 이 수정될때 까지 여러분은 slog 를 제거하실 수 없습니다. 이노디비는 사실 여러가지 종류의 쓰기 작업을 수행 합니다 (로그 쓰기, 데이타스페이스 쓰기, 삽입 버퍼 쓰기) slog 기능은 풀 전체에서 사용가능하고 그러므로 몇몇 쓰기 (데이타스페이스 쓰기) 같이 slog 로 가지 않아야 할 것들도 가게 됩니다. 이것은 Bug 6832481 ZFS separate intent log bypass property 에 의해서 수정될 수 있습니다. 또한 ZFS 트랜잭션 싱크 타임 동안에 ZFS IO 큐(35 deep) 또한 꽉 찰 수도 있습니다. 이것은 쓰기가 슬롯이 빌때 까지 기다려야 한 다는 뜻입니다. Bug 6471212: need reserved I/O scheduler slots to improve I/O latency of critical ops 가 예약된 슬롯을 사용하여 해결 합니다. Bug 6721168 slog latency impacted by I/O scheduler during spa_sync 또한 확인할 가치가 있습니다.

What	L2ARC (혹은 Level 2 ARC)
How	`zpool add cache c4t0d0`
Why	만약 여러분의 데이타베이스가 메모리에 잘 맞지 않는다면, 여러분이 데이타베이스 캐시를 미스할때 마다 디스크에서 블럭을 읽어와야 합니다. 이러한 비용은 일반적인 디스크에서 상당히 높습니다. 데이타베이스 캐시 미스 레이턴시는 한개 혹은 여러개의 SSD 를 레벨-2 캐시 혹은 L2ARC 로 사용함으로써 줄이실 수 있습니다. 여러분의 데이타베이스 워킹 셋 사이즈에 따라서 메모리와 L2ARC 사이즈는 성능에서 몇수십배의 차이를 보실 수 있습니다.
Note

What	안전한 경우에는 ZFS 캐시 flush 를 끕니다
How	ZFS Evil tuning guide 는 이 파라미터에 대한 더 자세한 정보를 제공합니다. 해당 문서를 참고하시기 바랍니다.
Why	ZFS 는 디스크 및 캐시와 함꼐 안정적으로 동작하도록 디자인 되었습니다. 데이타가 디스크에 저장이 필요할때 마다 ZFS 는 캐시 flush 커맨드를 디스크에 내립니다. 배터리에 의해 백업되는 캐시를 가진 디스크들은 어떠한 작업도 수행할 필요가 없습니다(참고로 캐시 flush 커맨드는 nop 입니다) 많은 스토리지 디바이스들이 이것을 올바르게 해석하고 올바르게 작업을 수행합니다. 그러나 몇몇 스토리지 시스템들은 여전히 캐시 flush 커맨드를 올바르게 해석하지 못합니다. 이러한 스토리지 시스템들에서 ZFS 가 캐시 flush 커맨드를 내리지 못하도록 막는 것은 IO 레이턴시를 크게 줄이는 효과를 얻을 수 있습니다. Sysbench 읽기-쓰기 테스트에서 약 30% 정도의 퍼포먼스 향상을 볼 수 있었습니다.
Note	배터리로 백업되지 않는 캐시에서 이 튜닝값을 사용하는 것은 오류시에 일관성을 훼손시킬 수 있습니다. ZFS 를 쓰기 캐시가 안보기에 활성화 되어 있는 파일 시스템들과 비교할때, 공정한 비교를 위해서 반드시 이 옵션을 사용하시기 바랍니다.

What	ZFS Adaptive replacement cache(ARC) 대신에 MySQL/이노디비 캐시를 사용합니다.
How	my.cnf 를 통한 설정 그리고 ARC 사이즈를 제한
Why	여러분이 MySQL/이노디비를 ZFS 와 사용할 때에는 복수의 캐싱레벨을 가지게 됩니다. 이노디비는 고유의 버퍼 풀을 가지고 있고 ZFS 는 ARC 를 가지고 있습니다. 두가지 모두 각각 어떤것을 캐시 하고 flush 할지 독립적으로 결정을 내리게 됩니다. 두개 모두 동일한 데이타를 캐시할 경우도 존재합니다. 이노디비 내부의 캐시를 통해서 여러분은 좀 더 짧은(그리고 빠른) 코드 경로로 데이타에 접근하실 수 있습니다. 또한 이노디비 버퍼 캐시가 꽉 찼을때, 이노디비 버퍼 캐시에 대한 미스는 ARC 에 데이타가 캐시되어 있더라도 더티 버퍼의 flush 를 유발합니다. 이것은 불필요한 쓰기 작업을 유발합니다.. 비록 ARC 가 메모리에 대한 압력에 따라서 동적으로 줄어들고 늘어나지만, 가장 효과적인 것은 단순히 그것을 제한 하는 것입니다. 저희는 보통 (7~200%) 정도 ZFS 보다 이노디비에 캐싱 하는 것이 빠르다는 것을 발견 하였습니다
Note	ARC 는 모든 데이타, 단순히 메타 데이타 혹은 파일시스템 기반에서 아무런 데이타도 캐싱하지 않도록 튜닝될 수 있습니다. 아래의 튜닝 조언을 참고하시기 바랍니다.

What	ZFS prefetch 를 끕니다.
How	`/etc/system:` set zfs:zfs_prefetch_disable = 1
Why	대부분의 파일시스템은 prefetch 같은 종류를 구현합니다. ZFS prefetch 는 선형적인 (증가 혹은 감소하는), 스트라이드, 멀티블럭 스트라이드 IO 스트림을 감지하고 퍼포먼스에 이득이 있다고 판단되면 prefetch IO 를 수행 합니다. 이러한 prefetch IO 는 일반적인 읽기 보다 낮은 우선순위를 가지고 있고 일반적으로 잇점이 있습니다. ZFS 는 또한 낮은 수준의 prefetch( 일반적으로 vdev prefetch 라고 불림) 기능을 통해서 데이타의 공간적인 지역성을 도와줄 수 있습니다. 이노디비에서 행들은 프라이머리 인덱스의 순서에 따라서 저장됩니다. 이노디비는 두 종류의 prefetch 요청을 수행합니다; 하나는 순차적인 페이지를 접근할때 발생되고 다른 하나는 익스텐트 안에서 랜덤액세스에 의해서 발생합니다. prefetch IO 명령을 내릴때 이노디비는 파일이 프라이머리 키 순서대로 배치되어 있다고 가정합니다. ZFS 에서는 그렇지 않습니다. 저희들은 여전히 이노디비 prefetch 에 대한 영향도를 조사하고 있습니다. OLTP 워크로드에서 데이타를 랜덤한 순서대로 읽는 다는 것은 잘 알려진 사실입니다. 그래서 prefetch 로는 이득을 얻기 힘듭니다. 그러므로 저희들은 ZFS prefetch 를 끄기를 권고 합니다
Note	만약 여러분이 프라이머리 캐시 전략을 단순 메타데이타 캐시로 변경하였다면 파일 레벨 prefetch 를 수행하지 않을 것입니다. 만약 레코드 사이즈를 16K 로 설정했다면 하위 레벨 prefetch 를 수행하지 않을 것입니다.

What	이노디비 double write buffer 를 끕니다.
How	`skip-innodb_doublewrite` in my.cnf
Why	이노디비는 테이블스페이스 내의 페이지들을 안전하게 업데이트 하기 위해서 double write buffer 를 사용 합니다. 이노디비는 먼저 변경사항을 이 버퍼에 쓰고 그 다음에 데이타 페이지에 씁니다. 이것은 부분적인 쓰기를 막기 위해서 입니다. ZFS 는 부분쓰기를 허용하지 않기 때문에 여러분은 안전하게 이 옵션을 끄실 수 있습니다. 저희들의 테스트에서 약 5% 정도의 성능 향상을 얻었습니다.
Note

[원문]

MySQL Innodb ZFS Best Practices

http://blogs.sun.com/realneel/entry/mys ··· ractices

"관리자코너" 카테고리의 다른 글

맥북 13인치 코어 2 듀오에 솔라리스10 설치하기 (댓글 2개 / 트랙백 0개) 2008/06/16
썬 버추얼 데스크탑 커넥터 1.0(베타)을 사용한 VDI 데모 구축 (댓글 0개 / 트랙백 0개) 2008/01/23
솔라리스 Tip Of The Week:SMF (댓글 0개 / 트랙백 0개) 2009/01/23
GlassFish 를 프로덕션 환경으로 설치하기 (댓글 0개 / 트랙백 0개) 2009/11/23
솔라리스 레디 애플리케이션 및 솔루션 (댓글 0개 / 트랙백 0개) 2008/03/13
솔라리스 10 에서 TCP Wrapper 사용하기 (댓글 1개 / 트랙백 0개) 2006/01/23
시만텍 베리타스 넷백업과 ZFS 스냅샷 통합하기 (댓글 0개 / 트랙백 0개) 2009/07/17
ZFS, 썬의 최신 파일 시스템(Part 1: 스토리지 무결성, 보안성 및 확장성) (댓글 3개 / 트랙백 1개) 2006/11/23
USB로 부팅하기 - 설치 (댓글 31개 / 트랙백 1개) 2007/08/20
파일과 디렉토리를 안전하게 옮기거나 카피 할 수 있는 방법 (댓글 6개 / 트랙백 0개) 2007/04/23

IBM HS22 Type 7807 블레이드서버에 솔라리스10 5/09 를 설치하는 워크어라운드

(Sun) — Thu, 17 Dec 2009 15:30:47 +0900

IBM HS22 Type 7807 블레이드서버에 솔라리스10 5/09 를 설치하는 워크어라운드

Jonathan O'Brien 과 Lee Damico, 2009년 9월 8일

설명

IBM HS22 Type 7870 블레이드 서버는 Matrox G200eV 그래픽 코어를 사용합니다. 이 시스템에서, 솔라리스10 5/09 버전을 부팅 혹은 설치 할때 GUI 를 사용하려고 시도 하면, Xorg 와 dtlogin 이 실행중이더라도 공백 혹은 깨진 화면이 나타나게 됩니다. 텍스트 모드에서는 정상적으로 동작합니다. 이 문제는 아래의 버그에 정리되어 있습니다:

 
CR 6826364 Xorg dtlogin doesn't display on IBM HS22 blade with MGA G220eV

mga 드라이버 1.4.10 버전이 이 문제를 해결해 줍니다. 이 수정된 드라이버는 솔라리스10 의 다음 업데이트 버전에 포함될 예정이고 현재 Patch ID 125270-32 로써 사용 가능합니다. 패치를 적용한 다음에, 시스템은 반드시 재부팅 되어야 하고, 아마도 올바른 동작을 위해서는 전원을 내렸다 올려 줘야할 것입니다. 자세한 정보 및 이 문제와 관련하여 발생할 수 있는 다른 문제들은 이후에 섹션들에서 문서화 되어 있습니다.

워크어라운드

시스템이 여전히 텍스트 모드로 접근 가능하더라도, GUI 기능에 대한 워크어라운드가 존재하지 않습니다. 만약 GUI 기능이 요구 된다면 Patch ID 125270-32 혹은 그 이후 버전이 반드시 설치되어야 합니다.

IBM HS22 Type 7870 블레이드 서버 설치하기

솔라리스10 5/09 를 이 시스템에 설치하려면, 텍스트 모드 설치를 수행해야 합니다. 솔라리스 설치 메뉴에서 옵션 4번을 선택합니다:

 
   4. Solaris Interactive Text (Console session)

설치를 계속 진행하고 자동 재부팅 혹은 수동 재부팅을 선택하는 옵션이 나왔을때 수동 재부팅 옵션을 선택합니다. 이것은 설치가 끝난 직후에 바로 패치를 설치 하는 작업을 용이하게 하도록 도와 줄 것입니다. 설치가 완료된 다음에는 "!" 를 눌러서 쉘로 나갈수 있도록 안내 됩니다.

설치 중간에 혹은 이후에 곧바로 패치를 적용하는 방법은 다음 섹션에서 설명 됩니다.

패치 적용하기

1) 패치를 다운로드 합니다

Patch ID 125270-32 (혹은 이후 버전) 을 Sunsolve 웹사이트에서 다운로드 합니다.

2) 패치를 대상 시스템이 복사 합니다

만약 네트워크를 이용해서 부팅하고 있다면, 그리고 넷인스톨 이미지에 쓰기 접근 권한을 가지고 있다면, 여러분은 패치를 넷인스톨 이미지에 복사함으로써 시스템이 설치 되는 동안에 /cdrom 마운트포인트에서 접근이 가능하도록 할 수 있습니다.

패치를 사용가능하게 하는 또 다른 방법은 USB 드라이브를 마운트 하거나 혹은 네트워크 접근이 가능하다는 가정 하에 패치를 ftp(1) 혹은 scp(1) 로 옮기는 것입니다.

3) 패치 압축해제하기

 
   # unzip <path_to_patch>/125720-32.zip

만약 사인된 패치를 다운로드 하셨다면 다음의 명령 에 따라서 서명을 검증하실 수 있습니다.

사인된 버전의 패치를 압축 해제 하려면:

 
   # unzip <path_to_patch>/125720-32.jar

4) 패치 적용하기

패치는 반드시 /a 로 마운트 된 설치된 대상에 적용해야 합니다

 
   # patchadd -R /a <path_to_patch>/125270-32

5) 시스템을 재부팅 합니다

 
   # reboot

만약 시스템이 패치를 설치 하기 전에 재부팅 되었다면, 패치를 원격에서 설치 하거나 혹은 패치를 설치하기 전까지 GUI 를 비활성화 시켜야 합니다. 위에서 언급한 패치 적용 절차들은 4번 단계를 제외 하고 그대로 적용 가능합니다. 4번 단계는 /a 마운트 포인트를 지정해주지 않는 것으로 수정해야 합니다. GUI 를 비활성화 하는 것은 아래의 트러블슈팅 에 설명되어 있습니다.

트러블슈팅

만약 여러분이 패치 ID 125270-32 를 적용하지 못했거나 패치 ID 125270-32 를 컨솔에서 적용하길 원한다면 cde-login 서비스를 비활성화 함으로써 시스템이 텍스트 모드로 남아 있도록 강제할 수 있습니다.

GUI 비활성화 하기

cde-login 을 비활성화 하는 3가지 시나리오가 아래에 설명되어 있습니다. 이러한 시나리오는, 부팅 시에 변경하거나, 점프스타트를 이용하거나, 혹은 시스템이 설치되고 부팅된 이후에 적용이 가능합니다.

1) 부팅시에 GUI 비활성화 하기

재부팅된 다음에, 싱글 유저로 부팅한 다음에 cde-login 서비스를 비활성화 함으로써 GUI 모드를 막을 수 있습니다. 이 것은 GNU GRUB 메뉴를 수정함으로써 가능합니다. 시스템이 솔라리스10 5/09 버전을 부팅 시키면, 다음과 같은 GNU GRUB 메뉴가 솔라리스가 기본 OS 인 상태로 강조되어서 나타 납니다:

 
   GNU GRUB version 0.95 (616K lower / 4127168K upper memory)
   +-------------------------------------------------------------------+
   |Solaris 10 5/09 s10x_u7wos_08 X86                                  |
   |Solaris  failsafe                                                  |
   |                                                                   |
   +-------------------------------------------------------------------+
   Use the ^ and v keys to select which entry is highlighted. Press
   enter to boot the selected OS, 'e' to edit the commands before
   booting, or 'c' for a command-line.

'e' 를 눌러서 수정합니다
커널 라인을 선택하고 'e' 를 눌러 해당 라인을 수정합니다
<SPACE> -s 를 줄의 마지막에 추가 하고 <RETURN> 을 누릅니다
'b' 를 눌러 부팅시킵니다

시스템이 싱글 유저 모드로 부팅된 다음에는 루트로 로그인 하고 svcadm(1M) 커맨드를 이용해서 GUI 로긴 스크린을 비활성화 시킵니다:

 
   # svcadm disable cde-login

2) 점프스타트를 통해서 GUI 비활성화 하기

만약 점프스타트 설치를 수행중이라면 cde-login 서비스를 /a/var/svc/profile 에 있는 종료 스크립트 site.xml 파일을 수정해서 비활성화 하실 수 있습니다:

 
   <?xml version='1.0'?>
   <!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
   <service_bundle type='profile' name='site'>
     <service name='application/graphical-login/cde-login' type='service' version='0'>
      <instance name='default' enabled='false'/>
     </service>
   </service_bundle>

3) 이미 설치되고 운영중인 시스템에서 GUI 비활성화 하기

만약 시스템이 솔라리스10 5/09 버전으로 설치 되었고 이미 GUI 로그인 스크린으로 부팅되었다면, 원격에서 ssh 를 이용하여 로그인한 후에 svcadm 으로 기본 GUI 로그인 스크린을 비활성화하실 수 있습니다:

 
   # svcadm disable cde-login

그 다음에 시스템을 재부팅 합니다.

GUI 재활성화 하기

패치 125720-32 (혹은 이후 버전) 을 설치한 다음에는, 다시 svcadm 커맨드를 이용해서 GUI 를 재활성화 해 줍니다:

 
   # svcadm enable cde-login

만약 GUI 를 site.xml SMF 프로파일을 통해서 비활성화 시켰다면, 위의 점프스타트 단계에서 설명한 대로, 프로파일을 다시 수정해서 cde-login 항목을 제거해 주어야 합니다.

[원문]

Workaround for Installing Solaris 10 5/09 OS on the IBM HS22 Type 7870 Blade Server

http://wikis.sun.com/display/bigadmin/i ··· rkaround

"관리자코너" 카테고리의 다른 글

맥북 13인치 코어 2 듀오에 솔라리스10 설치하기 (댓글 2개 / 트랙백 0개) 2008/06/16
썬 버추얼 데스크탑 커넥터 1.0(베타)을 사용한 VDI 데모 구축 (댓글 0개 / 트랙백 0개) 2008/01/23
솔라리스 Tip Of The Week:SMF (댓글 0개 / 트랙백 0개) 2009/01/23
GlassFish 를 프로덕션 환경으로 설치하기 (댓글 0개 / 트랙백 0개) 2009/11/23
솔라리스 레디 애플리케이션 및 솔루션 (댓글 0개 / 트랙백 0개) 2008/03/13
솔라리스 10 에서 TCP Wrapper 사용하기 (댓글 1개 / 트랙백 0개) 2006/01/23
시만텍 베리타스 넷백업과 ZFS 스냅샷 통합하기 (댓글 0개 / 트랙백 0개) 2009/07/17
ZFS, 썬의 최신 파일 시스템(Part 1: 스토리지 무결성, 보안성 및 확장성) (댓글 3개 / 트랙백 1개) 2006/11/23
USB로 부팅하기 - 설치 (댓글 31개 / 트랙백 1개) 2007/08/20
파일과 디렉토리를 안전하게 옮기거나 카피 할 수 있는 방법 (댓글 6개 / 트랙백 0개) 2007/04/23

솔라리스10 어플리케이션 라이브러리를 이용해서 솔라리스10에서 실행되는 어플리케이션 찾기

(Sun) — Thu, 17 Dec 2009 15:28:54 +0900

솔라리스10 어플리케이션 라이브러리를 이용해서 솔라리스10에서 실행되는 어플리케이션 찾기

Karen Perkins, November 2009

솔라리스10 에서 실행가능한 어플리케이션들을 찾고 계십니까? 만약 그렇다면 여기 완벽한 툴이 있습니다: BigAdmin 솔라리스10 어플리케이션 라이브러리 에서 어플리케이션들을 검색하고 다운로드 받으실 수 있습니다.

솔라리스10 어플리케이션 라이브러리는 SPARC 및 x86/x64 플랫폼에서 실행되는 수천가지의 어플리케이션 목록을 가지고 있고(현재 약 11,000개가 넘는 어플리케이션들이 존재) 그 수가 빠르게 늘어나고 있습니다. 벤더의 이름 혹은 어플리케이션의 이름이나 설명을 가지고 검색하실 수 있습니다.

또한 여러분의 어플리케이션을 라이브러리에 등록 하실 수 있습니다(혹은 만약 썬의 파트너라면, 저희가 등록할때 까지 기다리는 것 대신에 직접 로그인해서 어플리케이션을 등록하실 수 있습니다). 그리고 고객들이 여러분의 어플리케이션을 설정하고 배치할 수 있도록 백서, 문서 혹은 다른 컨텐츠들을 링크시키실 수 있습니다

라이브러리를 사용하는 방법을 알려 드립니다:

어플리케이션을 검색하는 방법

1. 솔라리스10 어플리케이션 라이브러리 를 방문합니다.

2. 페이지 상단의 Type 드롭다운 박스에서:

어플리케이션 이름으로 검색할 경우 Software 를 선택합니다.
소프트웨어를 내놓은 회사 이름으로 검색할 경우 Publisher 를 선택합니다.

3. Fields 드롭다운 리스트에서, 어떤 부분의 데이타베이스 라이브러리를 검색할지 선택합니다:

데이타베이스의 이름 필드만 검색하고 싶을 경우 Name 을 선택합니다.
데이타베이스의 설명 필드만 검색하고 싶을 경우 Description 을 선택합니다.
데이타베이스의 두가지 필드 모두를 검색하고 싶을 경우 Name and Description 을 선택합니다.

4. Keywords 필드에서, 하나 혹은 그 이상의 검색어를 입력합니다.

5. 어플리케이션이 실행되는 플랫폼을 선택합니다: SPARC, x86/x64, or both.

6. Search 를 클릭합니다.

검색 결과는 Search 버튼 아래 표형태로 표시 되며, 각각의 항목들은 아래와 같습니다:

테이블 위 왼쪽에는 라이브러리내의 어플리케이션의 총 수를 나타 냅니다. 오른쪽에는 SPARC 플랫폼 및 x86/x64 플랫폼에서 각각 얼마만큼의 어플리케이션이 존재하는지 보실 수 있습니다.

참고: SPARC 과 x86/x64 어플리케이션의 수가 전체 숫자를 넘어가는데 이것은 몇몇 어플리케이션들은 두개의 플랫폼에서 모두 실행되기 때문입니다.
종종 결과는 복수 페이지일 수 있습니다. 페이지 사이를 이동하려면, 페이지 번호(테이블 위 혹은 아래에)를 클릭하거나, 두개 이상의 페이지가 존재한다면 Previous, Next 를 클릭합니다.
Software Name 컬럼은 어플리케이션의 이름을 보여 줍니다. 이름을 클릭해서 어플리케이션에 대한 자세한 정보와 어플리케이션을 다운로드 받을 수 있는 정보를 얻을 수 있는 팝업 윈도우를 여시기 바랍니다.
Publisher column 은 각각의 어플리케이션의 제작회사를 나타냅니다. 이름을 클릭해서 회사의 웹사이트, 해당 회사의 모든 소프트웨어 리스트, 회사의 평균 평점, 리뷰 그리고 다른 리소스들에 대한 정보를 얻을 수 있는 팝업 윈도우를 여시기 바랍니다.
Description 컬럼은 각각의 어플리케이션에 대한 간략한 설명을 보여 줍니다. More Info 를 클릭해서 지원되는 플랫폼 같은 자세한 정보를 얻을 수 있는 팝업 윈도우를 여시기 바랍니다.

데이타베이스 어플리케이션을 검색하는 예제

여러분이 어떠한 데이타베이스 어플리케이션이 솔라리스10 x86/x64 플랫폼에서 실행되는지 알고 싶다고 가정해 봅시다. 아래에 그 방법이 있습니다:

1. 솔라리스10 어플리케이션 라이브러리 를 방문합니다.

2. 페이지 상단의 Type 드롭다운 박스에서 Software 를 선택합니다.

3. Fields 드롭다운 리스트에서, Name 을 선택합니다.

4. 키워드 필드에 "database" 를 입력합니다.

5. SPARC 체크박스를 클릭해제 하고 x86/x64 체크박스를 선택합니다.

6. Search 를 클릭합니다.

검색결과는 다음을 나타 냅니다:

라이브러리 내의 전체 어플리케이션 숫자는 (2009년 11월 10일 기준으로) 11,131 개 이고 그중에 7,798 가 x86/x64 플랫폼에서 실행됩니다.
결과는 총 3페이지 이고 총 49개 데이타베이스 어플리케이션의 정보를 담고 있습니다. 만약 Next 를 클릭해서 페이지 2 로 이동한다면, MySQL, Oracle 10g, PostgreSQL 데이타베이스 어플리케이션 항목들을 보실 수 있습니다.
Software Name 컬럼은 데이타베이스 어플리케이션의 이름을 나타 냅니다, 예를 들어 Oracle 10g Database Client 10.1.0.0 등을 보실 수 있습니다. 이름을 클릭하면 해당 어플리케이션에 대한 자세한 정보와 Oracle 에서 다운로드 받을 수 있는 링크를 제공하는 팝업 윈도우를 여실 수 있습니다.
Publisher 컬럼은 각각의 어플리케이션의 제작회사를 보여 줍니다. 이것을 클릭하면 Oracle 에 대한 설명과 Oracle 웹사이트에 대한 링크를 제공하는 팝업 윈도우를 여실 수 있습니다.

또한 "List all software from this publisher" 링크를 제공하는데 이것은 솔라리스10 x86/x64 플랫폼에서 실행되는 모든 Oracle 데이타베이스 소프트웨어들을 보여주는 검색을 재실행 합니다.

기술 백서, Oracle 의 평점 그리고 리뷰 같은 다른 리소스들에 대한 링크도 존재 합니다.
Description 컬럼은 각각의 어플리케이션들에 대한 간략한 설명을 보여 줍니다. 그리고 "More Info" 링크는 추가 정보들을 제공하는 팝업 윈도우를 열어 줍니다.

어플리케이션을 목록에 제출하여 라이브러리에 포함되도록 하기

여러분의 솔라리스10 어플리케이션을 솔라리스10 어플리케이션 라이브러리로 배포하기 위해서는 썬 소프트웨어 라이브러리에 그들을 추가시켜주어야 합니다.

썬 소프트웨어 라이브러리의 이득은 여러분이 한번만 배포하면, 복수개의 사이트에 자동으로 프로모션 됩니다. 그러므로 여러분의 썬 고객들에게 직접 마케팅할 수 있고, 썬 세일즈가 고객들에게 직접 알릴 수 있고 또한 피드백을 받을 수 있습니다.

썬 소프트웨어 라이브러리에 배포된 어플리케이션들, 그리고 솔라리스10이 지원된다고 표시된 것들은 솔라리스10 어플리케이션 라이브러리에 자동으로 프로모션 됩니다.

여러분의 어플리케이션을 썬 소프트웨어 라이브러리에 제출하기 위해서는:

1. 다음의 방법중에 하나를 사용하여 썬 소프트웨어 라이브러리 웹페이지로 이동합니다:

솔라리스10 어플리케이션 라이브러리 페이지에서, "Add your application to the library" 섹션 밑에 "Read More" 를 클릭 합니다. 그 다음에 팝업 윈도우가 나타나면 썬 소프트웨어 라이브러리 링크를 클릭합니다.
직접 Sun Software Library 를 방문합니다.

2. Search 필드에 여러분 회사의 이름을 넣고 검색합니다.

여러분 회사의 정보는 아마 다른 카탈로그로 부터 이미 제공되어졌을 수도 있습니다.

3. 만약 여러분 회사의 정보가 나타나지 않는다면, 오른쪽 상단의 Login 링크를 이용하여 로그인 합니다. 그 다음에 Publisher 로 등록하고, 어플리케이션을 등록하고 지원되는 플랫폼에 대한 상세 정보를 입력하고, 마지막으로 비디오 클립이나 문서자료 같은 리소스들을 추가 합니다.

혹은 만약 회사정보가 나타난다면, Type 컬럼에 Publisher 를 클릭합니다. 그 다음에 Publisher 상세 정보 페이지가 나타나면 "Request to be a content manager." 를 클릭합니다. 이메일로 승인 완료 정보를 받으면 (24시간 안에) 로그인해서 여러분의 컨텐츠를 수정 하고 추가합니다.

For More Information

Here are additional resources.

솔라리스 OS 리소스들

BigAdmin web applications and device lists:
BigAdmin Solaris technology resource centers:
BigAdmin Solaris resource collections (which include community submissions):
Discussions, such as the Solaris OS forums
BigAdmin Operating System wiki page

일반적인 썬 링크들

Sun download site
Sun training courses web site
Discussions, such as Sun forums and the BigAdmin Discussions collection
Product documentation at http://docs.sun.com and the Documentation Center
Sun wikis, such as the Sun BluePrints wiki and the BigAdmin wiki
Support:
- Sun resources:
- Community system administration experts

[원문]
Using the Solaris 10 Applications Library to Find Apps That Run on the Solaris 10 OS
http://www.sun.com/bigadmin/features/te ··· slib.jsp

"관리자코너" 카테고리의 다른 글

맥북 13인치 코어 2 듀오에 솔라리스10 설치하기 (댓글 2개 / 트랙백 0개) 2008/06/16
썬 버추얼 데스크탑 커넥터 1.0(베타)을 사용한 VDI 데모 구축 (댓글 0개 / 트랙백 0개) 2008/01/23
솔라리스 Tip Of The Week:SMF (댓글 0개 / 트랙백 0개) 2009/01/23
GlassFish 를 프로덕션 환경으로 설치하기 (댓글 0개 / 트랙백 0개) 2009/11/23
솔라리스 레디 애플리케이션 및 솔루션 (댓글 0개 / 트랙백 0개) 2008/03/13
솔라리스 10 에서 TCP Wrapper 사용하기 (댓글 1개 / 트랙백 0개) 2006/01/23
시만텍 베리타스 넷백업과 ZFS 스냅샷 통합하기 (댓글 0개 / 트랙백 0개) 2009/07/17
ZFS, 썬의 최신 파일 시스템(Part 1: 스토리지 무결성, 보안성 및 확장성) (댓글 3개 / 트랙백 1개) 2006/11/23
USB로 부팅하기 - 설치 (댓글 31개 / 트랙백 1개) 2007/08/20
파일과 디렉토리를 안전하게 옮기거나 카피 할 수 있는 방법 (댓글 6개 / 트랙백 0개) 2007/04/23

버퍼 I/O vs 직접 I/O 환경에서의 오라클 Logwriter 분석

(Sun) — Thu, 17 Dec 2009 15:26:57 +0900

버퍼 I/O vs 직접 I/O 환경에서의 오라클 Logwriter 분석

소개 / 동기

SAP 과 Oracle 은 이미 문제 진단 및 퍼포먼스 이슈를 다룰 수 있는 강력한 툴들을 제공하고 있습니다. 그와는 별개로 DTrace 는 시스템에 대한 무한한 접근성을 제공 합니다. 그러므로 필자는 DTrace 를 SAP/Oracle 환경에서 사용하는 케이스에 대한 시리즈의 글을 작성하기로 결정하였습니다. 이미 작성해 놓은 Oracle 와 I/O 에 관한 글이 있기 때문에 일단 저는 이것을 DTrace 의 관련 글의 시작점으로 삼을 생각입니다:

비록 버퍼 I/O 대신에 직접 I/O 를 통해서 파일에 접근 하는 것이 베스트프랙티스로 여겨지고 있지만, 여전히 많은 분들이 이러한 조언을 따르지 않고 있습니다. 고객은 보통 버퍼 I/O 가 훨씬 좋고 / 빠르다고 알고 있을 수도 있고 혹은 10.2.0.2 와 10.2.0.3 (후자는 SAP 환경에서 지원되지 않음) 에 오라클 버그 5752399 에 영향을 받아서일 수도 있습니다.

배경

오라클 데이타파일에 대한 버퍼 I/O 접근이 직접 I/O 보다 좀 더 나은 퍼포먼스를 제공하는 몇몇 상황들이 있습니다. 어떠한 경우에서든지 온라인 리두로그 파일 시스템은 반드시 직접 I/O 로 설정되어야 합니다. 이 글은 해당 주제에 대한 통찰력을 DTrace 를 통해서 드리려고 합니다.
참고:
테스트 환경은 오라클 10.2.0.1 을 'forcedirectio' 마운트 옵션을 이용하여 사용하였습니다. 대부분의 경우에 오라클 레벨의 파라미터 'filesystemio_options' 을 통해서 직접 I/O 를 활성화 하는 것을 추천 드립니다. 이것은 다른 어플리케이션 / 유틸리티 (예를 들어 백업 툴 같은) 이 파일시스템 캐시의 이득을 얻을 수 있도록 합니다.

접근

테스트 시나리오는 오라클 10g 데이타베이스 (10.2.0.1) 를 사용하여, 특히 imp 유틸리티를 약 100만 레코드가 존재하는 덤프 파일과 함께 사용합니다. 각각의 테스트 후에, 해당되는 테이블은 버려지고, 체크포인트가 수행됩니다. 직접 및 버퍼 I/O 를 바꾸기 위해서 각각의 테스트 마다 마운트 옵션이 변경될 것입니다 (remount 를 통한 온라인 작업). 이 과정은 커밋에 대한 빈도와 커밋 사이즈(imp parfile 설정을 통한), 그리고 아주 안정적인 결과(재연가능한) 를 얻을 수 있는 제어권을 가질 수 있도록 합니다. 저희는 전체 실행시간만 재는 것이 아니라 DTrace 스크립트를 통해서 I/O 와 ufs 내부를 들여다 볼 것입니다.

buffer=1024
commit=Y
file=my_sales.dump
rows=y

이 파라미터파일은 imp 유틸리티가 자주 커밋을 수행하고 각각의 커밋은 오직 소량의 데이타만을 쓰도록 합니다.

리두로그를 'noforcedirectio' 로 마운트 하여 임포트 합니다:

Import terminated successfully without warnings.
 
real        2:24.41
user          11.04
sys            1.66

리두로그를 'forcedirectio' 로 마운트 하여 임포트 합니다:

Import terminated successfully without warnings.
 
real        1:48.09
user          11.03
sys            1.62

결과로 봤을때 'forcedirectio' 를 사용함으로써 평균 약 36 초 (~30%) 정도의 이득을 얻었음을 볼 수 있습니다. 먼저 I/O 를 살펴 봅시다. Brendan Gregg 의 DTrace 툴킷 은 'iosnoop.sh' 이라고 하는 스크립트를 제공합니다. LogWriter 프로세스(lgwr) 을 추적하면 다음과 같은 정보를 얻을 수 있습니다:

forcedirectio:

./iosnoop.sh -aD -p 4162
STRTIME              DEVICE  MAJ MIN DELTA        UID   PID D    BLOCK   SIZE                     PATHNAME ARGS
2009 May 27 11:42:56 sd0      32   4 3772         215  4162 W 22293311    512                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3874         215  4162 W 22293312   2560                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3600         215  4162 W 22293317   3072                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3733         215  4162 W 22293323   2560                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3814         215  4162 W 22293328    512                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3322         215  4162 W 22293329   3072                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3193         215  4162 W 22293335   3072                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3730         215  4162 W 22293341   1536                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3813         215  4162 W 22293344   1536                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3615         215  4162 W 22293347   3072                       <none> ora_lgwr_DEM\0
2009 May 27 11:42:56 sd0      32   4 3556         215  4162 W 22293353   3072                       <none> ora_lgwr_DEM\0

임포트된 테이블은 VARCHAR 필드들을 가지고 있습니다. 그러므로 레코드의 길이는 다양할 것입니다. 모든 I/O 의 사이즈는 복수개의 512 바이트 블럭이고 상당히 작습니다 - 항상 4KB 보다 작습니다. 전체적으로 별로 놀라운 것은 없습니다: 데이타의 양에 따라 서로 다른 사이즈를 로그버퍼에서 리두로그 파일로 순차적으로 쓰는 것입니다. 오라클의 통계를 살펴 봅시다:

Event		
Statistic				Total		per Second	per Trans
redo size 				48,438,904 	267,760.27 	2,734.50
redo synch time 			7,384 		40.82 		0.42
redo synch writes 			17,864 	        98.75 		1.01
redo wastage 				5,559,348 	30,730.93 	313.84
redo write time 			7,381 		40.80 		0.42
redo writer latching time 		0 		0.00 		0.00
redo writes 				17,734 	        98.03 		1.00

좋습니다. 오라클은 평균 lgwr I/O 를 2731 바이트 (redo size / redo writes) 로 평균 서비스타임 4.2ms 에 처리 하였음을 보여주고 있습니다. 참고: v$sysstat 에서 나오는 시간들은 ms 가 아니라 cs 단위로 측정 됩니다!
이제 동일한 작업을 'noforcedirectio' 마운트 옵션으로 수행해 봅시다.
noforcedirectio:

./iosnoop.sh -aD -p 4162
STRTIME              DEVICE  MAJ MIN DELTA        UID   PID D    BLOCK   SIZE                     PATHNAME ARGS
2009 May 27 02:09:41 sd0      32   4 5848         215  4162 W 21946960  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:41 sd0      32   4 3667         215  4162 W 21946960  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:41 sd0      32   4 3690         215  4162 W 21946960  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:41 sd0      32   4 3650         215  4162 W 21946960  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:41 sd0      32   4 22498        215  4162 R 21949024 1048576 /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:41 sd0      32   4 23045        215  4162 W 21946976  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:41 sd0      32   4 3468         215  4162 W 21946976  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
					:
					:
2009 May 27 02:09:44 sd0      32   4 5855         215  4162 W 21949008  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:44 sd0      32   4 3333         215  4162 W 21949008  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:44 sd0      32   4 3690         215  4162 W 21949008  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:44 sd0      32   4 22519        215  4162 R 21951072 1048576 /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:44 sd0      32   4 23070        215  4162 W 21949024  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
2009 May 27 02:09:44 sd0      32   4 3675         215  4162 W 21949024  8192   /slice4/redolog/redo01.log ora_lgwr_DEM\0
					:
					:

두가지 흥미로운 관찰점이 있습니다:
LGWR 는 반복적으로 동일한 블럭을 씁니다! 저희의 테스트케이스에서 오라클은 아주 작은 커밋을 하고 있음을 알고 있는 상태 입니다. 만약 버퍼 I/O 가 사용되면 비록 512 바이트 만이 변경되었더라도 전체 OS 블럭이 매 커밋마다 쓰여져야 합니다. 이것은 이후에 쓰기 작업이 동일한 블럭을 디스크에 쓰도록 유도 합니다.
저희들은 자주 로그파일에 대한 대용량의 읽기 작업(1MB) 를 볼 수 있습니다. 블럭 주소를 살펴 보면 이것은, 프리페칭(prefetching) 과 유사해 보입니다. prefetched 데이타 (1MB) 의 직전에 8KB 블럭에 도달하면 또다른 1MB 가 읽힙니다. 데이타베이스 내부 측면으로 한번 살펴 봅시다:

Event		
Statistic				Total		per Second	per Trans
redo size 				50,214,248 	293,724.43 	2,832.48
redo synch time 			10,993 	   	64.30 		0.62
redo synch writes 			17,870 		104.53 		1.01
redo wastage 				5,609,796 	32,814.08 	316.44
redo write time 			10,999 		64.34 		0.62
redo writer latching time 		0 		0.00 		0.00
redo writes 				17,728 		103.70 		1.00

몇몇 분들은 '리두 사이즈' 가 이전에 저희가 얘기했던 대로 버퍼 I/O 의 쓰기 오버헤드 때문에 훨씬 클 것으로 예상했을 것입니다. 그러나 기억하시기 바랍니다:이것은 오라클의 관점입니다. 작은 데이타 블럭의 전체를 8KB 파일시스템 블럭으로 채우는 것은 UFS 레이어에서 일어나고 오라클에서 일어나지는 않습니다! 그러므로 저희들은 거의 동일한 리두 데이타(리두 사이즈) 의 양을 볼 수 있고, 또한 거의 동일한 숫자의 리두 쓰기도 확인할 수 있습니다. 그러나 리두 쓰기 시간 (73.8s vs 110s) 에서는 엄청난 차이를 발견할 수 있는데 이것은 두 테스트의 전체 런타임에 해당 합니다.
이제 두개의 시나리오의 내부에 어떠한 일이 발생하는지에 대해서 좀 더 자세히 알아 봅시다. 작은 DTrace 스크립트의 커널 프로파일링이 이데 관련한 정보를 제공할 수 있습니다:

 
#!/usr/sbin/dtrace -s
#pragma D option flowindent
 
fbt:ufs::entry
/pid == $1/
{
        self->ts[probefunc] = timestamp;
}
 
fbt:ufs::return 
/pid == $1 && self->ts[probefunc] != 0/
{ 
        self->duration[probefunc] = (timestamp - self->ts[probefunc])/1000;
} 
 
fbt:ufs::
/pid == $1/
{
        trace(self->duration[probefunc]);
        self->duration[probefunc] = 0;
}

스크립트에 하나의 파라미터가 전달되는데 이것은 오라클 LGWR 프로세스의 pid 입니다. 스크립트는 (function boundary tracing) 프로바이더를 이용합니다. fbt 는 거의 대부분의 솔라리스 커널 함수의 진입 및 리턴 프로브를 제공 합니다. 이번에 저희는 특히 UFS 모듈에 관심이 있습니다. 기본적으로 저희는 진입 및 리턴에 걸리는 시간을 추적합니다. 추가적으로 flowindent 옵션을 이용해서 좀더 읽기 쉬운 출력을 생성하고 이를 통해서 호출 구조에 대한 좀 더 명확한 그림을 제공합니다.
직접 I/O 는 비교적 간단한 코드패스를 가지고 있음을 보실 수 있습니다. 저희들은 각각의 호출에 대한 코드 레벨 까지 알아보지는 않을 것입니다. 그러나 호출의 횟수를 통해서 무슨일이 벌어지고 있는지는 알 수 있을 것입니다. 일단 제일 처음 시작부분에 'ufs_write' 호출이 있습니다.

forcedirectio (숫자들은 마이크로세컨드임):

root@ontario1:/opt/dtrace # ./ufs3.d 4162
 
  1          -> ufs_write                                     0
  1            -> ufs_check_rewrite                           0
  1              -> bmap_has_holes                            0
  1              <- bmap_has_holes                           28
  1            <- ufs_check_rewrite                          94
  1            -> ufs_lockfs_begin                            0
  1              -> ufs_lockfs_is_under_rawlockfs             0
  1              <- ufs_lockfs_is_under_rawlockfs            47
  1            <- ufs_lockfs_begin                          135
  1            -> ufs_directio_write                          0
  1              -> bmap_read                                 0
  1                -> findextent                              0
  1                <- findextent                             23
  1              <- bmap_read                                75
  1              -> directio_start                            0
  1              <- directio_start                           67
  1              -> directio_wait                             0
  1                -> directio_wait_one                       0
  1                <- directio_wait_one                    2914
  1              <- directio_wait                          2981
  1            <- ufs_directio_write                       3259
  1            -> ufs_itimes_nolock                           0
  1              -> ufs_imark                                 0
  1              <- ufs_imark                                21
  1            <- ufs_itimes_nolock                          78
  1            -> ufs_lockfs_end                              0
  1              -> ufs_lockfs_top_vop_return                 0
  1              <- ufs_lockfs_top_vop_return                42
  1            <- ufs_lockfs_end                            120
  1          <- ufs_write                                  3894

noforcedirectio (숫자들은 마이크로세컨드임):

  0  -> ufs_write                                             0
  0    -> ufs_check_rewrite                                   0
  0      -> bmap_has_holes                                    0
  0      <- bmap_has_holes                                   36
  0    <- ufs_check_rewrite                                 119
  0    -> ufs_lockfs_begin                                    0
  0      -> ufs_lockfs_is_under_rawlockfs                     0
  0      <- ufs_lockfs_is_under_rawlockfs                    59
  0    <- ufs_lockfs_begin                                  170
  0    -> ufs_itimes_nolock                                   0
  0      -> ufs_imark                                         0
  0      <- ufs_imark                                        29
  0    <- ufs_itimes_nolock                                 102
  0    -> wrip                                                0
  0      -> ufs_indirblk_sync                                 0
  0      <- ufs_indirblk_sync                                41
  0      -> ufs_getpage                                       0
  0        -> ufs_lockfs_begin_getpage                        0
  0        <- ufs_lockfs_begin_getpage                       52
  0        -> bmap_has_holes                                  0
  0        <- bmap_has_holes                                 36
  0      <- ufs_getpage                                     227
  0      -> ufs_putpage                                       0
  0      <- ufs_putpage                                      32
  0      -> ufs_putpages                                      0
  0        -> ufs_putapage                                    0
  0          -> bmap_read                                     0
  0            -> findextent                                  0
  0            <- findextent                                 34
  0          <- bmap_read                                    99
  0          -> lufs_write_strategy                           0
  0            -> deltamap_remove                             0
  0            <- deltamap_remove                            38
  0          <- lufs_write_strategy                         171
  0        <- ufs_putapage                                 4877
  0      <- ufs_putpages                                   4955
  0      -> ufs_check_rewrite                                 0
  0      <- ufs_check_rewrite                                41
  0      -> top_delta                                         0
  0        -> deltamap_add                                    0
  0        <- deltamap_add                                   33
  0      <- top_delta                                        98
  0      -> ufs_itimes_nolock                                 0
  0        -> ufs_imark                                       0
  0        <- ufs_imark                                      28
  0      <- ufs_itimes_nolock                               101
  0    <- wrip                                             5833
  0    -> ufs_lockfs_end                                      0
  0      -> ufs_lockfs_top_vop_return                         0
  0      <- ufs_lockfs_top_vop_return                        53
  0    <- ufs_lockfs_end                                    152
  0  <- ufs_write                                          6614

여러분이 오라클 statspack 혹은 AWR 리포트 (혹은 오라클 엔터프라이즈 메니저 diagnostics pack 에 대한 라이센스가 없는 경우에) 에 대한 접근 권한이 없을 경우에는 다음의 스크립트를 수행함으로써 LGWR 의 평균 리두 쓰기 시간에 대한 아이디어를 얻으실 수 있습니다:

 
#!/usr/sbin/dtrace -s
 
fbt:ufs:ufs_write:entry 
/pid == $1/
{ 
        self->ts = timestamp; 
} 
 
fbt:ufs:ufs_write:return 
/self->ts != 0 && pid == $1/ 
{ 
        @time[execname] = avg(timestamp - self->ts); 
        self->ts = 0; 
}

이 스크립트는 집합(@time[]) 을 사용해서 리턴 프로브로 진입할때 까지의 걸리는 평균 시간을 계산합니다.

여러분은 다음의 명령으로 알아낼 수 있는 오라클 LGWR 의 pid 를 스크립트 실행시에 전달해 주어야 합니다

root@ontario1:/opt/dtrace # ps -ef | grep lgwr
  oradem  4162     1   0 02:01:29 ?           1:50 ora_lgwr_DEM
    root  9747  5417   0 15:53:39 pts/4       0:00 grep lgwr

테스트 임포트 작업이 끝난 후에 CTRL-c 를 누르면 다음과 같은 결과를 나노세컨드 단위로 보실 수 있습니다:

forcedirectio

root@ontario1:/opt/dtrace # ./avg_redo_write.d 4162
dtrace: script './avg_redo_write.d' matched 2 probes
^C
 
  oracle                                                      3932139

noforcedirectio

root@ontario1:/opt/dtrace # ./avg_redo_write.d 4162
dtrace: script './avg_redo_write.d' matched 2 probes
^C
 
  oracle                                                      5893665

이 스크립트를 통해서 LGWR ufs_write 호출의 평균 응답시간은 직접 I/O 의 경우 ~4ms, 버퍼 I/O 의 경우 5.9ms 임을 확인하실 수 있습니다. 이러한 결과는 AWR 리포트에 포함되어 있습니다.

이 글의 주제인 버퍼 vs 직접 I/O 사용에 대한 토론으로 돌아가서:
여러분은 아주 작은 단위의 커밋때문에 테스트 시나리오가 약간 이상한 것이 아니냐고 생각하실 수 있습니다. 좋습니다. 이제 imp parfile 의 버퍼사이즈를 16MB 로 바꿔서 테스트 해 보겠습니다.
먼저 noforcedirectio 를 사용했습니다

Import terminated successfully without warnings.
 
real          44.74
user          10.57
sys            0.60

iosnoop-출력결과:

STRTIME              DEVICE  MAJ MIN   UID   PID D    BLOCK   SIZE                     PATHNAME ARGS
2009 May 28 00:33:34 sd0      32   4   215  4162 W 36398016   8192   /slice4/redolog/redo03.log ora_lgwr_DEM\0
2009 May 28 00:33:34 sd0      32   4   215  4162 W 36398032   8192   /slice4/redolog/redo03.log ora_lgwr_DEM\0
2009 May 28 00:33:34 sd0      32   4   215  4162 W 36398048   8192   /slice4/redolog/redo03.log ora_lgwr_DEM\0
2009 May 28 00:33:34 sd0      32   4   215  4162 W 36398064   8192   /slice4/redolog/redo03.log ora_lgwr_DEM\0
2009 May 28 00:33:34 sd0      32   4   215  4162 W 36398080   8192   /slice4/redolog/redo03.log ora_lgwr_DEM\0

다시한번 8KB 의 순차적인 쓰기 작업을 볼 수 있습니다. 비록 오라클이 더 큰 덩어리의 데이타를 커밋하더라도 말입니다. 이것은 오라클의 통계를 통해서도 확인될 수 있습니다:

Event		
Statistic				Total		per Second	per Trans
redo size 				39,506,404 	314,606.56 	564,377.20
redo write time 			3,222 		25.66 		46.03
redo writes 				99 		0.79 		1.41

이것은 대략 400 KB/redo 쓰기를 나타 냅니다.

이제 동일한 테스트를 forcedirectio 를 이용해서 진행해 봅시다:

Import terminated successfully without warnings.
 
real          17.01
user          10.55
sys            0.59

이 것은 버퍼 I/O 보다 약 163% 빠른 결과 입니다 (17,01 초 vs. 44,74 초). 다시한번 iosnoop 결과를 봅시다:

STRTIME              DEVICE  MAJ MIN   UID   PID D    BLOCK   SIZE                     PATHNAME ARGS
2009 May 28 00:54:09 sd0      32   4   215  4162 W 27313955   6656                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:10 sd0      32   4   215  4162 W 27313968 1048576                      <none> ora_lgwr_DEM\0
2009 May 28 00:54:10 sd0      32   4   215  4162 W 27316019 242176                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:10 sd0      32   4   215  4162 W 27316492  34816                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:10 sd0      32   4   215  4162 W 34013328  93696                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:10 sd0      32   4   215  4162 W 34013511 1044992                      <none> ora_lgwr_DEM\0
2009 May 28 00:54:10 sd0      32   4   215  4162 W 34015552   3584                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:10 sd0      32   4   215  4162 W 34015559   3072                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:10 sd0      32   4   215  4162 W 34015565 361984                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:10 sd0      32   4   215  4162 W 34016272   5632                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:11 sd0      32   4   215  4162 W 34016283 133632                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:11 sd0      32   4   215  4162 W 34018064 857600                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:11 sd0      32   4   215  4162 W 34013216  57344                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:11 sd0      32   4   215  4162 W 34019739 371200                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:11 sd0      32   4   215  4162 W 34020464    512                       <none> ora_lgwr_DEM\0
2009 May 28 00:54:11 sd0      32   4   215  4162 W 34020465 1048064                      <none> ora_lgwr_DEM\0

여러분이 보시듯이 I/O 는 다양한 사이즈로 발생했는데, 512 바이트에서 1MB 까지 다양한 사이즈가 발견되었습니다. 평균적으로 이것은 작은 8KB 쓰기 보다 훨씬 효율적임이 발견되었습니다.

결론

필자는 AWR 과 DTrace 로 얻어진 결론이 아주 명확하다고 생각합니다. 여전히 여러분은 UFS 버퍼 I/O 를 선호 하십니까? 선택은 여러분의 몫입니다.....

[원문]
Analyzing Oracle Logwriter w/ buffered vs. direct I/O
http://wikis.sun.com/display/saponsun/g ··· part%2B1

"관리자코너" 카테고리의 다른 글

맥북 13인치 코어 2 듀오에 솔라리스10 설치하기 (댓글 2개 / 트랙백 0개) 2008/06/16
썬 버추얼 데스크탑 커넥터 1.0(베타)을 사용한 VDI 데모 구축 (댓글 0개 / 트랙백 0개) 2008/01/23
솔라리스 Tip Of The Week:SMF (댓글 0개 / 트랙백 0개) 2009/01/23
GlassFish 를 프로덕션 환경으로 설치하기 (댓글 0개 / 트랙백 0개) 2009/11/23
솔라리스 레디 애플리케이션 및 솔루션 (댓글 0개 / 트랙백 0개) 2008/03/13
솔라리스 10 에서 TCP Wrapper 사용하기 (댓글 1개 / 트랙백 0개) 2006/01/23
시만텍 베리타스 넷백업과 ZFS 스냅샷 통합하기 (댓글 0개 / 트랙백 0개) 2009/07/17
ZFS, 썬의 최신 파일 시스템(Part 1: 스토리지 무결성, 보안성 및 확장성) (댓글 3개 / 트랙백 1개) 2006/11/23
USB로 부팅하기 - 설치 (댓글 31개 / 트랙백 1개) 2007/08/20
파일과 디렉토리를 안전하게 옮기거나 카피 할 수 있는 방법 (댓글 6개 / 트랙백 0개) 2007/04/23

JSF 2.0 애플리케이션에서 자바용 CDI 및 의존성 주입 사용

(Sun) — Wed, 25 Nov 2009 14:54:02 +0900

2009년 10월 30일 금요일

JSF 2.0 애플리케이션에서 자바용 CDI 및 의존성 주입 사용

저자 Roger Kitain

이 테크팁에서는 자바 EE 6 플랫폼에 속하는 세 가지 강력한 기술인 JSR 299: 컨텍스트 및 의존성 주입, JSR 330: 자바를 위한 의존성 주입 및 JSR 314: JavaServer Faces 2.0의 교차를 다룹니다.

JSR 299: 컨텍스트 및 의존성 주입(CDI)은 애플리케이션을 훨씬 쉽게 개발할 수 있게 만드는 자바 EE 환경을 위한 서비스 집합을 정의합니다. CDI는 서블릿, 엔터프라이즈 빈 및 JavaBean과 같은 자바 EE 구성요소가 범위가 잘 정의된 애플리케이션의 수명 주기 내에 존재할 수 있게 해주는 아키텍처를 제공합니다. 또한 CDI 서비스를 통해 이벤트를 시작하고 관찰하여 EJB 세션 빈과 JSF(JavaServer Faces) 관리 빈을 포함한 자바 EE 구성요소가 주입되어 느슨하게 결합되는 방식으로 상호 작용할 수 있습니다. 가장 중요한 점은 CDI가 EJB 및 JSF 프로그래밍 모델을 통합하고 단순화한다는 점일 것입니다. CDI를 통해 엔터프라이즈 빈은 JSF 애플리케이션에서 관리 빈으로 작동할 수 있습니다. CDI는 자체적인 서비스를 통해 웹 계층에 트랜잭션 지원을 제공합니다. CDI는 웹 애플리케이션에서 트랜잭션 리소스에 액세스하기 훨씬 쉽게 할 수 있습니다. 예를 들어, CDI 서비스를 이용하면 자바 Persistence API에서 제공하는 지속성으로 데이터베이스에 액세스하는 자바 EE 웹 애플리케이션을 훨씬 쉽게 만들 수 있습니다.

JSR 330: 자바를 위한 의존성 주입에서는 의존성 주입을 위해 사용할 수 있는 표준 주석 집합을 도입합니다. 의존성 주입은 엔터프라이즈 자바 애플리케이션 개발에 많이 사용되는 기술입니다. 불행히도, 주석 기반 의존성 주입에 대한 표준 접근 방식이 없었습니다. 자바를 위한 의존성 주입은 의존성 주입을 위해 표준화되고 확장 가능한 API를 제공함으로써 변화를 꾀합니다. API는 주입 가능한 클래스에서 사용하기 위한 주석 집합으로 구성됩니다.

JavaServer Faces 기술은 자바 EE 애플리케이션용 사용자 인터페이스(UI)의 개발을 단순화하기 위해 설계된 서버 쪽 구성 요소 프레임워크를 제공합니다. 이 기술의 최신 릴리스인 JSR 314: JavaServer Faces 2.0은 주석 지원과 Facelet 및 컴포지트 구성 요소와 같은 새로운 기능 추가를 통해 자바 EE 애플리케이션용 UI 개발을 훨씬 쉽게 해줍니다.

이 테크팁에서는 JSF 2.0 애플리케이션에서 자바용 CDI 및 의존성 주입의 사용에 관해 설명합니다.

애플리케이션 예

자바용 CDI 및 의존성 주입을 사용하는 JSF 2.0 애플리케이션의 몇몇 핵심 부분을 살펴봅시다. 이 팁에서 제공되는 샘플 애플리케이션 패키지에서 애플리케이션의 소스 코드를 찾을 수 있습니다. 애플리케이션 설치 및 실행 방법에 대한 지침은 샘플 코드 실행을 참조하십시오.

그림 1은 애플리케이션의 UI를 나타낸 것입니다. UI에서는 사용자에게 시스템이 임의로 선택한 숫자를 추측해보라는 메시지를 표시합니다. 이 메시지는 다음과 같습니다. min에서 max 사이의 수를 생각하고 있습니다. 여기서, min과 max는 각각 어림짐작으로 허용 가능한 최소값과 최대값을 나타냅니다. UI에는 사용자가 숫자를 입력할 텍스트 필드, 숫자를 전송하기 위한 추측 버튼, 게임을 다시 시작하기 위한 재설정 버튼이 표시됩니다. 사용자가 정확한 수보다 낮은 수를 입력하는 경우 UI는 더 높음(Higher)!이라는 메시지로 응답합니다. 또한 UI는 프롬프트 메시지의 min 값을 추측한 수보다 높은 값으로 변경합니다. 사용자가 입력한 값이 너무 높은 경우 UI는 더 낮음(Lower)!이라는 메시지로 응답하고 프롬프트 메시지의 max 값을 추측한 수보다 낮은 값으로 변경합니다. 시스템은 추측 횟수에 대한 제한을 설정하고, UI는 각각의 부정확한 추측에 대해 사용자에게 추측할 수 있는 기회가 얼마나 남아 있는지 알려주는 메시지를 표시합니다. 사용자가 수를 정확히 추측하거나 추측 횟수 제한에 이를 때 게임이 끝납니다.

그림 1. 수 추측 JSF 2.0 애플리케이션의 UI

다음은 애플리케이션의 UI에 대한 코드입니다.

   1.  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   2.  <html xmlns="http://www.w3.org/1999/xhtml"
   3.     xmlns:ui="http://java.sun.com/jsf/facelets"
   4.     xmlns:h="http://java.sun.com/jsf/html"
   5.     xmlns:f="http://java.sun.com/jsf/core">
   6.     <h:head>
   7.         <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
   8.         <title>JSF 2.0 Weld Example</title>
   9.     </h:head>
  10.     <h:body>
  11.        <h:form id="NumberGuessMain">
  12.           <h:panelGrid styleClass="title-panel">
  13.              <h:outputText value="Guess Number" styleClass="title-panel-text"/>
  14.              <h:outputText value="Powered By JavaServer Faces 2.0 and Weld" styleClass="title-panel-subtext"/>
  15.           </h:panelGrid>
  16.           <div style="color: black; font-size: 24px;">
  17.              I'm thinking of a number between <span style="color: blue">#{game.smallest}</span> and <span style="color: blue">#{game.biggest}</span>. You have <span style="color: blue">#{game.remainingGuesses}</span>guesses.
  18.           </div>
  19.           <h:panelGrid border="1" columns="5" style="font-size: 18px;">
  20.              Number:
  21.              <h:inputText id="inputGuess" value="#{game.guess}" required="true" size="3" disabled="#{game.number eq game.guess}" validator="#{game.validateNumberRange}"/>
  22.              <h:commandButton id="GuessButton" value="Guess" action="#{game.check}" disabled="#{game.number eq game.guess}"/>
  23.              <h:commandButton id="RestartButton" value="Reset" action="#{game.reset}" immediate="true" />
  24.              <h:outputText id="Higher" value="Higher!" rendered="#{game.number gt game.guess and game.guess ne 0}" style="color: red"/>
  25.              <h:outputText id="Lower" value="Lower!" rendered="#{game.number lt game.guess and game.guess ne 0}" style="color: red"/>
  26.           </h:panelGrid>
  27.           <div style="color: red; font-size: 14px;">
  28.              <h:messages id="messages" globalOnly="false"/>
  29.           </div>
  30.           <h:outputStylesheet name="stylesheet.css" />
  31.        </h:form>
  32.     </h:body>
  33. </html>

JSF로 애플리케이션을 개발하는 경우 UI의 코드가 눈에 익을 것입니다. 사실, 이 페이지의 모든 것이 표준 JSF 2.0 뷰 마크업입니다. 강조 표시한 표현 언어(EL) 표현식에 주의하십시오. 이 표현식들은 game이라는 이름의 상황별 빈 인스턴스를 가리킵니다. 상황별 빈 인스턴스는 괸리 빈이라고도 하고, 그냥 간단히 빈이라고도 합니다.

실제로, 관리 빈의 개념은 CDI를 벗어납니다. 자바 EE 6에 도입된 관리 빈은 JSF 관리 빈, 엔터프라이즈 빈 및 CDI 빈을 포함하여, 자바 EE의 다양한 모든 종류의 빈을 통합하도록 설계되었습니다. 관리 빈은 자바 EE 컨테이너에서 관리 구성요소로 취급하는 자바 클래스입니다. 선택적으로, EJB 구성요소에서 사용하는 것과 같은 네임스페이스에 이름을 지정할 수 있습니다. 관리 빈은 수명 주기 관리 및 리소스 주입에 주로 관련된 소수의 컨테이너 제공 서비스에도 의존할 수 있습니다. JSF, EJB 및 CDI와 같은 다른 자바 EE 기술은 서비스를 추가하여 이런 관리 빈의 기본적인 정의를 바탕으로 구축됩니다. 예를 들어, JSF 관리 빈은 수명 주기 범위를 추가하고, EJB 세션 빈은 트랜잭션 지원과 같은 서비스를 추가하고, CDI 빈은 의존성 주입과 같은 서비스를 추가합니다.

UI에 대한 코드에 강조 표시된 EL 표현식으로 돌아갈 때, EL 표현식은 다음과 같이 다양한 빈 속성 및 메소드에 바인딩합니다.

17, 24 및 25행의 EL 표현식은 빈 속성에 바인딩합니다.
21행의 EL 표현식은 빈 속성과 빈 유효성 검사 메소드에 바인딩합니다.
22 및 23행의 EL 표현식은 빈 작동 메소드에 바인딩합니다.

보시다시피, JSF 2.0에서는 CDI 빈에 바인딩하는 것이 일반적인 JSF 관리 빈에 바인딩하는 것과 전혀 다르지 않습니다.

간단한 상황별 빈의 분석

앞서 언급한 바와 같이, 이벤트를 시작하고 관찰하여 빈을 수명 주기 컨텍스트에 바인딩하고 주입하여 느슨하게 결합되는 방식으로 다른 빈과 상호 작용할 수 있습니다. 그 밖에도, 자바 코드에서 빈을 직접 호출하거나, 예로 든 애플리케이션의 UI에서 보았듯이 EL 표현식에서 호출할 수도 있습니다. 이를 통해 JSF 페이지가 빈에 직접 액세스할 수 있습니다.

애플리케이션에서 사용되는 game 빈을 살펴봅시다. 다음은 이 빈의 소스 코드입니다.

   1. package weldguess;
   2.
   3. import java.io.Serializable;
   4. import javax.annotation.PostConstruct;
   5. import javax.enterprise.context.SessionScoped;
   6. import javax.enterprise.inject.Instance;
   7. import javax.inject.Inject;
   8. import javax.inject.Named;
   9. import javax.faces.application.FacesMessage;
  10. import javax.faces.component.UIComponent;
  11. import javax.faces.component.UIInput;
  12. import javax.faces.context.FacesContext;
  13.
  14. @Named
  15. @SessionScoped
  16. public class Game implements Serializable {
  17.     private static final long serialVersionUID = 1L;
  18.
  19.     private int number;
  20.     private int guess;
  21.     private int smallest;
  22.
  23.     @MaxNumber @Inject
  24.     private int maxNumber;
  25.
  26.     private int biggest;
  27.     private int remainingGuesses;
  28.
  29.     @Random @Inject Instance<Integer> randomNumber;
  30.
  31.     public Game() {
  32.     }
  33.
  34.     public int getNumber() {
  35.          return number;
  36.     }
  37.
  38.     public int getGuess() {
  39.          return guess;
  40.     }
  41.
  42.     public void setGuess(int guess) {
  43.          this.guess = guess;
  44.     }
  45.
  46.     public int getSmallest() {
  47.          return smallest;
  48.     }
  49.
  50.     public int getBiggest() {
  51.         return biggest;
  52.     }
  53.
  54.     public int getRemainingGuesses() {
  55.         return remainingGuesses;
  56.     }
  57.
  58.     public String check() throws InterruptedException {
  59.         if (guess>number) {
  60.             biggest = guess - 1;
  61.         }
  62.         if (guess<number) {
  63.             smallest = guess + 1;
  64.        }
  65.        if (guess == number) {
  66.            FacesContext.getCurrentInstance().addMessage(null, new FacesMessage("Correct!"));
  67.        }
  68.        remainingGuesses--;
  69.        return null;
  70.     }
  71.
  72.     @PostConstruct
  73.     public void reset() {
  74.         this.smallest = 0;
  75.         this.guess = 0;
  76.         this.remainingGuesses = 10;
  77.         this.biggest = maxNumber;
  78.         this.number = randomNumber.get();
  79.     }
  80.
  81.     public void validateNumberRange(FacesContext context,  UIComponent toValidate, Object value) {
  82.         if (remainingGuesses <= 0) {
  83.             FacesMessage message = new FacesMessage("No guesses left!");
  84.             context.addMessage(toValidate.getClientId(context), message);
  85.             ((UIInput)toValidate).setValid(false);
  86.             return;
  87.         }
  88.         int input = (Integer) value;
  89.         if (input < smallest || input > biggest) {
  90.             ((UIInput)toValidate).setValid(false);
  91.             FacesMessage message = new FacesMessage("Invalid guess");
  92.             context.addMessage(toValidate.getClientId(context), message);
  93.         }
  94.     }
  95. }

특히 빈에서 강조 표시된 다음 주석을 잘 살펴보십시오.

14행의 @Named 주석. 이것은 어떤 이름을 빈과 연관시키기 위해 사용되는 자바용 의존성 주입 주석입니다. 주석에 인수로 지정된 이름이 없기 때문에, 빈의 이름은 첫 번째 문자가 소문자로 된 JavaBean의 이름, 즉 game이 됩니다. 이 주석을 통해 애플리케이션은 보기의 EL 표현식을 사용하여 빈을 그 이름으로 지칭할 수 있습니다.
15행의 @SessionScoped 주석. 이것은 빈에 대한 범위를 지정하는 CDI 주석입니다. 모든 빈에는 인스턴스의 수명 주기와 다른 빈의 인스턴스에서 빈의 어떤 인스턴스를 볼 수 있게 할지 결정하는 범위가 있습니다. @SessionScoped 주석은 이 빈이 세션 범위의 빈(즉, 빈의 수명 주기가 세션의 수명 주기라는 의미)임을 선언합니다.
23행과 29행의 @Inject 주석. 이것은 의존성 주입 지점, 즉 자바 클래스 또는 인터페이스에 대한 의존성을 주입할 수 있는 지점을 식별하는 데 사용되는 CDI 주석입니다. 23행에서 주석은 maxNumber 필드에 대한 의존성 주입 지점을 식별합니다. 23행은 주입하기 위한 구현을 식별하는 한정자 주석인 @MaxNumber도 지정합니다. 한정자는 유형이 같은 개체들의 다른 사용 방법을 구분하는 데 도움이 되는 강력한 형식의 키입니다. 이번 팁의 후반부에 한정자에 대해 더 자세히 설명하겠습니다. @MaxNumber를 한정자 주석으로 정의하면 최대 추측 횟수에 대한 제한 값을 주입할 수 있습니다. 29행에서 @Inject 주석은 randomNumber 필드에 대한 의존성 주입 지점을 식별합니다. 29행은 주입하기 위한 구현을 식별하는 한정자 주석인 @Random도 지정합니다. @Random을 한정자 주석으로 정의하면 사용자가 추측할 필요가 있는 임의의 수를 주입할 수 있습니다.
72행의 @PostConstruct 주석. 이 주석은 JSR 250, 자바 플랫폼용 공통 주석에 정의되어 있습니다. 이 주석은 구성 요소를 만든 후 초기화를 수행할 메소드를 식별하는 데 사용됩니다. 여기서 reset() 메소드는 @PostConstruct 주석으로 표시됩니다. 빈을 만든 후, reset() 메소드는 나머지 추측 횟수를 추적하는 remainingGuesses, 최대 추측 횟수에 대한 값을 유지하는 biggest 및 사용자가 추측할 필요가 있는 임의로 생성된 수를 유지하는 number와 같은 많은 변수를 초기화합니다.

도움이 되는 주석

빈이 한정자 주석으로 @Random 및 @MaxNumber 주석을 사용하는 것을 보았습니다. 이제 그런 주석이 어떻게 정의되는지 살펴봅시다.

다음은 @Random 주석의 정의입니다.

   1. package weldguess;
   2.
   3. import static java.lang.annotation.ElementType.FIELD;
   4. import static java.lang.annotation.ElementType.METHOD;
   5. import static java.lang.annotation.ElementType.PARAMETER;
   6. import static java.lang.annotation.ElementType.TYPE;
   7. import static java.lang.annotation.RetentionPolicy.RUNTIME;
   8. import java.lang.annotation.Documented;
   9. import java.lang.annotation.Retention;
  10. import javax.inject.Qualifier;
  11.
  12. @Target( { TYPE, METHOD, PARAMETER, FIELD })
  13. @Retention(RUNTIME)
  14. @Documented
  15. @Qualifier
  16. public @interface Random {
  17. }

15행의 @Qualifier 주석은 어떤 주석을 한정자 주석으로 식별하는 데 사용되는 자바용 의존성 주입 주석입니다. 한정자는 주입할 자바 클래스 또는 인터페이스의 특정 구현을 식별합니다. 한정자 주석을 사용하려면 우선 한정자로서 그 형식을 정의해야 합니다. 그렇게 하기 위해 @Qualifier 주석을 사용합니다. @Random을 한정자 주석으로 정의하면 임의의 수를 애플리케이션에 주입할 수 있습니다.

@Qualifier 주석은 아래에 표시된 것처럼 @MaxNumber 주석의 정의에도 사용됩니다.

   1. package weldguess;
   2.
   3. import static java.lang.annotation.ElementType.FIELD;
   4. import static java.lang.annotation.ElementType.METHOD;
   5. import static java.lang.annotation.ElementType.PARAMETER;
   6. import static java.lang.annotation.ElementType.TYPE;
   7. import static java.lang.annotation.RetentionPolicy.RUNTIME;
   8. import java.lang.annotation.Documented;
   9. import java.lang.annotation.Retention;
  10. import java.lang.annotation.Target;
  11. import javax.inject.Qualifier;
  12.
  13. @Target( { TYPE, METHOD, PARAMETER, FIELD })
  14. @Retention(RUNTIME)
  15. @Documented
  16. @Qualifier
  17. public @interface MaxNumber {
  18. }

16행의 @Qualifier 주석은 @MaxNumber를 한정자 주석으로 정의합니다. @MaxNumber를 한정자 주석으로 정의하면 최대 허용 추측 횟수를 애플리케이션에 주입할 수 있습니다.

유틸리티 빈

애플리케이션의 중요한 구성요소가 하나 더 있는데, 그것은 바로 Generator라는 이름의 유틸리티 빈입니다. Generator 빈은 다음과 같은 형태입니다.

   1. package weldguess;
   2.
   3. import java.io.Serializable;
   4. import javax.enterprise.context.ApplicationScoped;
   5. import javax.enterprise.inject.Produces;
   6.
   7. @ApplicationScoped
   8. public class Generator implements Serializable {
   9.     private static final long serialVersionUID = -7213673465118041882L;
  10.    private java.util.Random random = new java.util.Random( System.currentTimeMillis() );
  11.     private int maxNumber = 100;
  12.     java.util.Random getRandom() {
  13.         return random;
  14.     }
  15.     @Produces @Random int next() {
  16.         return getRandom().nextInt(maxNumber);
  17.     }
  18.     @Produces @MaxNumber int getMaxNumber() {
  19.         return maxNumber;
  20.     }
  21. }

다음은 빈에서 강조 표시된 주석이 하는 역할입니다.

7행의 @ApplicationScoped 주석은 클래스에 대한 범위를 지정하는 CDI 주석입니다. 이 주석은 Generator 클래스의 인스턴스가 애플리케이션의 수명 주기 동안 존재함을 선언합니다.
15행 및 18행의 @Produces 주석은 어떤 메소드를 producer 메소드로 식별하는 데 사용되는 CDI 주석입니다. producer 메소드는 애플리케이션에 있는 다른 빈에서 주입된 개체를 필요로 할 때마다 호출됩니다. 15행에서 producer 메소드는 next()입니다. Game 빈이 다음 난수의 인스턴스를 구할 필요가 있을 때 Beans Manager에서 이 메소드를 호출합니다. 18행에서 producer 메소드는 getMaxNumber()입니다. Game 빈이 최대 허용 추측 횟수(이 경우에는 100)를 구할 필요가 있을 때 Beans Manager에서 이 메소드를 호출합니다.

구성요소가 함께 작동하는 방식

앞서 설명한 UI로 돌아가 봅시다. 사용자가 메시지에 응답하여 추측 버튼을 클릭하면 CDI 기술이 작동합니다. 자바 EE 컨테이너는 Game 빈과 Generator 빈의 상황별 인스턴스를 자동으로 인스턴스화합니다. Game 빈을 만든 후, 이 빈의 reset() 메소드가 호출되어 최대 추측 횟수에 대한 값을 유지하는 biggest 및 사용자가 추측할 필요가 있는 임의로 생성된 수를 유지하는 number와 같은 많은 변수를 초기화합니다.

Game 빈은 maxNumber 필드에서 최대 추측 횟수를 가져옵니다. 한정자 주석인 @MaxNumber를 포함한 의존성 주입 지점이 maxNumber 필드에 대해 지정된다는 점을 상기하십시오. Generator 빈에서 producer 메소드인 getMaxNumber()가 @MaxNumber 한정자 주석과 연관된다는 점도 상기하십시오. 결과적으로, Game 빈이 @MaxNumber 필드에 액세스할 때 이 빈은 Generator 빈의 getMaxNumber() 메소드를 호출합니다. getMaxNumber() 메소드는 maxNumber 필드의 값, 즉 100을 반환합니다.

Game 빈은 사용자가 추측할 임의의 수를 제공하기 위해 비슷한 경로를 거칩니다. 이 빈은 randomNumber.get() 메소드를 구성 후 초기화의 일부로 호출합니다. 한정자 주석인 @Random을 포함한 의존성 주입 지점은 randomNumber 필드에 대해 지정되고, Generator 빈의 producer 메소드인 getRandom()은 @Random 한정자 주석과 연관된다는 점을 상기하십시오. 결과적으로, Game 빈이 randomNumber.get() 메소드를 호출하면 Generator 빈의 getRandom() 메소드가 호출됩니다. randomNumber.get() 메소드는 java.util.Random 클래스의 getRandom() 메소드를 사용하여 0~100의 범위 내에서 임의의 수를 생성합니다.

샘플 코드 실행

샘플 애플리케이션이 이 팁에 제공됩니다. 샘플 애플리케이션을 실행하려면 다음과 같이 하십시오.

글래스피쉬 v3 프리뷰 애플리케이션 서버의 최신 promoted build 또는 nightly build를 아직 다운로드하지 않았으면 다운로드하십시오.
샘플 애플리케이션 패키지인 weld-guess.zip을 다운로드합니다.
샘플 애플리케이션 패키지의 압축을 풉니다. 애플리케이션 소스 코드가 들어 있는 폴더뿐 아니라, 애플리케이션의 WAR 파일인 weld-guess.war도 보일 것입니다. UI에 대한 소스 코드는 web 폴더에 있습니다. 빈과 주석에 대한 소스 코드는 src 폴더에 있습니다.
다음 명령을 입력하여 글래스피쉬 v3 프리뷰 애플리케이션 서버를 시작합니다.
```
   <GFv3_inst>/bin/asadmin start-domain
```
여기서 <GFv3_inst>는 글래스피쉬 v3 프리뷰 애플리케이션 서버를 설치한 곳입니다.
weld-guess.war 파일을 <GFv3inst>/domains/domain1/autodeploy 디렉토리에 복사하여 샘플 애플리케이션을 배포합니다.
브라우저를 열고 URL http://localhost:8080/weld-guess에 액세스하여 애플리케이션을 실행합니다.

추가 자료

자세한 내용은 다음 자료를 참조하십시오.

저자 정보

Roger Kitain은 JavaServer Faces에 대한 공동 스펙 부문 리더입니다. 그는 1997년 이래 server-side 웹 기술 및 제품에 광범위하게 관여해 왔습니다. 2001년에는 레퍼런스 구현 팀의 일원으로 JavaServer Faces 기술에 대한 작업을 시작했습니다. 또한 서블릿 및 JSP 기술 관련 경험을 보유하고 있습니다. 최근에 Roger는 CDI 사양과 글래스피쉬 컨테이너와 CDI의 통합 프로젝트에 참여했습니다. Roger Kitain의 블로그를 둘러보십시오.

---------------------------------------------------------------------------------------
원문 :

Using CDI and Dependency Injection for Java in a JSF 2.0 Application
http://blogs.sun.com/enterprisetechtips ··· njection

"Java EE" 카테고리의 다른 글

JAX-WS 핸들러 구성, 패키징, 배치하기 (댓글 2개 / 트랙백 0개) 2006/10/19
Enterprise Bean에서 보안 주석 사용하기 (댓글 4개 / 트랙백 0개) 2007/05/28
엔터프라이즈용 Java Application Verification Kit, 2부 (댓글 1개 / 트랙백 0개) 2005/10/05
Java Persistence를 최상으로 구현하는 방법 (댓글 12개 / 트랙백 0개) 2007/07/23
SAAJ 소개 (댓글 1개 / 트랙백 0개) 2005/06/08
커스텀 ELResolver를 이용하여 통합 EL 확장하기 (댓글 4개 / 트랙백 0개) 2006/10/19
JAX-WS를 이용한 웹 서비스 개발 (댓글 1개 / 트랙백 0개) 2006/01/18
JAXR (JAVA API FOR XML REGISTRIES) (댓글 1개 / 트랙백 0개) 2005/05/18
GlassFish에서 호출 흐름 모니터링하기 (댓글 3개 / 트랙백 0개) 2006/06/16
Groovy, Grails, MySQL 및 Java Persistence API의 조합 (댓글 0개 / 트랙백 0개) 2008/08/20

POST-REDIRECT-GET 및 JSF 2.0

(Sun) — Wed, 25 Nov 2009 14:52:14 +0900

POST-REDIRECT-GET 및 JSF 2.0
(2009년 11월 16일 월요일 )

저자 Ed Burns

Michael Jouravlev는 2004년 8월에 관련 업계에 큰 영향을 미쳤던 Redirect After Post라는 기사에서, 수많은 웹 애플리케이션에서 발생하는 문제를 설명했습니다. 그는 이 문제를 다음과 같이 설명했습니다.

모든 대화형 프로그램은 사용자 입력을 받고 결과를 표시하는 두 가지 기본적인 기능을 제공합니다. 웹 애플리케이션은 각각 POST와 GET이라는 두 가지 HTTP 메소드를 사용하여 이 동작을 구현합니다. 이 간단한 프로토콜은 애플리케이션이 POST 요청에 대한 응답으로 웹 페이지를 반환할 때 중단됩니다. 서로 다른 브라우저의 특성과 결합된 POST 메소드의 특성으로 인해 종종 사용자 경험의 질이 낮아지고 서버 애플리케이션의 상태가 잘못될 수 있습니다.

이 문제를 해결하기 위해, Jouravlev는 자신이 POST-REDIRECT-GET 또는 간단히 줄여 PRG 패턴이라 부른 기법을 설명했습니다. 이 패턴의 규칙은 다음과 같습니다.

POST에 대한 응답으로 절대 페이지를 표시하지 않음
항상 GET을 사용하여 페이지를 로드함
REDIRECT를 사용하여 POST에서 GET으로 탐색

JSF(JavaServer Faces) 기술의 이전 버전들은 페이지 탐색을 할 때마다 POST를 사용했기 때문에 위 규칙 중 첫 번째 규칙을 위반했습니다. JSF 사용 애플리케이션에서 한 페이지에서 다른 페이지로 탐색할 때, JSF 프레임워크가 서블릿 API의 RequestDispatcher.forward( ) 메소드를 통해 POST 요청을 전달했습니다. 이로 인해 포스트백 요청에 대한 응답으로 새 Faces 페이지가 렌더링되어 브라우저로 반환됩니다.

사실, Struts를 포함하여 가장 많이 사용하는 자바 서블릿 기반 웹 프레임워크는 이 접근 방법을 이용해 탐색합니다. HTTP 신봉자들은 당연히 이 접근 방법이 PRG 패턴의 첫 번째 규칙을 위반한다는 점을 지적합니다. JSF는 첫 번째 규칙을 어기지 않았을 뿐 아니라, JavaServer Faces 2.0까지는 다른 어떤 방법을 통해 이 규칙을 위반하기도 무척 어려웠습니다. JBoss의 Seam 팀에서 JSF 기술을 제공해준 덕분에, 지금은 JSF로 PRG 작업을 하기가 훨씬 쉬워졌습니다.

이 테크팁에서는 JSF 2.0에서 PRG 패턴을 구현하는 방법을 설명합니다. 이 팁의 내용은 곧 출간될 필자와 Neil Griffin의 공저인 JavaServer Faces 2.0: The Complete Reference의 PRG 및 JSF 2.0 섹션을 개작한 것입니다.

PRG가 아닌 예

사용자 등록을 처리하는 간단한 JSF 2.0 애플리케이션을 검사하는 것부터 시작해봅시다. 이 첫 번째 예에서는 애플리케이션이 PRG 패턴을 구현하지 않습니다. 이 애플리케이션의 첫 페이지는 다음과 같이 register.xhtml 파일에서 코딩됩니다.

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:h="http://java.sun.com/jsf/html"
         xmlns:f="http://java.sun.com/jsf/core">
   <h:head>
     <title>A Simple JavaServer Faces Registration Application</title>
   </h:head>
   <h:body>
     <h:form>
       <h2>JSF Registration App</h2>
       <h4>Registration Form</h4>
       <table>
         <tr>
           <td>First Name:</td>
           <td>
             <h:inputText label="First Name"
                          id="fname" value="#{userBean.firstName}"
                          required="true"/>
             <h:message for="fname" />
           </td>
         </tr>
         <tr>
           <td>Last Name:</td>
           <td>
             <h:inputText label="Last Name"
                          id="lname" value="#{userBean.lastName}"
                          required="true"/>
             <h:message for="lname" />
           </td>
           </tr>
   ... additional table rows not shown.
       </table>
       <p><h:commandButton value="Register" action="confirm" /></p>
     </h:form>
   </h:body>
   </html>

이 페이지에는 사용자가 성과 이름을 입력하는 텍스트 필드가 있습니다. 등록 버튼도 표시됩니다. 사용자가 등록 버튼을 누르면 JSF 탐색 규칙 시스템에서 확장명이 현재 페이지와 동일하고 파일 이름이 confirm인 애플리케이션 내부의 페이지를 찾습니다. confirm.xhtml이 존재하는 경우 JSF는 그 파일에 있는 탐색 구성요소를 사용하여 다음 페이지를 탐색합니다. 다음은 confirm.xhtml 파일입니다.

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:h="http://java.sun.com/jsf/html"
         xmlns:f="http://java.sun.com/jsf/core">
   <h:head>
     <title>A Simple JavaServer Faces Registration Application</title>
   </h:head>
   <h:body>
     <h:form>
       <h2>JSF Registration App</h2>
       <h4>Registration Confirmation</h4>
       <table>
         <tr>
           <td>First Name:</td>
           <td>
             <h:outputText value="First Name" value="#{userBean.firstName}"
           </td>
         </tr>
         <tr>
           <td>Last Name:</td>
           <td>
             <h:outputText label="Last Name" value="#{userBean.lastName}"
           </td>
           </tr>
   ... additional table rows not shown.
       </table>
       <p><h:commandButton value="Edit" action="register" /></p>
       <p><h:commandButton value="Confirm" action="#{userBean.addConfirmedUser}" /></p>
     </h:form>
   </h:body>
   </html>

confirm.xhtml 파일에는 편집 버튼과 확인 버튼에 대한 마크업이 포함됩니다. 사용자가 편집 버튼을 클릭하면 register.xhtml 페이지로 다시 돌아갑니다. 사용자가 확인 버튼을 클릭하면 어떤 작업이 호출됩니다. 확인 버튼을 클릭하면 메소드의 논리에서 프로그램 방식으로 결과를 결정하는 addConfirmedUser( )라는 작업 메소드가 지정됩니다. 다음은 addConfirmedUser( ) 메소드가 들어 있는 UserBean.java 파일입니다.

   package com.jsfcompref.model;

   ...  imports

   @ManagedBean
   @SessionScoped
   public class UserBean {

   ...  properties and methods

      public String addConfirmedUser() {
        boolean added = true; // actual application may fail to add user
        FacesMessage doneMessage = null;
        String outcome = null;
        if (added) {
            doneMessage = new FacesMessage("Successfully added new user");
            outcome = "done";
        } else {
            doneMessage = new FacesMessage("Failed to add new user");
            outcome = "register";
        }
          FacesContext.getCurrentInstance().addMessage(null, doneMessage);
          return outcome;
   }

이 간단한 예에서 addConfirmedUser( )는 페이지에 Successfully added new user라는 메시지가 표시되는 원인이 되고 그 결과로 "done"을 반환합니다. addConfirmedUser( ) 메소드가 "done"을 결과로 반환하면 사용자에게는 done.xhtml 페이지가 표시됩니다. 이것은 JSF 2.0의 새로운 기능인 암시적 탐색의 예입니다. 적용되는 모든 규칙을 확인한 후 일치하는 탐색 케이스를 찾지 못한 경우 탐색 처리기가 작업 결과가 보기 id에 해당하는지 여부를 확인합니다. 작업 결과와 일치하는 보기를 찾은 경우 일치하는 보기에 대한 암시적 탐색이 이루어집니다. 여기서 결과는 "done"이고 일치하는 보기는 done.xhtml이므로, 사용자에게는 done.xhtml 페이지가 표시됩니다. 암시적 탐색을 통해 faces-config.xml 파일에 탐색 규칙을 추가하는 수고를 덜 수 있습니다.

다음은 done.xhtml 페이지입니다.

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:h="http://java.sun.com/jsf/html"
         xmlns:f="http://java.sun.com/jsf/core">
   <h:head>
     <title>A Simple JavaServer Faces Registration Application</title>
   </h:head>
   <h:body>
     <h:form>
       <h2>JSF Registration App</h2>
       <h4>Registration Confirmation</h4>
       <h:messages />
       <table>
         <tr>
           <td>First Name:</td>
           <td>
             <h:outputText value="First Name" value="#{userBean.firstName}"
           </td>
         </tr>
       </table>
     </h:form>
   </h:body>
   </html>

매개 변수 보기를 사용하는 POST-REDIRECT-GET

매개 변수 보기는 간단하고 단정적으로 수신 요청 매개 변수 값을 보기 내부의 특수한 구성요소에 매핑하는 방법입니다. 이런 매핑은 보기의 새로운 <f:metadata> 섹션 내에서 새로운 <f:viewParam> 구성요소를 사용하여 지정됩니다. 다음 예를 생각해보십시오.

   <f:metadata>
      <f:viewParam name="foo" value="#{bean.foo}"/>
   </f:metadata>

이 예에서는 이름이 "foo"인 요청 매개 변수의 값이 #{bean.foo}의 속성에 자동으로 할당되는 것을 보여줍니다. 따라서 GET 요청의 경우는 다음과 같습니다.

   page1.jspx?foo=bar

JSF가 요청을 처리하기 시작할 때 #{bean.foo} 속성의 값은 bar로 설정됩니다.

매개 변수 보기는 JBoss Seam에서 볼 수 있는 페이지 매개 변수 기능과 비슷하지만, JSF 2.0에서 구현된 이 기능은 핵심적인 JSF 사양과 긴밀히 통합되어 있으므로 더욱 쉽게 사용할 수 있고 더 강력합니다. 다른 간단한 예를 살펴봅시다.

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:h="http://java.sun.com/jsf/html"
         xmlns:f="http://java.sun.com/jsf/core">
   <h:head>
     <title>A Simple JavaServer Faces 2.0 View</title>
   </h:head>
   <h:body>
     <h:form>

         <p>First Name:< <h:inputText id="fname"
              value="#{userBean.firstName}" /> </p>
       <p><h:commandButton value="submit"
    action="page02?faces-redirect=true&includeViewParams=true" /></p>

     </h:form>
   </h:body>
   </html>

<h:commandButton> 요소에 action="page02?faces-redirect=true"가 있습니다. URL을 정의하는 인터넷 표준에서 ? 문자가 있다는 것은 그 URL의 나머지 부분이 & 또는 &로 구분되는 name=value 쌍의 목록이 될 것임을 가리키며, 이 목록은 URL에 대한 요청과 함께 서버로 전송되어야 합니다. 이것을 쿼리 문자열이라고 합니다. JSF는 여기서 ? 문자의 의미를 빌리는데, 그 의미는 인터넷 표준에서 URL과 정확히 같습니다. JSF가 서버 쪽에서 결과를 구문 분석할 때 인식하는 두 가지 특수한 쿼리 문자열 매개 변수가 있습니다. faces-redirect 쿼리 문자열은 탐색 시스템에 이 암시적 탐색 케이스를 마치 <redirect/> 요소를 포함한 실제 <navigation-case> 요소인 것처럼 취급해야 한다고 알려줍니다. 다른 특수 쿼리 문자열 매개 변수인 includeViewParams는 탐색 처리기에 탐색을 수행할 때 매개 변수 보기를 포함하라고 알려줍니다. 그러나 어떤 매개 변수 보기가 포함되어야 할까요? 탐색을 수행할 때 포함할 매개 변수 보기는 to-view-id 페이지에서 선언됩니다. 이 경우에는 암시적 탐색을 사용하고 있으므로, 아래에 표시된 것처럼 암시적 to-view-id는 page02.xhtml입니다.

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:h="http://java.sun.com/jsf/html"
         xmlns:f="http://java.sun.com/jsf/core">
   <f:metadata>
        <f:viewParam name="fname> value="#userBean.firstName}"/>
       </f:metadata> 
   <h:head>
     <title>A Simple JavaServer Faces 2.0 View</title>
   </h:head>
   <h:body>
     <h:form>
         <p> Hello #{userBean.firstName}.</p>
     </h:form>
   </h:body>
   </html>

탐색 처리기가 매개 변수 보기를 포함시켜야 한다고 선언하는 해당 탐색 케이스(암시적 또는 명시적)를 발견하면 from-view-id 및 to-view-id 페이지의 매개 변수 보기를 살펴보고 일치 및 복사 알고리즘을 수행하여 매개 변수 보기를 새 페이지로 전달합니다. 이 경우에는 navigation-case가 리디렉션도 요청했습니다.

이제 등록 예를 살펴봅시다. 이번에는 매개 변수 보기로 PRG를 수행하도록 구현했습니다. register.xhtml 페이지는 다음과 같은 모습입니다.

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:h="http://java.sun.com/jsf/html"
         xmlns:f="http://java.sun.com/jsf/core">
   <f:metadata>
       <f:viewParam name="fname" value="#{userBean.firstName}" />
       <f:viewParam name="lname" value="#{userBean.lastName}" />
       <f:viewParam name="sex" value="#{userBean.sex}" />
       <f:viewParam name="dob" value="#{userBean.dob}">
          <f:convertDateTime pattern="MM-dd-yy" />
       </f:viewParam>
       <f:viewParam name="mail" value="#{userBean.email}" />
       <f:viewParam name="sLevel" value="#{userBean.serviceLevel}" />
       </f:metadata>
   <h:head>
     <title>A Simple JavaServer Faces Registration Application</title>
   </h:head>
   <h:body>
     <h:form>
       <h2>JSF Registration App</h2>
       <h4>Registration Form</h4>
       <table>
         <tr>
           <td>First Name:</td>
           <td>
             <h:inputText label="First Name"
                          id="fname" value="#{userBean.firstName}"
                          required="true"/>
             <h:message for="fname" />
           </td>
         </tr>
       ... remaining table rows omitted, they are the same as the original
       </table>

       <!-- The query parameters on the action attribute cause JSF to do the
               POST REDIRECT GET pattern -->
       <p><h:commandButton value="Register"
          action="confirm?faces-redirect=true&includeViewParams=true" /></p>
     </h:form>
   </h:body>
   </html>

이전의 매개 변수 보기 예에서는 to-view-id 페이지에 나타난다고 말했습니다. 이 예는 사용자가 보는 첫 페이지이지만, 이 예에서도 그렇습니다. 이 특정 애플리케이션에서는 사용자가 register.xhtml 페이지와 confirm.xhtml 페이지 사이를 오갈 수 있습니다. 따라서 사용자가 confirm.xhtml 페이지에 있을 때 to-view-id는 register.xhtml 페이지이고 그 반대도 마찬가지입니다. 따라서 <f:viewParams>는 두 페이지에 모두 있습니다. to 페이지로 넘어가려는 from 페이지에 있는 모든 입력 구성요소에 대해 <f:viewParam>이 필요합니다. dob 속성의 <f:viewParam> 내에 있는 <f:convertDateTime>에도 주목하십시오. 탐색이 수행될 때 값을 넘기기 위해 변환기를 호출해야 하기 때문에 이것이 필요합니다. 입력 필드에 정의된 명시적 변환기가 있는 경우에는 그에 해당하는 <f:viewParam>에도 명시적 변환기가 하나 있어야 합니다. 마지막으로, 암시적 탐색에서 이제는 눈에 익은 추가 쿼리 매개 변수인 confirm?faces-redirect=true&includeViewParams=true를 볼 수 있습니다.

UserBean.java 파일의 변경 내용을 살펴봅시다.

   package com.jsfcompref.model;

   ... omits imports

   @ManagedBean
   @RequestScoped
   public class UserBean {

   ...  additional properties omitted

      public String addConfirmedUser() {
        boolean added = true; // actual application may fail to add user
        FacesMessage doneMessage = null;
        String outcome = null;
        if (added) {
            doneMessage = new FacesMessage("Successfully added new user");
            outcome = "done?faces-redirect=true&includeViewParams=true";
        } else {
            doneMessage = new FacesMessage("Failed to add new user");
            outcome = "register?faces-redirect=true&includeViewParams=true";
        }
          FacesContext.getCurrentInstance().addMessage(null, doneMessage);
          return outcome;
   }

이 코드의 유일한 변경 사항은 Bean을 요청 범위에 포함시키고 쿼리 매개 변수를 암시적 탐색 문자열에 추가한 것입니다. 이 경우에는 includeViewParams=true 매개 변수가 추가되어 to-view-id page에서 어떤 매개 변수 보기를 선언하더라도 탐색에 포함됩니다.

다음은 confirm.xhtml 페이지입니다.

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:h="http://java.sun.com/jsf/html"
         xmlns:f="http://java.sun.com/jsf/core">
   <f:metadata>
          <f:viewParam name="fname" value="#{userBean.firstName}" />
          <f:viewParam name="lname" value="#{userBean.lastName}" />
          <f:viewParam name="sex" value="#{userBean.sex}" />
          <f:viewParam name="dob" value="#{userBean.dob}">
             <f:convertDateTime pattern="MM-dd-yy" />
          </f:viewParam>
          <f:viewParam name="mail" value="#{userBean.email}" />
          <f:viewParam name="sLevel" value="#{userBean.serviceLevel}" />
       </f:metadata>
   <h:head>
     <title>A Simple JavaServer Faces Registration Application</title>
   </h:head>
   <h:body>
     <h:form>
       <h2>JSF Registration App</h2>
       <h4>Registration Confirmation</h4>
       <table>
         <tr>
           <td>First Name:</td>
           <td>
             <h:outputText value="First Name" value="#{userBean.firstName}"
           </td>
         </tr>

   ... additional rows omitted, they are the same as the original.
       </table>

       <p><h:commandButton value="Edit"
     action="register?faces-redirect=true&includeViewParams=true" /></p>
      </h:form>

      <h:form>
	     <h:inputHidden value="#{userBean.firstName}" />
	     <h:inputHidden value="#{userBean.lastName}"/>
	     <h:inputHidden value="#{userBean.sex}" />
	     <h:inputHidden value="#{userBean.dob}">
	        <f:convertDateTime pattern="MM-dd-yy" />
	     </h:inputHidden>
	     <h:inputHidden value="#{userBean.email}" />
	     <h:inputHidden value="#{userBean.serviceLevel}" />

	     <p><h:commandButton value="Confirm"
          action="#{userBean.addConfirmedUser}" /></p>
            </h:form>

   </h:body>
   </html>

register.xhtml 페이지에서와 같이, 페이지 맨 위에 <f:metadata> 섹션과 작업 문자열에 추가 쿼리 매개 변수가 필요합니다. 여기서 새로운 점은 추가적인 <h:form> 요소 및 <h:inputHidden> 요소와 확인 버튼이 이 새로운 형태로 바뀌었다는 사실입니다. 이것은 매개 변수 보기로서 이 페이지로 전달되는 값을 일반적인 형태의 전송 매개 변수로 다음 페이지로 넘겨야 하기 때문에 필요합니다. 하지만, register.xhtml 페이지에 있는 것처럼 일반적인 입력 필드는 없습니다. 따라서 값을 넘기기 위해 숨겨진 필드를 사용합니다. dob 필드에서 <f:convertDateTime>이 계속 필요하다는 점도 주의하십시오.

마지막으로, 다음은 done.xhtml 페이지입니다.

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:h="http://java.sun.com/jsf/html"
         xmlns:f="http://java.sun.com/jsf/core">
   <f:metadata>
             <f:viewParam name="fname" value="#{userBean.firstName}" />
             <f:viewParam name="lname" value="#{userBean.lastName}" />
             <f:viewParam name="sex" value="#{userBean.sex}" />
             <f:viewParam name="dob" value="#{userBean.dob}">
                <f:convertDateTime pattern="MM-dd-yy" />
             </f:viewParam>
             <f:viewParam name="email" value="#{userBean.email}" />
             <f:viewParam name="sLevel" value="#{userBean.serviceLevel}" />
       </f:metadata>
   <h:head>
     <title>A Simple JavaServer Faces Registration Application</title>
   </h:head>
   <h:body>
     <h:form>
       <h2>JSF Registration App</h2>
       <h4>Registration Confirmation</h4>
       <h:messages />
       <table>
         <tr>
           <td>First Name:</td>
           <td>
             <h:outputText value="First Name" value="#{userBean.firstName}"
           </td>
         </tr>
   ... additional rows omitted
       </table>
     </h:form>
   </h:body>
   </html>

이 done.xhtml과 원본 파일 사이의 유일한 차이점은 지금은 눈에 익은 <f:metadata> 섹션입니다.

샘플 코드 실행

이 팁에는 PRG를 구현하는 샘플 애플리케이션이 제공됩니다. 다음 지침에서는 Maven 2 소프트웨어 프로젝트 관리 도구를 사용하여 샘플 애플리케이션을 작성한 다음 글래스피쉬 v3 프리뷰 애플리케이션 서버에 배포합니다.

글래스피쉬 v3 프리뷰 애플리케이션 서버의 최신 promoted build 또는 nightly build를 아직 다운로드하지 않았으면 다운로드하십시오.
Maven 2를 아직 다운로드하지 않았으면 다운로드하십시오.
샘플 애플리케이션 패키지인 PostRedirectGet.zip을 다운로드합니다.
샘플 애플리케이션 패키지의 압축을 풉니다. 매개 변수 보기를 사용하는 PRG 애플리케이션의 코드가 들어 있는 prgViewParams 폴더가 보일 것입니다.
prgViewParams 디렉토리로 이동하고 다음 Maven 명령을 입력하여 PRG 애플리케이션을 위한 WAR 파일을 만듭니다.
```
   mvn install
```
prgViewParams 디렉토리에 새로 생성된 target 하위 디렉토리에 prgViewParams.war 파일이 보일 것입니다.
다음 명령을 입력하여 글래스피쉬 v3 프리뷰 애플리케이션 서버를 시작합니다.
```
   <GFv3_inst>/bin/asadmin start-domain
```
여기서 <GFv3_inst>는 글래스피쉬 v3 프리뷰 애플리케이션 서버를 설치한 곳입니다.
샘플 애플리케이션을 배포합니다. 배포 방법 중 한 가지는 prgViewParams.war 파일을 <GFv3inst>/domains/domain1/autodeploy 디렉토리에 복사하는 것입니다.
브라우저를 열고 URL http://localhost:8080/prgViewParams에 액세스하여 애플리케이션을 실행합니다. 그림 1에 표시된 양식이 보일 것입니다.

그림 1. 등록 페이지
양식에 적당히 정보를 입력하고 등록 버튼을 클릭합니다. 그림 2에 표시된 것과 비슷한 페이지가 나타날 것입니다.

그림 2. 등록 페이지를 통한 등록
확인 버튼을 클릭합니다. 그림 3에 표시된 것과 비슷한 페이지가 나타날 것입니다.

그림 3. 확인 페이지

추가 자료

자세한 내용은 다음 자료를 참조하십시오.

저자 정보

Ed Burns는 썬 마이크로시스템즈의 엔지니어입니다. Ed는 1994년부터 NCSA Mosaic, Mozilla, Sun Java Plugin, Jakarta Tomcat 등 다양한 클라이언트 및 서버측 웹 기술 관련 업무를 해왔으며 최근에는 JavaServer Faces 관련 업무를 담당하고 있습니다. Ed는 현재 JavaServer Faces의 스펙 부문 공동 리더입니다. JavaServer Faces: The Complete Reference의 공동 저자이며, Secrets of the Rockstar Programmers의 저자입니다. 또한 곧 출간될 JavaServer Faces 2.0: The Complete Reference의 공동 저자이기도 합니다. Ed Burns의 블로그를 둘러보십시오.
---------------------------------------------------------------------------------------
원문 : Using CDI and Dependency Injection for Java in a JSF 2.0 Application
http://blogs.sun.com/enterprisetechtips ··· njection

"Java SE" 카테고리의 다른 글

JSSE 이용한 안전한 커뮤니케이션 (댓글 2개 / 트랙백 0개) 2004/08/31
3D 화면(scene)에 빛 효과 주기 (댓글 1개 / 트랙백 0개) 2004/07/30
Java SE & Java SE for Business 지원 로드맵 (댓글 0개 / 트랙백 0개) 2009/09/11
클래스에서 enhanced For-Loop 사용 (댓글 0개 / 트랙백 1개) 2007/10/09
VARIABLE CONTENT로 메세지 포맷하기 (댓글 7개 / 트랙백 2개) 2003/08/19
CONTENTPANE 작업의 변화 (댓글 1개 / 트랙백 0개) 2004/11/11
새로운 포매터로 출력물 포맷하기 (댓글 1개 / 트랙백 0개) 2004/10/27
스윙 유저 인터페이스에서 컴포넌트의 방향성 (댓글 2개 / 트랙백 0개) 2003/09/26
쓰레드의 상태정보를 저장할 때 사용되는 THREADLOCAL 변수들 (댓글 4개 / 트랙백 0개) 2003/12/12
2개의 스트링이 같은 경우는? (댓글 2개 / 트랙백 0개) 2004/05/27

[오픈 소스] 자바 EE 애플리케이션 서버의 상태

(Sun) — Wed, 25 Nov 2009 14:48:51 +0900

오픈 소스 자바 EE 애플리케이션 서버의 상태

Posted by kalali on November 17, 2009 at 3:26 AM PST

이 글은 커뮤니티에서 어떤 활성 컨테이너를 사용할 수 있고 각 컨테이너의 일반적인 상태를 어떠한지 알 수 있도록 하기 위해 현재 사용 중인 오픈 소스 자바 EE 애플리케이션 서버 및 서블릿 컨테이너(웹 컨테이너)에 대한 매우 기본적인 검토 내용입니다. 이 글은 개발 또는 제품 생산 과정에서 나중에 이들 중 하나를 사용하도록 선택할 필요가 있는 사람이 출발점으로 삼을 수 있게 하려는 목적만 가지고 있습니다. 이들을 상세히 비교한 내용은 기술 서적의 많은 지면을 할애해야 기술 가능합니다.

완전히 파괴된 오픈 소스 자바 EE 애플리케이션 서버:

Caucho의 유명한 제품인 레진은 꽤 오랫동안 사용된 오픈 소스 자바 EE 애플리케이션 서버로, 이 서버를 소규모 또는 대규모로 배포하여 DZone 자체와 같이 다양한 대소 규모의 시스템에 사용하고 있습니다.

현재 안정적인 레진 버전은 자바 EE 5를 완전히 지원하는 3.1.9이며 현재 버전을 대체할 개발 단계의 버전은 4.0.1입니다. 레진 라이선싱 스키마는 다른 대체 스키마와는 약간 다릅니다. 상업용으로 사용하려면 매년 CPU 단위로 Caucho에 소정의 요금을 지불해야 하지만, 오픈 소스 배포자와 평가자를 위한 GPL 버전을 제공합니다. 레진의 다른 버전들은 기능과 특징이 다른 기능 집합과 함께 사용할 수 있고, 각 버전에는 자체적인 가격 결정 스키마가 있습니다. 다른 버전과 라이선스 요금에 대한 자세한 내용은 라이선싱에서 확인할 수 있습니다.

레진은 통합 캐싱 시스템의 클러스터링, 고가용성 지원 및 각종 이점이 제공됩니다. Quercus를 사용하여 PHP 애플리케이션을 호스트하는 글래스피쉬 레진 지원과 유사합니다.

관리 및 유지 관리를 위해, 레진은 관리자와 개발자가 애플리케이션 서버에서 다른 서비스들의 상태를 볼 수 있게 하기 위해 가벼운 모니터링 애플리케이션을 제공함으로써 대체 경로를 택했고 관리자들이 구성 파일을 통해 관리 및 구성 작업을 수행할 수 있게 했습니다.

개발 도구 지원에 관해서라면 Ant, Maven 및 Ivy와의 통합과 함께 NetBeans, Eclipse 및 IntelliJ 통합을 예상할 수 있습니다.

다운로드 링크: http://www.caucho.com/download/ 버전 4.0.1을 구할 수 있음
시작 방법: OS에 따라 install_dir/bin으로 이동하고 /resin.sh start 또는 resin.bat start를 실행함
모니터링 콘솔: 세부 사항: URL: http://127.0.0.1:8080/resin-admin/ 더 진행하려면 사용자와 암호를 만들어야 합니다. 화면에 표시되는 절차에 따라 사용자와 암호를 만듭니다.

제로니모: ASF 하에서 분명히 배포되는 아파치 자바 EE 애플리케이션 서버. 새 자바 EE 사양을 구현하는 문제라면 제로니모가 글래스피쉬보다 못하지만, JBoss에 비해 관리 콘솔이 좋다는 점이 이점입니다. 클러스터링은 Terracotta와 같은 타사 제품을 통해 사용할 수 있고 클러스터링 및 고가용성에 대해 기본 제공되는 지원은 없습니다. 제로니모는 ServiceMix 및 ActiveMA와 같은 다른 아파치 프로젝트와 잘 통합됩니다. 제로니모의 현재 버전은 v2.1.4이고 자바 EE 5 사양을 완벽히 지원합니다. 제로니모에 대한 상업적 지원은 IBM 웹스피어 애플리케이션 서버 커뮤니티 에디션을 통해 받을 수 있습니다.

제로니모의 두 가지 배포 버전을 따로 사용할 수 있는데, 하나는 제티가, 다른 하나는 톰캣이 웹 컨테이너로 포함되어 있습니다. 모든 주요 IDE는 개발 서버로서 제로니모를 지원합니다.

다운로드 링크: http://geronimo.apache.org/apache-geron ··· ase.html
시작 방법: OS에 따라 install_dir/bin으로 이동하고 ./geronimo.sh start 또는 geronimo.bat start를 실행함
관리 콘솔 세부 정보: URL: http://localhost:8080/console/ 자격 증명: 시스템/관리자

글래스피쉬: 주로 썬 마이크로시스템즈에서 개발했으며 모듈식 아키텍처와 확장 가능한 아키텍처에서 이익을 얻습니다. 글래스피쉬는 새 자바 EE 사양 구현 능력을 커뮤니티에 제공하는 동시에, 모든 사용자에게 고급 관리 채널, 기본 제공 클러스터링 및 고가용성, OSGI 런타임 배포 등과 같은 기능을 제공합니다. 글래스피쉬를 사용한다는 것은 사용자가 배포 비트를 변경할 필요 없이 계약에 서명하면 썬으로부터 손쉽게 지원을 얻을 수 있음을 의미합니다. 현재 안정적인 글래스피쉬 버전은 글래스피쉬 2.1.1이고 다음 주 버전은 자바 EE 6에 완전히 적합하고 OSGI를 기반으로 하는 애플리케이션 서버인 글래스피쉬 v3입니다. 새 버전은 올해 11월에 릴리스될 예정입니다. 오픈 소스 글래스피쉬는 CDDL 및 GPL 라이선스에서 액세스 가능합니다.

글래스피쉬는 운영 체제(솔라리스)에서 시작하여 IDE(NetBeans)까지 다양하고 폭 넓은 썬 제품군과의 통합으로 많은 이점을 누립니다. 글래스피쉬 ESB, 오픈 포털, OpenSSO 및 OpenMQ는 글래스피쉬가 잘 통합되는 주목할 만한 프로젝트 중 일부입니다.

글래스피쉬의 다른 강점은 필수 소프트웨어 및 라이선스 비용을 전혀 지불하지 않아도 입증된 고가용성 인프라를 이룰 수 있는 썬 HADB와의 통합 능력입니다.

모든 주요 IDE는 글래스피쉬를 개발 서버로 지원하며, 이는 글래스피쉬를 사용하여 자바 EE 애플리케이션을 손쉽게 개발하기 시작할 수 있다는 뜻입니다.

다운로드 링크: https://glassfish.dev.java.net/downloads/v2.1.1-final.html
시작 방법: intall_dir/bin으로 이동하고 asadmin start-domain을 실행함
관리 콘솔 세부 정보: URL: http://localhost:4848 기본 자격 증명: admin/adminadmin

JBoss: JBoss는 다른 프로젝트보다 오랫동안 오픈 소스 커뮤니티에서 있었고 레드 햇 지원의 이점이 있습니다. JBoss 애플리케이션 서버는 기본적으로 클러스터링 및 고가용성을 제공하지만, 버전 5.1부터 배포에 포함되는 관리 콘솔은 관리자가 모든 애플리케이션 서버 리소스를 관리할 수 있도록 하기에 충분히 발전되지는 않습니다. 포함된 관리 및 유지 관리 콘솔은 Jopr(http://www.jboss.org/jopr)의 임베디드 버전입니다. 이 콘솔은 ESB, 캐시 등의 모든 JBoss 기술을 위한 단일 관리 및 유지 관리 지점으로 작동합니다. JBoss의 현재 버전은 5.1.0.GA이고 다음에 나올 버전은 5.2입니다. JBoss는 LGPL 하에서 배포되며 관심 있는 사람은 누구든지 레드 햇으로부터 상용 지원을 받을 수 있습니다. JBoss 커뮤니티 배포 및 엔터프라이즈 배포는 두 가지 다른 패키지이며, 커뮤니티 지원에서 상용 지원으로의 이동은 JBoss 엔터프라이즈 미들웨어라는 이름의 다른 Jboss 버전 설치를 의미합니다.

JBoss 애플리케이션 서버는 JBoss에서 제공하는 다양한 미들웨어와 통합함으로써 기대하는 효과를 거둡니다. 이 제품에는 캐싱, BPM, ESB, 포털 등이 포함됩니다. 개발 측면에서는 Eclipse를 기반으로 하는 JBoss Developer Studio(무료로 사용할 수는 없음)를 사용하며 Jboss에서 제공하는 다양한 미들웨어를 위한 도구를 제공합니다.

모든 주요 IDE는 JBoss를 개발 서버로 지원하며, 이는 이 애플리케이션 서버에서 애플리케이션을 손쉽게 개발하기 시작할 수 있다는 뜻입니다.

다운로드 링크: http://www.jboss.org/jbossas/downloads/
시작 방법: OS에 따라 install_dir/bin으로 이동하고 ./run.sh 또는 ./run.bat를 실행함
관리 콘솔 세부 정보: URL: http://localhost:8080/admin-console/ 기본 자격 증명: admin/admin

JOnAS는 OW2 컨소시엄의 대표적 프로젝트 중 하나로, 뉴스와 블로고스피어에서 비교적 덜 다루어지는 것과는 대조적으로 OSGI를 기반으로 하는 철저한 모듈식 아키텍처의 혜택을 많이 보고 있습니다. JOnAS 관리 콘솔은 훌륭하게 설계되어 있고 세련된 사용자 인터페이스로 손쉽게 사용할 수 있습니다. Jonas는 클러스터된 환경을 원활하게 우수하게 설계, 배포 및 관리하기 위해 JASMINe과 통합됩니다.

Jonas의 현재 버전은 자바 EE 5를 완벽히 지원하는 5.1이고, 다음에 나올 것으로 계획된 버전은 자바 EE와 자체 관리 기능을 기본적으로 지원하는 5.2로서 2010년 2월에 릴리스될 예정입니다. Eclipse 및 NetBeans와 같은 주요 IDE는 개발 서버로서 JOnAS를 지원합니다. Jonas는 LGPL 하에서 배포됨

다운로드 링크: http://wiki.jonas.ow2.org/xwiki/bin/view/Main/Downloads
시작 방법: OS에 따라 install_dir/bin으로 이동하고 ./jonas start 또는 jonas.bat start를 실행함
관리 콘솔 세부 정보: URL: http://localhost:9000/jonasAdmin/ 자격 증명: admin/admin

서블릿 컨테이너:

제티: 제티는 일정 수준까지 톰캣에 대한 대한으로 간주됩니다. 이들 컨테이너 아키텍처의 차이 때문에, 각기 다른 사용자층을 가지고 있습니다. 톰캣은 기능이 다양한 데 반해, 제티는 더 가볍고 내장시키기 쉽고 고도로 모듈화되어 있는 것으로 여겨집니다. 두 프로젝트 모두 큰 부하를 받는 조건에서 좋은 성능을 보이지만, 확실히 버전마다 차이가 있고 사용 사례에 따라서도 다른 결과를 나타냅니다. Gigaspaces, WADI, Terracotta 등을 사용하여 제티 인스턴스의 클러스터를 구성할 수 있습니다. 제티에는 관리 콘솔이 없고 모든 것은 구성 파일에 필요한 변경 사항을 추가하여 구성 파일을 거쳐야 합니다. 톰캣과 제티를 잘 비교한 자료는 다음 URL에서 확인할 수 있습니다. http://www.webtide.com/choose/jetty.jsp

다운로드 링크: http://www.eclipse.org/jetty/downloads.php
시작 방법: OS에 따라 install_dir/bin으로 이동하고 ./jetty.sh start 또는 jetty.bat start를 실행함
관리 콘솔 세부 정보: 관리 콘솔 없음.

참고: 제티를 시작하기 전, OS에 따라 install_dir/bin/jetty.sh 또는 jetty.bat에 다음 행을 추가합니다.

Windows:

set JETTY_HOME=path/to/jetty/install/dir

Linux, UNIX..:

export JETTY_HOME=path/to/jetty/install/dir

톰캣: 아파치 톰캣은 과거 10년간 사용되었고 지금도 가장 널리 사용되는 서블릿 컨테이너입니다. 인터넷에서 글래스피쉬, 제로니모, JBoss 및 JOnAS 호스팅은 찾기 힘들지만, 공유 호스트 공급자 중 다수가 고객을 위해 톰캣 호스팅을 제공합니다. 아파치 톰캣은 아파치 라이선스 하에서 배포되고 현재 버전(6.0.20)은 서블릿 2.5와 JSP 2.1을 지원합니다. 아파치 톰캣에는 관리자에게 매우 기본적인 구성 기능을 제공하는 번들형 관리 콘솔이 있습니다. 대부분의 관리 및 유지 관리 작업은 구성 파일을 편집하여 완료해야 합니다. 톰캣은 알려진 모든 IDE 및 빌드/배포 도구에서 지원되고 커뮤니티에서 높은 인기를 누리고 있습니다. 톰캣에는 내장형 클러스터링 및 세션 복제 지원 기능이 제공됩니다.

다운로드 링크: http://tomcat.apache.org/download-60.cgi#6.0.20
시작 방법: OS에 따라 install_dir/bin으로 이동하고 ./startup.sh 또는 startup.bat를 실행함
관리 콘솔 세부 정보: URL: http://127.0.0.1:8080/manager/html 자격 증명: admin/admin

참고: 톰캣을 시작하기 전에 tomcat-users 노드 내부의 install_dir/conf/tomcat-users.xml에 다음 행을 추가합니다.

<user username="tomcat" password="tomcat" roles="manager"/>

결론: 이 프로젝트 중 어떤 것도 모든 개발 및 배포 계획과 요구 사항에 딱 들어맞을 수는 없습니다. 그들 각각은 5가지 다른 경쟁 프로젝트에 비해 나름의 강점과 약점이 있습니다. 따라서 이들을 모두 테스트한 후 어떤 것이 더 나은지 결정해야 합니다.
----------------------------------------------------------------------------------------
원문 :
State of Open Source Java EE Application Servers
http://weblogs.java.net/blog/kalali/arc ··· -servers

"Java EE" 카테고리의 다른 글

JAX-WS 핸들러 구성, 패키징, 배치하기 (댓글 2개 / 트랙백 0개) 2006/10/19
Enterprise Bean에서 보안 주석 사용하기 (댓글 4개 / 트랙백 0개) 2007/05/28
엔터프라이즈용 Java Application Verification Kit, 2부 (댓글 1개 / 트랙백 0개) 2005/10/05
Java Persistence를 최상으로 구현하는 방법 (댓글 12개 / 트랙백 0개) 2007/07/23
SAAJ 소개 (댓글 1개 / 트랙백 0개) 2005/06/08
커스텀 ELResolver를 이용하여 통합 EL 확장하기 (댓글 4개 / 트랙백 0개) 2006/10/19
JAX-WS를 이용한 웹 서비스 개발 (댓글 1개 / 트랙백 0개) 2006/01/18
JAXR (JAVA API FOR XML REGISTRIES) (댓글 1개 / 트랙백 0개) 2005/05/18
GlassFish에서 호출 흐름 모니터링하기 (댓글 3개 / 트랙백 0개) 2006/06/16
Groovy, Grails, MySQL 및 Java Persistence API의 조합 (댓글 0개 / 트랙백 0개) 2008/08/20