반응형
지갑에 오랫동안 짱박혀 있던 도서상품권을 드디어 꺼냈다.

전에 이벤트를 통해서 받은 도서상품권이였는데 집에 있는 다른 책들도 다 못읽었는데..

책을 산다는게 아까워서 사용하지 않고 지갑속에 고이 모셔두었던 상품권이였다.

예전에 친구가 이 책을 읽고서 추천했던 기억이 났다.

그때는 학교 도서관에서 잠깐 읽어보기만 했었는데..

나는 책을 사면 전공관련 서적만 주구장창 사놔서 결국 다 읽지 못하고 집에서 취침중이시다.

이 책은 지하철을 타고 출퇴근 길에 틈틈히 읽어 보려고 구매했다.. 후기는 다 읽고 올리는 것으로 ㅎㅎ

/*  ===========================================================================
*    누워서 읽는 알고리즘을 읽고서...
*   ============================================================================ */
누워서 읽는 알고리즘을 읽고서...

책이 두껍지도 않고 글자가 작지도 않고 소설처럼 읽을수 있는 책이였다.

책 내용또한 어려운것이 아니라 잠깐잠깐 나온 문제들을 생각할수 있는 형식의 책이였던것 같다.

지루하지 않게 읽으면서 금방 읽을수 있었다. 후기는 좀 늦었지만 말이다.

한번쯤 읽어 볼만한 책이기는 하다. 그렇지만 약간 아쉬운 면이 없지 않은 책이다.

후반부에 갈수록 소스코드로 지면을 채운다던지 하는 부분등... 친구에게 있다면 빌려 보는게 좋을듯..

아니면 틈틈히 서점이나 도서관에 가서 읽어도 될듯하다.
반응형





Want to write open source code?
Want to make money?
Want to do both?

지난 4년간 Google Summer of Code를 통해 전세계 약 2500명의 학생들이 수백만 라인에 달하는 코드를 작성하기 위해 180개 이상의 오픈소스 스프트웨어 프로젝트에 참여했습니다. 올해도 변함없이 Google에서는 최고의 Summer of Code 를 만드는데 동참할 학생들과 멘토들을 찾습니다! Google Summer of Code는 탁월한 성과를 보여준 학생 참가자들에게 3개월간 개발 프로젝트에 집중할 수 있도록 4500달러(USD)를 제공합니다.

Google Summer of Code 는 학생들의 오픈 소스 개발 참여를 권장하기 위해 기획된 프로그램입니다. 2005 년 시작된 이래, 프로그램은 다음과 같은 목표를 지향하고 있습니다.
· 젊고 패기있는 개발자의 오픈 소스 개발 참여를 권장합니다
· 컴퓨터과학 및 관련 분야의 학생들에게 여름을 이용하여 학업적 관심분야와 관련된 일을 할 수 있는 기회를 제공합니다
· 학생들이 실제 소프트웨어 개발 상황(분산된 개발 환경, 소프트웨어 라이선스 관련 문제들, 메일링 리스트 에티켓 등)을 접할 수 있게 합니다
· 모두에게 이로운 오픈 소스 코드를 더 많이 개발하고 보급합니다
· 오픈 소스 프로젝트들이 새로운 개발자와 기여자들을 발굴하고 참여를 유도하는데 기여합니다
Google 은 2009 년 3 월 9 일부터 13 일까지 오픈 소스 프로젝트들의 참가 신청서를 접수합니다.
학생 참가 신청서의 접수는 3 월 23 일부터 4월 3일까지 입니다.

참가 요건에 대한 세부사항(참여 방법 및 티셔츠 등)은 아래 웹페이지를 참고하세요.

http://code.google.com/soc/
Translations proudly provided by Google Summer of CodeTM community members.


작성자: 구글코리아 블로그 운영팀

반응형

URL Encoding Reference

ASCII Character URL-encoding
space %20
! %21
" %22
# %23
$ %24
% %25
& %26
' %27
( %28
) %29
* %2A
+ %2B
, %2C
- %2D
. %2E
/ %2F
0 %30
1 %31
2 %32
3 %33
4 %34
5 %35
6 %36
7 %37
8 %38
9 %39
: %3A
; %3B
< %3C
= %3D
> %3E
? %3F
@ %40
A %41
B %42
C %43
D %44
E %45
F %46
G %47
H %48
I %49
J %4A
K %4B
L %4C
M %4D
N %4E
O %4F
P %50
Q %51
R %52
S %53
T %54
U %55
V %56
W %57
X %58
Y %59
Z %5A
[ %5B
\ %5C
] %5D
^ %5E
_ %5F
` %60
a %61
b %62
c %63
d %64
e %65
f %66
g %67
h %68
i %69
j %6A
k %6B
l %6C
m %6D
n %6E
o %6F
p %70
q %71
r %72
s %73
t %74
u %75
v %76
w %77
x %78
y %79
z %7A
{ %7B
| %7C
} %7D
~ %7E
  %7F
%80
  %81
%82
ƒ %83
%84
%85
%86
%87
ˆ %88
%89
Š %8A
%8B
Œ %8C
  %8D
Ž %8E
  %8F
  %90
%91
%92
%93
%94
%95
%96
%97
˜ %98
%99
š %9A
%9B
œ %9C
  %9D
ž %9E
Ÿ %9F
  %A0
¡ %A1
¢ %A2
£ %A3
  %A4
¥ %A5
| %A6
§ %A7
¨ %A8
© %A9
ª %AA
« %AB
¬ %AC
¯ %AD
® %AE
¯ %AF
° %B0
± %B1
² %B2
³ %B3
´ %B4
µ %B5
%B6
· %B7
¸ %B8
¹ %B9
º %BA
» %BB
¼ %BC
½ %BD
¾ %BE
¿ %BF
À %C0
Á %C1
 %C2
à %C3
Ä %C4
Å %C5
Æ %C6
Ç %C7
È %C8
É %C9
Ê %CA
Ë %CB
Ì %CC
Í %CD
Î %CE
Ï %CF
Ð %D0
Ñ %D1
Ò %D2
Ó %D3
Ô %D4
Õ %D5
Ö %D6
  %D7
Ø %D8
Ù %D9
Ú %DA
Û %DB
Ü %DC
Ý %DD
Þ %DE
ß %DF
à %E0
á %E1
â %E2
ã %E3
ä %E4
å %E5
æ %E6
ç %E7
è %E8
é %E9
ê %EA
ë %EB
ì %EC
í %ED
î %EE
ï %EF
ð %F0
ñ %F1
ò %F2
ó %F3
ô %F4
õ %F5
ö %F6
÷ %F7
ø %F8
ù %F9
ú %FA
û %FB
ü %FC
ý %FD
þ %FE
ÿ %FF


URL Encoding Reference

The ASCII device control characters %00-%1f were originally designed to control hardware devices. Control characters have nothing to do inside a URL.

ASCII Character Description URL-encoding
NUL null character %00
SOH start of header %01
STX start of text %02
ETX end of text %03
EOT end of transmission %04
ENQ enquiry %05
ACK acknowledge %06
BEL bell (ring) %07
BS backspace %08
HT horizontal tab %09
LF line feed %0A
VT vertical tab %0B
FF form feed %0C
CR carriage return %0D
SO shift out %0E
SI shift in %0F
DLE data link escape %10
DC1 device control 1 %11
DC2 device control 2 %12
DC3 device control 3 %13
DC4 device control 4 %14
NAK negative acknowledge %15
SYN synchronize %16
ETB end transmission block %17
CAN cancel %18
EM end of medium %19
SUB substitute %1A
ESC escape %1B
FS file separator %1C
GS group separator %1D
RS record separator %1E
US unit separator %1F

<출처 : http://www.w3schools.com/tags/ref_urlencode.asp >
반응형


Common이라는 힙합 브랜드와 손을 잡고 DOS 같은 레트로 로고나 빌게이츠 젊은 시절 같은 오래된 사진 등으로  80년대 PC 초창기의 향수를 일으킨다고 합니다.

브랜드 이름부터 SOFTWEAR 입니다.   SOFTWARE 가 아니라 말이죠.. 센스 있네요.

마이크로소프트 매트릭스 티셔츠 ($9.99)



빌게이츠 머그샷 티셔츠 (현재 품절 상태)


Softwear 매장의 모습이랍니다.. 깔끔하네요.


갠적으로 디자인이 나와있는지는 잘 모르겠지만 옛날에 진짜인지 모르지만 블루스크린 티셔츠를

어떤 게시판에서 본거 같기도 한데요.. MS 브랜드라면 블루스크린 티셔츠 있지 않을까요?

ㅎㅎ 윈도우 하면 블루스크린 아니겠습니까.. 요새는 좀 보기 힘들지만...


반응형

딱히 후기라고 할것은 아닙니다.

전날 무리한 과음으로 인해(회식?!) 몸 상태가 별로 좋지 않았습니다.

그리고 당일날 회사에 출근을 해야했기 때문에 참석하지 못할뻔 하였습니다.

회사 출근후 몸상태가 좋지가 않아 점심이후 퇴근을 하고 집으로 향하던 길에...

꼭 듣고 싶던 세션이 있었기에.. 요새 관심을 가지고 있는 CI 부분 세션이 맘에 걸려..

발걸음을 돌리고 JCO 컨퍼런스로 향했습니다.. 사실 SUN 테크 블로거 선물도 궁금했습니다. ㅋ

3시쯤 가까스로 도착하여 듣고 싶었던  Continuous Integration with Hudson 최철우님  세션을 들을수 있었습니다.

그리고 SUN 부쓰에 가서 선물(볼펜통) 받았습니다.. ㅎㅎ

책상위에 올려놓고 사진 한컷 찍었습니다. 처음으로 저의 사무실 책상 사진입니다. 나름 깔끔합니다.

사무실 책상 사진..




SUN에서 테크 블로거에게 준 볼펜통과 JCO 볼펜..
Fire up your passion Again!    맘에 드는 말입니다.. ㅎㅎ 저도 다시 열정을 불태워야 할듯..

SUN 볼펜통과 볼펜



이번 JCO 각 부쓰에서 레드햇, 큐브리드, 썬, 등등 그리고 JCO 측  모두 경품등 많이 준비하셔서

다른 분들 손에는 다들 이것저것 한 보따리씩(?) 가지고 계시더군요.. 저는 늦게 가고 몸도 안좋아

경황이 없어 저것만 득하고 올수 밖에 없었습니다..

그리고 폐회식,경품추천 까지 마치고 집으로 아픈몸을 이끌고 터벅터벅 걸어와서.. 주말 내내 누었습니다.

장염과 몸살까지 겹쳐 아예 움직일수가 없네요.. ㅠㅠ 다시 나의 열정을 불태워야 하는데 말이죠..

뭐 딱히 후기라고 할껀 없습니다. 그냥 볼펜통이 넘 귀여워서 글 남깁니다..ㅎㅎ;

반응형
업무 과정중에 디비에 데이터를 넣는 과정에서 한글 깨짐현상이 발생하였다.

문제는 2가지 정도가 발생하였는데 디비간의 데이터 이동시에 해당 컬럼의 사이즈가 서로 달랐던 것이다.

source db 는  varchar(100)  target db는 varchar(70)  그로인해 한글데이터가 잘리는 경우가 발생하여

깨짐 현상이 발생하였고 데이터를 처리하여 다른 테이블에 INSERT 과정에서 깨진 데이터는

INSERT 가 되지 않았다. 그래서 데이터를 byte단위로 잘라서 target 테이블에 insert 하여야 했다.

해서 입력된 String을 byte 단위로 잘라서 마지막에 깨진 글자가 있을시에 빼고 리턴하는 메소드를 작성.


그리고 2번째 문제가 발생하였는데 잘못된 한글 표기로 인코딩의 문제로 String 중간에 깨진 글자 발생
이 문제는 DB의 인코딩 방식과 JAVA에서 처리된 인코딩 방식의 차이로 발생 하였는데..

해당 소스가 실행되는 환경에서 어떤 인코딩에 따라 한글이 깨지는지 확인 해 보도록 하자.
반응형
출처:  http://www.ibm.com/developerworks/kr/library/j-jdom/

JDOM은 XML과 함께 작동하는 고유한 자바 툴킷으로서, XML 애플리케이션의 신속한 개발을 목적으로 설계되었습니다. JDOM의 디자인에는 자바 언어의 신택스부터 의미까지 포괄되어 있습니다. 하지만, 기존의 XML API보다 과연 얼마나 나을까요? 여러분이 직접 예제를 실행해 보고, 오픈 소스 프로젝트의 디자인 목표와 비교하면서 판단해 봅시다.

개발자인 여러분들도 80-20 규칙에 대해 들어봤을 것이다. 프로세스나 방법론이 모든 상황의 80 퍼센트를 차지하고, 나머지 20 퍼센트는 상황 별로(case-by-case) 다루어져야 한다. 소프트웨어 개발 세계에서 개발자가 주어진 기술을 사용하여 수행할 수 있는 일들의 80 퍼센트를 이룩하기는 매우 쉽다.

물론, 소프트웨어 제품과 표준이 80-20 규칙을 늘 따르는 것은 아니다. 특히 자바 XML 툴의 어긋난 부분은 이 규칙의 예외를 증명하고 있다. 자바 프로그래밍 세계는 수 많은 API들로 가득 차있다. 어떤 것은 자생한 것이고, 어떤 것은 대기업의 마케팅의 지원을 받기도 한다. XML의 보편성에 대한 약속으로서, 모든 새로운 태스크에는 새로운 기술이 있다. 하지만, 무엇이 접착제 역할을 하고, 여러분은 80 퍼센트의 작업을 수행하는데 적합한 툴을 어떻게 찾겠는가? JDOM은 이러한 질문을 염두 해 두고 구현된 XML API이다.

자바와 XML

여러 가지 면에서, 자바 언어는 XML을 위한 프로그래밍 언어가 되었다. Apache Software Foundation과 IBM alphaWorks의 노력으로 XML 문서의 생성, 조작, 변형, 파싱을 위한 완전한 툴 체인이 생겼다.

많은 자바 개발자들은 XML을 매일 사용하지만, Sun은 XML을 자바 플랫폼에 적용하는데 뒤쳐졌다. Java 2 플랫폼은 XML이 비즈니스 대 비즈니스 통합부터 웹 사이트 콘텐트 스트리밍에 이르기까지 모든 것에 대한 핵심 기술이 되기 전에 가치 있는 것이 되었기 때문에 Sun은 폭넓은 채택성을 획득했던 기존 XML API의 창시자가 되는 JSR 프로세스를 사용해왔다. 가장 중요한 것은 JAXP(Java API for XML Parsing)의 추가이다. 여기에는 세 개의 패키지들이 포함된다.

  • org.w3c.dom: XML을 위한 표준 프로그래밍 방식의 Document Object Model의 W3C recommendation의 자바 구현.
  • org.xml.sax: XML 파싱을 위한 이벤트 중심의 API.
  • javax.xml.parsers: 애플리케이션 개발자들이 특정 파서 구현을 설정하고 획득할 수 있도록 해주는 팩토리 구현.

이러한 패키지들의 추가가 자바 개발자들에게는 좋은 일이지만, 고급의 자바-XML 상호 운용성으로 큰 도약을 이룬 것이 아닌 기존 API 표준에 대한 일반적인 순응을 나타낸다. 핵심 자바 플랫폼에서 부족한 것은 XML 문서를 자바 객체로서 조작할 수 있는 매력적인 인터페이스이다.

JDOM을 생각해 보자. 유명한 자바 개발자이자 작가인 Brett McLaughlin과 Jason Hunter의 생각의 산물인 JDOM은 2000년 초반에 Apache 계열의 라이센스 하에서 오픈 소스 프로젝트로서 시작되었다. 폭넓은 자바 개발자 베이스로부터 기여와 피드백, 버그 픽스를 받아들였고, 자바 코드에서 XML 데이터에 액세스 하여, 조작 및 결과를 만들어 내는 완벽한 자바 플랫폼 기반의 솔루션 구현을 목표로 설정했다.






API로서의 JDOM

JDOM은 XML 문서들을 프로그래밍 방식으로 조작하는 org.w3c.dom 패키지에 대한 대안으로서 사용될 수 있다. 완벽한 대체는 아니고, 사실, JDOM과 DOM은 공존할 수 있다. 게다가, JDOM은 텍스트 인풋에서 XML을 파싱하는 것을 신경 쓰지 않는다. 파서 구현을 설정 및 실행하는데 도움이 되는 래퍼 클래스를 제공하기도 한다. JDOM은 기존 API를 기반으로 구현되었다.

대안 API의 필요성을 이해하려면, W3C DOM의 디자인 제약 조건에 대해 살펴보자.

  • 언어 독립성. DOM은 자바 언어를 염두 해 두고 설계되지 않았다. 이것의 접근 방식은 다양한 언어들 사이에서 매우 비슷한 API를 유지하지만, 자바의 이디엄에 익숙한 프로그래머에게는 성가신 API이다. 예를 들어, 자바 언어는 String 클래스가 언어에 구현되어 있지만, DOM 스팩은 고유의 Text 클래스를 정의한다.

  • 엄격한 계층. DOM의 API는 XML 스팩을 따른다. 따라서, 모든 것의 노드가 되는 XML에서, 모든 것이 확장하는 DOM에서 Node 기반 인터페이스와 Node를 리턴하는 메소드의 호스트를 찾는다. 이는 다형성의 관점에서 볼 때는 뛰어나지만, 자바 언어로 작업하기에는 불편하다. Node에서 리프(leaf) 유형으로의 변화는 장황하고 이해하기 어려운 코드를 만든다.

  • 인터페이스 중심. 퍼블릭 DOM API는 인터페이스들로만 구성된다. (한 가지 예외는 Exception 클래스이다.) W3C는 인터페이스를 정의할 때 구현을 제공하는 것에는 관심이 없다. 자바 프로그래머로서 API를 사용한다는 것은 XML 객체들을 생성할 때 어느 정도의 분리가 된다. W3C 표준은 일반적인 팩토리 클래스와 유연하지만 덜 직접적인 패턴들을 사용하기 때문이다. XML 문서들이 애플리케이션 레벨 코드가 아닌 파서에 의해서만 구현되는 특수한 경우, 이는 무관하다. 하지만, XML 사용이 널리 퍼지면서, 애플리케이션 개발자들은 XML 객체들을 프로그래밍 방식으로 구현하는 편리한 방법을 필요로 하게 되었다.

프로그래머에게, 이러한 제약 조건은 (메모리 사용과 인터페이스 규모 면에서) 무겁고 다루기 어렵다는 것을 의미한다. 반대로, JDOM은 자바 중심의, 경량의 API이다. DOM의 원리를 조정하여 위에 언급한 불편함을 해소시켰다.

  • JDOM은 자바 플랫폼 식이다. 이 API는 자바 언어의 빌트인 String 지원을 사용하기 때문에, 텍스트 값은 String으로서 언제나 사용할 수 있다. ListIterator 같은 Java 2 플랫폼 컬렉션 클래스도 활용하면서 자바 언어에 익숙한 프로그래머에게 풍부한 환경을 제공한다.

  • 계층이 없음. JDOM에서, XML 엘리먼트는 Element의 인스턴스이고, XML 애트리뷰트는 Attribute의 인스턴스이며, XML 문서는 Document의 인스턴스이다. 이 모든 것들이 XML에서 다른 개념들을 나타내기 때문에, 무정형의 "노드"로서가 아닌 고유의 유형으로서 참조된다.

  • 클래스 중심. JDOM 객체는 Document, Element, Attribute 같은 클래스들의 직접적인 인스턴스이므로, 이를 구현하는 것은 자바 언어에서 new 연산자를 사용하는 것만큼이나 쉽다. 또한 설정 할 팩토리 인터페이스가 없다. JDOM은 jar에서 직접 사용할 준비가 되어있다.





JDOM 문서 구현 및 조작

JDOM은 표준 자바 코딩 패턴을 사용한다. 가능하다면, 복잡한 팩토리 패턴 대신에 자바 new 연산자를 사용하면서, 신참 사용자들도 객체를 쉽게 조작할 수 있게 해준다. JDOM을 사용하여 XML 문서를 구현하는 방법을 살펴보자. 우리가 구현할 구조는 Listing 1과 같다. (참고자료 섹션에서 전체 코드를 다운로드 할 수 있다.)


Listing 1. 구현할 XML 문서 샘플
                

<?xml version="1.0" encoding="UTF-8"?>
<car vin="123fhg5869705iop90">
  <!--Description of a car-->
  <make>Toyota</make>
  <model>Celica</model>
  <year>1997</year>
  <color>green</color>
  <license state="CA">1ABC234</license>
</car>

주: 아래 Listing 2부터 7까지 샘플 문서를 구현할 것이다.

먼저, 루트(root) 엘리먼트를 만들고 이를 문서에 추가한다.


Listing 2. Document 구현하기
                

Element carElement = new Element("car");
Document myDocument = new Document(carElement);

이 단계는 새로운 org.jdom.Element를 만들고, 이것을 org.jdom.Document myDocument의 루트 엘리먼트로 만든다. (참고자료 섹션에서 제공하는 샘플 코드를 사용하고 있다면 반드시 org.jdom.*을 반입하라.) XML 문서는 하나의 루트 엘리먼트를 가져야 하므로, Document는 생성자에 Element를 취한다.

다음에는, vin 애트리뷰트를 추가한다.


Listing 3. Attribute 추가하기
                

carElement.addAttribute(new Attribute("vin", "123fhg5869705iop90"));

엘리먼트를 추가하는 것도 매우 단순하다. make 엘리먼트를 추가한다.


Listing 4. 엘리먼트와 하위 엘리먼트
                

Element make = new Element("make");
make.addContent("Toyota");
carElement.addContent(make);

ElementaddContent 메소드가 Element를 리턴하므로, 이를 다음과 같이 작성할 수 있다.


Listing 5. 간결한 형식으로 엘리먼트 추가하기
                

carElement.addContent(new Element("make").addContent("Toyota"));

이 문장들 모두 같은 일을 수행한다. 첫 번째 예제는 보다 읽기 쉽지만, 두 번째는 많은 엘리먼트들을 한번에 구현한다면 더욱 읽기 쉬울 것이라고 말할 수도 있겠다. 문서 구현을 완료하려면 다음과 같이 한다.


Listing 6. 나머지 엘리먼트 추가하기
                

carElement.addContent(new Element("model").addContent("Celica"));
carElement.addContent(new Element("year").addContent("1997"));
carElement.addContent(new Element("color").addContent("green"));
carElement.addContent(new Element("license")
    .addContent("1ABC234").addAttribute("state", "CA"));

license 엘리먼트의 경우, 엘리먼트의 콘텐트를 추가했을 뿐만 아니라, 여기에 애트리뷰트도 추가하면서, 라이센스가 발행되었던 상태를 지정하고 있다. Element에 대한 addContent 메소드는 Element만 리턴하기 때문에 이것이 가능하다.

주석 섹션이나 기타 표준 XML 유형을 추가하는 것도 같은 방식이다.


Listing 7. 주석 추가하기
                

carElement.addContent(new Comment("Description of a car"));

문서 조작은 비슷한 방식으로 발생한다. 예를 들어, year 엘리먼트에 대한 레퍼런스를 획득하려면, ElementgetChild 메소드를 사용한다.


Listing 8. 자식 엘리먼트에 액세스 하기
                

Element yearElement = carElement.getChild("year");

이 문은 실제로 엘리먼트 이름 year를 가진 자식 Element를 리턴한다. year 엘리먼트가 없다면, 호출은 어떤 것도 리턴하지 않는다. DOM Node Node 인터페이스 같은 것에서 리턴 값을 던질 필요가 없었다. Element의 자식 들은 단순히 Element이다. 비슷한 방식으로, 문서에서 year 엘리먼트를 제거할 수 있다.


Listing 9. 자식 엘리먼트 제거하기
                

boolean removed = carElement.removeChild("year");

이 호출은 year 엘리먼트만 제거한다. 나머지 문서는 바뀌지 않은 채로 남아있다.

엘리먼트만 제거한다. 나머지 문서는 바뀌지 않은 채로 남아있다. XMLOutputter 클래스를 사용한다.


Listing 10. JDOM을 XML 텍스트로 바꾸기
                

try {
    XMLOutputter outputter = new XMLOutputter("  ", true);
    outputter.output(myDocument, System.out);
} catch (java.io.IOException e) {
    e.printStackTrace();
}

XMLOutputter는 포맷팅 옵션을 갖고 있다. 여기에서, 우리는 부모 엘리먼트에서 두 스페이스를 들여쓰기 한 자식 엘리먼트를 원한다고 지정했고, 엘리먼트들 사이에 새로운 라인을 원한다는 것을 지정했다. XMLOutputterWriter 또는 OutputStream을 출력한다. 파일로 출력하려면 아웃풋 라인을 다음과 같이 바꾼다.


Listing 11. FileWriter를 사용하여 XML 출력하기
                

FileWriter writer = new FileWriter("/some/directory/myFile.xml");
outputter.output(myDocument, writer);
writer.close();






기존 XML 툴과 결합하기

JDOM의 재미있는 기능들 중 하나는 다른 API들과의 상호 운용성이다. JDOM을 사용하여, Stream 또는 Reader 뿐만 아니라, SAX Event Stream 또는 DOM Document로서도 문서를 출력할 수 있다. 이러한 유연성 때문에 JDOM이 이종의 환경에서 사용될 수 있고, XML을 핸들링 하는 또 다른 메소드를 이미 사용하고 있는 시스템에 추가될 수 있다. 나중에 예제에서 보겠지만, JDOM은 JDOM 데이터 구조를 인식하지 못하는 다른 XML 툴을 사용할 수 있다.

JDOM의 또 다른 사용법은 이미 존재하는 XML 데이터를 읽고 조작하는 기능이다. 잘 구성된 XML 파일을 읽는 것은 org.jdom.input의 클래스들 중 하나를 사용함으로써 수행된다. 이 예제에서, 우리는 SAXBuilder를 사용할 것이다.


Listing 12. SAXBuilder를 사용하여 XML 파일 파싱하기
                

try {
  SAXBuilder builder = new SAXBuilder();
  Document anotherDocument = 
    builder.build(new File("/some/directory/sample.xml"));
} catch(JDOMException e) {
  e.printStackTrace();
} catch(NullPointerException e) {
  e.printStackTrace();
}

Listing 2부터 7까지의 방식과 똑같이 이 프로세스를 통해 구현된 문서를 조작할 수 있다.

JDOM의 또 다른 적용은 이를 Apache의 Xalan 제품과 결합하는 것이다. (참고자료) 위 자동차 예제를 사용하여, 특정 자동차에 대한 상세를 제공하는 온라인 자동차 딜러용 웹 페이지를 구현할 것이다. 우선, 이 문서는 우리가 사용자에게 제공하고자 하는 자동차에 대한 정보를 나타낸다. 그런 다음, 이 JDOM Document를 XSL 스타일 시트로 결합하고, HTML 포맷의 결과를 서블릿의 OutputStream으로 출력할 수 있다.

이 경우, 우리가 사용할 XSL 스타일시트는 car.xsl이다.


Listing 13. 자동차 기록을 HTML로 변형하는 XSL 문서
                

<?xml version="1.0" encoding="UTF-8"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/car">
    <html>
        <head>
          <title><xsl:value-of select="make"/> <xsl:value-of select="model"/>
        </head>
        <body>
          <h1><xsl:value-of select="make"/></h1><br />
          <h2><xsl:value-of select="model"/></h2><br />
          <table border="0">
          <tr><td>VIN:</td><td><xsl:value-of select="@vin"/></td></tr>
          <tr><td>Year:</td><td><xsl:value-of select="year"/></td></tr>
          <tr><td>Color:</td><td><xsl:value-of select="color"/></td></tr>
          </table>
        </body>
    </html>
  </xsl:template>
</xsl:stylesheet>

이제, org.jdom.Document를 DOM Document로 바꾸고, 이것을 Xalan에 제공한다. XSL과 가상의 애플리케이션 서버에서 가져온 OutputStream을 나타내는 파일도 함께 제공한다. (Listing 14)


Listing 14. JDOM과 Xalan을 사용하여 HTML 문서 생성하기
                

TransformerFactory tFactory = TransformerFactory.newInstance();

// Make the input sources for the XML and XSLT documents
org.jdom.output.DOMOutputter outputter = new org.jdom.output.DOMOutputter();
org.w3c.dom.Document domDocument = outputter.output(myDocument);
javax.xml.transform.Source xmlSource = 
  new javax.xml.transform.dom.DOMSource(domDocument);
StreamSource xsltSource = 
  new StreamSource(new FileInputStream("/some/directory/car.xsl"));

// Make the output result for the finished document using 
// the HTTPResponse OutputStream
StreamResult xmlResult = new StreamResult(response.getOutputStream());

// Get a XSLT transformer
Transformer transformer = tFactory.newTransformer(xsltSource);

// Do the transform
transformer.transform(xmlSource, xmlResult);

이 예제에서, 아웃풋은 자바 서블릿의 HTTPResponse OutputStream을 통해 체계화 된다. 하지만, 이 스트림은 XMLOutputter를 사용한 이전 예제처럼 쉽게 파일스트림이 될 수 있다. 우리는 DOMOutputter를 사용하여 Xalan용 XML 소스를 생성했다. 하지만, XMLOutputter를 사용하여 XML 문서를 String으로서 출력하고 이를 StreamSource로 만듦으로써 같은 인풋을 생성할 수 있었다. 유연성에 대해서 보자. JDOM은 그 구조를 String, SAX Event Stream, 또는 DOM Document로서 출력할 수 있다. 이는 JDOM이 인풋으로서 이러한 모델을 취할 수 있는 툴과 상호 작동할 수 있도록 해준다. (JDOM 웹 사이트에서 contrib 패키지를 참조하라. 여기에서 JDBC ResultSet-기반 빌더, XPATH 구현 같은 툴을 제공하는 JDOM 기반 유틸리티의 라이브러리를 찾을 수 있다.)

몇 줄의 코드로, JDOM은 다양한 기능을 실행한다. 우리는 XML에서 파싱하고 프로그래밍 방식으로 XML 문서를 생성하고, 그러한 문서들을 조작했고, XML 중심의 웹 페이지를 생성하는데 이를 사용했다.

Sun과 JDOM
JDOM의 공식 1.0 릴리스는 Java Community Process의 진행 과정과 발을 맞춘다. JSR-102로서 제출된 JDOM은 핵심 자바 플랫폼에 들어가도록 승인을 얻었다. 다음은 Sun 측에서 말한 부분이다. "JDOM은 이전 API들보다 사용하기가 훨씬 더 쉽기 때문에, 이 플랫폼에 매우 유용할 것이라고 생각한다." JSR에 따르면, 1.0 릴리스는 JDOM의 패키징 변화를 "org.jdom"에서 "javax.xml.tree"로 간주하고 있다. 미래는 긍정적이지만, 개발자들은 새로운 버전에 발을 맞추려면 코드를 개선해야 한다.





JDOM의 성장: 미래

이 글을 쓰고 있는 현재, JDOM 프로젝트는 Beta 6 버전을 릴리스 했다. 베타 상태임에도, JDOM은 안정적인 구현으로 입증되었다. API의 많은 부분이 안정적이고, 기존 인터페이스들에 잠재적으로 영향을 줄 많은 부분에서 작업이 진행 중이다. 따라서, 이 시점에서 진행되는 어떤 개발 프로젝트라도 JDOM을 무시해서는 안되겠다. 특정 메소드 시그너처와 특정 의미가 바뀔 것이고 핵심 자바 API에 채택될 것이기 때문이다. (Sun과 JDOM 참조)

JDOM을 위한 단기적인 TO-DO 리스트는 API를 안정화 하고 성능 부분을 평가하는 것에 초점이 맞춰졌다. 개발자들을 애먹이는 부분에는 DTD 엔터티 지원과 기타 구조들이다. XPATH 지원과 보다 직접적인 XML 데이터 소스와의 통합 등이 진행 중이다.

그래서, JDOM은 기존 XML API들보다 더 나은가? 여러분이 자바로 꿈을 꾼다면 대답은 '그렇다'이다. JDOM이 여러분이 선호하는 파서나 XML 인식 데이터베이스를 대체하는 것은 아니지만, 이것의 디자인 원리는 XML 세계에 적용될 수 있다.



참고자료

반응형
출처: http://kr.blog.yahoo.com/kwon37xi/folder/3381246.html

Java와 XML 데이터 바인딩이란 XML 파일을 자바 객체로 바꾸는 것이다.(DOM 객체로 만든다는 의미가 아니다)


예를들어 다음과 같은 XML이 있을 때
<AddressBook>
   <Person>
      <Name>홍길동</Name>
      <Address>서울</Address>
      <Phone>02-123-4567</Phone>
   </Person>
</AddressBook>
  • 위와 같은 상황에서 AddressBook, Person, Name, Address, Phone이라는 클래스를 생성해주고
  • XML 데이터를 입력하면 최상위 요소인 AddressBook의 객체가 생성되는 것이다.
  • AddressBook의 객체를 ab라고 할 때 ab.getPerson()하면 Person의 객체를 얻게 된다.
  • Person객체를 person이라 할 때 person.getName()Name객체를 리턴하거나 혹은 직접적으로 문자열 "홍길동"을 리턴하는 식이다.

클래스 생성

클래서 생성은 XML의 제약 집합(DTD, XML Schemas)로부터 자바 클래스를(가능하다면 인터페이스를) 생성하는 과정이다. XML 제약집합을 자바 클래스 정의와 동일하게 간주하면 된다.

언마샬링(Unmarshalling)

언마샬링은 XML 문서를 자바 클래스의 인스턴스로 변환하는 것을 의미한다.

단순히 XML 문서를 얻고 그 문서를 데이터 바인딩 프레임워크가 제공하는 도구나 클래스 인스턴스에 전달한 후, XML문서에 해당하는 자바 객체를 구하면 된다. 이때 생성된 자바 객체는 일반적으로 문서를 나타내는 최상의 부모 클래스의 인스턴스이다.

마샬링(Marshalling)

마샬링은 자바 객체와 이 객체에 종속적인 객체를 XML 형태로 변환하는 과정이다.

Castor

  • http://castor.exolab.org
  • 오픈 소스 XML 데이타 바인딩 프레임워크
  • Xerces 와 castor-버전-xml.jar 가 필요하다.

바잉딩 클래스 생성하기

  • XML Schemas 를 작성한다.
  • 다음을 실행하면 스키마에 따라 -package에 지정된 패키지로 클래스들이 생성된다.

    java org.exolab.castor.builder.SourceGenerator -i catalog.xsd -package javaxml2.castor
    

Unmarshall

File catalogFile = new File("catalog.xml");
InputSource is = new InputSource(new FileInputStream(catalogFile));

// Root 요소 클래스와 InputSource를 인자로 넘겨서 Unmarshalling을 수행한다.
Catalog catalog = (Catalog)Unmarshaller.unmarshal(Catalog.class, is);
  • InputSource 대신 Reader를 사용해도 되지만 문자 인코딩 문제가 발생할 수 있으므로 InputSource가 나은 것 같다.

Marshalling


// 변경된 카탈로그를 다시 파일에 저장한다.
FileWriter writer = new FileWriter(catalogFile);

Marshaller marshal = new Marshaller(writer);
marshal.setEncoding("euc-kr");
marshal.marshal(catalog);
  • 저기서 XML의 문자 인코딩을 지정했는데, 이것은 Writer의 인코딩과 일치해야 한다. 여기서는 운영체제 문자 인코딩이 EUC-KR 이다.
  • 다음 과 같이 Marshaller의 객체를 생성하지 않고 static 메소드로 해도 된다. 하지만 이럴 경우 운영체제의 문자 인코딩이 UTF-8이 아니라면 문자 인코딩 문제가 발생할 수 있다. 이 경우에 Writer의 인코딩을 UTF-8로 맞춰야 한다.

    Marshaller.marshal(catalog, writer);
  • 반응형
    출처: http://kr.blog.yahoo.com/kwon37xi/folder/3381246.html


    • JAXP는 새로운 기능을 제공하는 것이 아니라 기존의 SAX, DOM 파서들을 래핑해서 벤더 중립적으로 SAX와 DOM 기능을 사용할 수 있게 해준다.
    • JAXP는 XML 분석 기능을 제공하지 않는다. 즉, SAX, DOM 혹은 그 이외의 XML 파싱 API 없이 JAXP만 가지고는 XML을 분석할 수 없다.
    • SAX, DOM 그리고 JDOM은 XML을 분석하는데 사용된다. 반면 JAXP는 이러한 API와 분석된 문서의 결과를 얻는 방법을 제공한다. JAXP 자체는 문서를 분석하는 새로운 방법을 제공하는 것은 아니다.
    • 결론 : JAXP는 새로운 작업을 수행하기 위한 API가 아니라 기존에 존재하는 API를 추상화시켜 특정 벤더에 종속적인 코드를 전혀 쓰지않고 하나의 단일된 형태로 사용할 수 있게 만든 중간계층이다.

    JAXP 1.0 with SAX

    • SAX 1.0만 지원한다.
    • SAX 처리 파서와 함께 JAXP를 사용하려면 org.xml.sax.HandlerBase 클래스를 확장하고 애플리케이션에서 처리하려는 콜백들을 구현하면 된다. HandlerBase는 SAX 2.0의 DefaultHandler와 같은 역할을 한다.
    • JAXP는 자바 시스템 Property를 통해서 벤더 클래스의 파서를 지정할 수 있다.

    SAX 사용순서

    • SAXParserFactory 클래스의 객체를 생성한다.
    • SAXParserFactory는 SAX 파서의 인스턴스를 생성하고, 파서의 옵션을 설정하는 역할을 한다.
    • SAXParserFactory에서 설정한 옵션들은 그것을 통해 얻은 모든 파서의 인스턴스에 적용된다.
      • SAXParserFactory.setNamespaceAware(boolean) : 네임스페이스 인식 여부
      • SAXParserFactory.setValidating(boolean) : 유효성 검사 여부
    • 일단 SAXParserFactory를 설정하고 나면, SAXParserFactory.newSAXParser() 메소드를 사용하여 파서에 해당하는 SAXParser 클래스(JAXP에 포함된 클래스임)의 인스턴스를 구할 수 있다.
    • SAXParser.parse()로 XML 파싱을 수행한다.
      // JAXP import
      import javax.xml.parsers.*;
      
      // SAX import
      import org.xml.sax.*;
      
      // SAXParserFactory를 얻는다.
      SAXParserFactory factory = SAXParserFactory.newInstance();
      
      // 유효성 검사를 수행하고, 네임스페이스를 인식하지 않도록 설정
      factory.setValidating(true);
      factory.setNamespaceAware(false);
      
      // SAXParser를 얻어 파싱을 한다.
      SAXParser parser = factory.newSAXParser();
      parser.parse(new File(xmlFileName), new MyHandlerBase());
      // MyHandlerBase는 org.xml.sax.HandlerBase 를 상속한 클래스이다.
      

    발생 가능한 예외

    • FactoryConfigurationError : 일반적으로 파서가 사용하는 JAXP 구현 클래스나 시스템 Property를 불러올 수 없을 경우에 발생한다.
    • ParserConfigurationException : 파서에서 사용할 수 없는 특징을 설정할 때 발생한다.

    SAXParser 클래스

    • SAXParser.isValidating() : 유효성 검사 수행 여부
    • SAXParser.isNamespaceAware() : 네임스페이스 인식 여부
    • SAXParser 클래스는 위 두 특징을 변경할 수 있는 메소드는 제공하지 않는다. SAXParserFactory에서 변경해야 한다.
    • SAXParser.getParser() : 내부적으로 실제 사용하는 파서의 객체(org.xml.sax.Parser의 인스턴스)

    JAXP 1.0 with DOM

    • SAX와 거의 동일하다.
    • 파싱 후 Document 객체를 리턴한다.

    DOM 사용 순서

    • DocumentBuilderFactory 클래스의 인스턴스를 얻는다.
    • factory 객체에서 설정할 사항들을 설정하고,
    • DocumentBuilder를 DocumentBuilderFactory로 부터 얻는다.
    • DocumentBuilder로 파싱을 수행해서 Document 객체를 얻는다.
      // DocumentBuilderFactory를 얻는다.
      DocumentBuilderFactory factory =
        DocumentBuilderFactory.newInstance();
      
      // 여러가지 설정...
      
      // DocumentBuilder 얻기
      DocumentBuilder builder = factory.newDocumentBuilder();
      
      // XML 파싱 수행
      Document doc = builder.parse(new File(xmlFileName));
      

    발생 가능한 예외

    SAX와 동일하다.

    DocumentBuilder 클래스

    • SAX 이벤트를 처리하지 않으므로 HandlerBase 인스턴스가 필요없다.
    • DocumentBuilder.parse()는 곧바로 Document 객체를 리턴한다.
    • SAX의 ErrorHandler를 위한 DocumentBuilder.setErrorHandler()
    • SAX의 EntityResolver를 위한 DocumentBuilder.setEntityResolver()

    네임스페이스?

    JAXP 1.0은 네임스페이스를 처리하지 않는다. "지원"만 할 뿐이다.

    JAXP 1.1은 네임스페이스를 처리할 수 있다.

    파서의 변경

    • JAXP가 사용하는 파서를 변경한다는 것은 실제로 파서를 생성하는 Factory를 변경한다는 의미이다.
    • SAXParserFacotry 변경 : javax.xml.parsers.SAXParserFactory 시스템 프라퍼티로 설정
    • DocumentBuilderFactory 변경 : javax.xml.parsers.DocumentBuilderFactory 시스템 프라퍼티로 설정

    JAXP 1.1

    • XSLT 프로세서는 javax.xml.transform.TransformerFactory 시스템 프라퍼티로 설정할 수 있다.

    1.1에서 바뀐점

    • SAX 2.0과 DOM Level 2를 지원한다.
    • 네임스페이스를 처리한다.
    • SAX 2.0으로 넘어가면서 Parser 인터페이스는 디프리케이티드 되었다. 대신 org.xml.sax.XMLReader를 사용한다.
    • SAXParser.getXMLReader()가 추가되었다.
    • SAXParser에 SAX 2의 DefaultHandler를 인자로 받는 parse() 메소드를 추가했다.
    • SAXParserFactory.setFeature(), SAXParserFactory.getFeature()가 추가되었다.
    • SAXParser.setProperty(), SAXParser.getProperty()가 추가되었다.

    TrAX API : XSL을 위한 API

    • XML 문서 변환을 벤더에 중립적으로 처리할 수 있다.
    • 다음과 같은 순서로 XSL 변환을 처리한다.
      1. TransformerFactory를 얻는다.
      2. Transformer를 얻는다.
      3. 변환을 수행한다.

    Factory

    • javax.xml.transform.TransformerFactory 팩토리 객체를 생성한다.
    • 팩토리 객체에 다양한 옵션을 설정한다. 이 옵션들은 이 팩토리에서 생성되는 모든 Tansformer 인스턴스에 영향을 주게 된다.
      • 속성 설정(각 XSL 프로세서에 종속적임). TransformerFactory.setAttribute(), TransformerFactory.getAttribute()
      • ErrorListener 설정 : 분석도중에 발생하는 문제를 프로그램에서 처리시킨다. javax.xml.transform.ErrorListener 인터페이스 구현. TransformerFactory.setErrorListener()로 설정.
      • URIResolver 설정 : xsl:import 혹은 xsl:include 등에서 가져올 XML 데이터를 Source 객체로 제공해준다. 특정 URI를 만났을 때 Transformer가 여러 곳에 있는 특정 문서를 검색할 수 있게 해준다. javax.xml.transform.URIResolver 인터페이스 구현. TransformerFactory.setURIResolver()로 설정.
    • TansformerFactory.newTransformer()는 변환에 사용되는 스타일시트를 입력으로 받아들인다.

      // TransformerFactory를 얻는다.
      TransformerFactory factory = TransformerFactory.newInstance();
      
      // TransformerFactory를 구성한다.
      factory.setErrorResolver(myErrorResolver);
      factory.setURIResolver(myURIResolver);
      
      // 명시된 옵션들을 가지는 작업에 사용할 Transformer를 얻는다.
      Transformer transformer =
         factory.newTransformer(new StreamSource("foundation.xsl"));
      

    XML 변환

    • 스타일시트의 위치는 반드시 그것의 위치를 나타내는 javax.xml.transform.Source의 인스턴스를 사용해 명시한다.
    • Source 인터페이스 : 스타이시트, XML 혹은 다른 정보들의 집할일 수 있는 입력의 위치
      • StreamSource : InputStream, Reader, 시스템 아이디로 입력 받음
      • DOMSource : DOM 트리에서 데이터 읽기. org.w3c.dom.Node를 인자로 받음. 이미 DOM파싱이 된 문서를 사용할 때는 DOMSource를 써야 성능이 더 좋다.
      • SAXSource : SAX 생성기로 부터 데이타 읽기. InputSource혹은 XMLReader를 입력으로 받는다. SAX 컨텐트 핸들러가 이미 사용중이고, 콜백이 설정되고 변환에 앞서 특정 작업을 처리해야 할 경우라면 SAXSource를 사용하는 것이 좋다.
    • 변환 결과는 javax.xml.transform.Result의 인스턴스로 받는다.
    • Result 인터페이스 : 변환된 문서를 출력할 목표 지정
      • StreamResult
      • DOMResult
      • SAXResult : SAX의 ContentHandler를 인스턴스로 넘겨 받는다.
        // 명시된 옵션들을 가지는 작업에 사용할 Transformer를 얻는다.
        Transformer transformer =
            factory.newTransformer(new StreamSource("foundation.xsl"));
        
        // 변환을 수행하고 결과 출력
        transformer.transform(new StreamSource("asimov.xml"),
                              new StreamResult("results.xml"));
        

    SourceLocator

    • SourceLocator 인터페이스는 동작이 발생한 위치에 대한 정보를 제공한다.
    • DOMLocator 인터페이스는 처리중인 DOM 노드를 반환하는 getOriginatingNode()라는 메소드가 추가되어 있다.

    OutputKeys

    • javax.xml.transform.OutputKeys 클래스는 TrAX의 변환을 위한 출력 Property를 위해 몇몇 상수를 정의하고 있다.

    Templates

    • 여러번 재활용되고 다중 쓰레드에서 사용할 Transformer를 생성한다.
    • Templates 인터페이스는 출력 Property의 집합을 여러 개의 변환작업에 똑같이 적용하고 싶거나, 변환 지시어들의 집합을 연속적으로 사용하고 싶을 때 사용한다.
      TransformerFactory factory = TransformerFactory.newInstance();
      
      // Templates 객체를 얻는다.
      Template template =
          factory.newTemplates(new StreamSource("html.xsl"));
      
      // Transformer의 인스턴스를 얻는다.
      Transformer transformer = template.newTransformer();
      
      // 변환
      transformer.transform(new DOMSource(orderForm), new StreamResult(res.getOutputStream()));
      
    • 하나의 스타일시트를 두 번이상 사용하면 Templates 객체를 사용하는 것이 좋다.
    • XSL 스타일시트를 자바 객체로 변환하는 과정을 반복하지 않으므로 더 성능이 좋다.
    • 다중 쓰레드 환경에서는 Templates 꼭 사용해야 한다.

    JAXP 설정

    $JRE_HOME/lib/ext 디렉토리에 jaxp.properties 파일을 만들고 원하는 팩토리를 설정해 둘 수 있다.
    반응형
    출처: http://kr.blog.yahoo.com/kwon37xi/folder/3381246.html


    TEXT 클래스

    • org.jdom.Text
    • Element 클래스는 getText() 메소드로 텍스트를 얻을 수 있지만, 내부적으로는 Text 클래스의 인스턴스를 만들어서 요소의 텍스트를 저장한다.
    • 이렇게 한 이유는 트리모델에서 탐색을 용이하게 하기 위해서이다.

    EntityRef 클래스

    • org.jdom.EntityRef
    • XML 엔티티 참조를 나타낸다.
    • 만약 엔티티가 XML DTD나 스키마를 참조한다면, 이 클래스로 이름, 공개ID, 시스템ID를 설정하거나 반환할 수 있다.
    • JDOM 컨텐트 트리의 어디에나 위치할 수 있다.
    • 거의 사용되지 않는다.
    • EntityRef를 사용하기 위해서는 엔티티 확장을 하지 않게 해야한다.

      SAXBuilder builder = new SAXBuilder();
      
      // 엔티티 참조를 확장하지 않는다.(기본값은 true)
      builder.setExpandEntities(false);
      
      // EntityRef 객체를 포함하는 트리 생성
      Document doc = builder.build(inputStream);
      
    • 엔티티 확장을 true로 하면 엔티티를 만날 때는 실제 엔티티의 값으로 바뀐 것을 읽게 된다.
    • 엔티티 참조 생성

      EntityRef ref = new EntityRef("TrueNorthGuitarsTagline");
      ref.setSystemID("tngTagline.xml");
      
      // 트리에 넣는다.
      tagLineElement.addContent(ref);
      

    Namespace 클래스

    • org.jdom.Namespace
    • 요소를 생성하거나 요소를 검색하는데 새로운 네임스페이스가 필요하다면, Namespace 클래스의 정적 메소드인 getNamespace()를 사용해야 한다.

      // 접두어가 있는 네임스페이스를 생성한다.
      Namespace schemaNamespace =
          Namespace.getNamespace("xsd", "http://www.w3.org/XMLSchema/2001");
      
      // 접두어가 없는 네임스페이스를 생성한다.
      Namespace javaxml2Namespace =
          Namespace.getNamespace("http://www.oreilly.com/javaxml2");
      
    • 네임스페이스 적용

      // 네임스페이스가 있는 요소 생성
      Element schema = new Element("schema", schemaNamespace);
      
      // 특정한 네임스페이스에 속한 자식 요소들을 찾는다.
      List chapterElements = contentElement.getChildren("chapter", javaxml2Namespace);
      
      // 요소에 새로운 네임스페이스를 선언한다.
      catalogElement.addNamespaceDeclaration(
          Namespace.getNamespace("tng", "http://www.truenorthguitars.com");
      
    • 접두어와 상관없이 Namespace의 URI가 동일하면 Namespace객체는 동일하다. - 이것은 표준 규약을 따르는 것이다.

    JDOM Factory

    • org.jdom.JDOMFactory 인터페이스는 JDOM에 있는 모든 타입의 객체를 생성하기 위한 여러 메소드를 정의하고 있다.
    • 보통 JDOM은 org.jdom.DefaultJDOMFactory 클래스를 사용해서 JDOM 트리를 구성한다. DefaultJDOMFactory 클래스를 상속하여 자신만의 팩토리 클래스를 작성할 수 있다.

      class CustomJDOMFactory extends org.jdom.DeafultJDOMFactory {
          ....
      }
      
    • 사용자 정의 Factory 사용해서 JDOM 트리 구성하기 : setFactory(factory)

      SAXBuilder builder = new SAXBuilder();
      
      JDOMFactory factory = new CustomJDOMFactory();
      
      // 사용자 정의 팩토리를 사용하도록 설정
      builder.setFactory(factory);
      
    • JDOMFactory를 사용할 때는 필요한 메소드가 정확히 구현되었는지 확실히 확인해야 한다.

    + Recent posts