JCF3.0 TEAM BLOG

Ext JS 3.0

(장의진) — Tue, 11 Nov 2008 11:30:49 +0900

*참조 : http://ajaxian.com/archives/ext-js-30-r ··· per-tool

Ext JS 3.0이 내년 1분기에 릴리즈 될 예정이라고 합니다.
특히 Ext JS Designer도 함께 출시된다고 하니 기대가 됩니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

jsp 한글깨짐 현상

(김민아) — Wed, 24 Sep 2008 14:39:21 +0900

jsp파일에서 한글 데이터가 깨져서 이리저리 charset도 계속 확인해보고 했는데 원인은 form에 있었음.

<s:form enctype="multipart/form-data" action="saveBBS" method="post"
theme="simple" onsubmit="formCheck();" >

위에서 enctype부분이 꼭 들어가야함. 안그럼 한글이 깨져서 들어감,.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

오라클에서 데이타 복구하기

(장의진) — Fri, 01 Aug 2008 11:46:38 +0900

오라클 10g(?)부터 flash back 이라는 재미있는 기능을 제공합니다.
이 기능을 이용하면 이미 업데이트된 데이타를 쉽게 복구할 수 있습니다.

만약 USER_ROLE 테이블에 데이타를 잘못 업데이트하여 데이타를 복구하려고 할 경우에
아래와 같이 퀴리를 실행하여 undo_sql 을 조회한 다음,
undo_sql 을 이용하여 데이타를 복구하면 됩니다.

SELECT undo_sql from flashback_transaction_query
WHERE commit_timestamp >= TO_TIMESTAMP('2008-08-01 11:30:00', 'YYYY-MM-DD HH24:MI:SS')
and table_name = 'USER_ROLE';

자세한 내용은 아래 링크를 참조하세요.
http://www.oracle.com/technology/deploy ··· view.htm
http://dbataj.blogspot.com/2008/05/orac ··· ery.html

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

과연 어떤 웹서비스 엔진을 선택할 것인가? - 웹서비스 엔진 스팩 비교

(서경진) — Mon, 28 Jul 2008 17:50:47 +0900

General Features

Feature	Axis 1.x	Axis2	CXF	Glue	JBossWS	XFire (1.2)	Metro@GlassFish	OracleAS 10g
Basic Profile 1.1 Compliant	X	X	X	X	X	X	X	X
Easily Create Services from POJOs	X	X	X	X	X	X	X	X
Open Source	X	X	X		X	X	X
RPC-Encoding	X			X	X		X [6]	X
Spring Support	X	X	X			X	X
REST Support		X	X				X	X
IDEA Plugins		X			X	X	X	Ant
Eclipse Plugins		X	(STP)		X	X	X	Ant
NetBeans Plugins							X	Ant
JDeveloper								X
Hot Deployment		X	X		X	?	X	X
Soap 1.1	X	X	X	X	X	X	X	X
Soap 1.2	X	X	X	X	X	X	X	X
Streaming XML (StAX based)		X	X			X	X
WSDL 1.1 ->Code (Client)	X	X	X	X	X	X	X	X
WSDL 1.1 ->Code (Server)	X	X	X	X	X	X	X	X
WSDL 2.0 ->Code (Client)		X		?	?	?		?
WSDL2.0 ->Code (Server)		X		?	?	?		?
Client-side Asynchrony	X	X	X				X	With BPEL
Server-side Asynchrony	X	X	X				X	With BPEL
Policy-driven code generation		X	X

Web Services related JSR standards

Feature	Axis 1.x	Axis2	CXF	Glue	JBossWS	XFire (1.2)	Metro@GlassFish	OracleAS 10g
JAX-RPC	X			X?	X		X	X
JAX-WS		[Early Access/Nightly]	X			[Early Access]	X [5]
JSR 181	X	[Early Access/Nightly]	X		X	X	X	X
JSR 181 on Java 1.4					X	X
SAAJ (1.2/1.3)	X	X	X	X	X	X	X	X
JSR 109							X	X
JBI			X				X

Data Bindings

Feature	Axis 1.x	Axis2	CXF	Glue	JBossWS	XFire	Metro@GlassFish	OracleAS 10g
XMLBeans Support	X	X	X			X
Castor Support	X	X [9]				X
JiBX		X				X
JAXB	X	X	X		X	X	X [5]	JAX-RPC

WS-*

Feature	Axis 1.x	Axis2	CXF	Glue	JBossWS	XFire	Metro@GlassFish	OracleAS 10g
WS-Addressing	X	X	X	X	X	X	X	with BPEL
WS-Atomic Transaction	X	X					X
WS-Business Activity		X
WS-Coordination	X	X					X
WS-Eventing		X			X
WS-Metadata Exchange		X [10]					X
WS-Notification	X	X [12]		?		?
WS-ReliableMessaging	X	X	X				X
WS-Policy		X	X				X	X
WS-Secure Conversation		X					X
WS-Security Policy		X					X
WS-Security	X	X	X	X	X	X	X	X
WS-Trust		X					X
WS-Transfer		X
WSDL 1.1 Support	X	X	X	X	X	X	X	X
WSDL 2.0 Support		X

Transports

Feature	Axis 1.x	Axis2	CXF	Glue	JBossWS	XFire	Metro@GlassFish	OracleAS 10g
HTTP	X	X	X	X	X	X	X	X
JMS	X	X	X	X	X	X	X	X
Jabber	Experimental	Experimental				X
SMTP/POP3	X	X					X
TCP	X	X					X
In-VM	?	X	X	?	?	?	X	?

Attachments

Feature	Axis 1.x	Axis2	CXF	Glue	JBossWS	XFire	Metro@GlassFish	OracleAS 10g
Soap w/ Attachments	X	X	X	X	X		X	X
DIME	X			X				X
MTOM		X	X		X	X	X	X

Encoding Table

Feature	Axis 1.x	Axis2	CXF	Glue	JBossWS	XFire	Metro@GlassFish	OracleAS
XML Textual	X	X	X	X	X	X	X	X
MTOM		X	X		X	X	X	X
FastInfoset		X	X				X
JSON		X	X				X

WS-Addressing Versions

This section is incomplete. If a stack has no WS-A support listed next to it, it probably means that this section has not been filled in for it.

Feature	Axis 1.x	Axis2	CXF	Glue	JBossWS	XFire	Metro@GlassFish	OracleAS 10g
2003-03			?
2004-04			?
2004-08	X	X	?			X	X	X
2005-08	X	X	X			X	X	X
2006-05 [8]	X	X	X				X

위의 내용은 다양한 웹서비스 엔진의 스팩을 비교한 것이다. 이러한 특성은 구현하고자 하는 웹서비스의 특성에 따라 선택된 스팩을 가장 잘 지원하는 웹서비스 엔진을 선택하기 위한 기준이다. 웹서비스에 있어서는 이러한 스팩적 특성뿐만 아니라 성능과 같은 비기능적 요구사항을 만족해야 한다. 따라서 적절한 웹서비스 엔진을 선택하기 위해서는 충분한 테스트와 도입과정이 필요하다.

===== Notes =====
#1 Bootstrapped this page from XFire Stack Comparion page on Oct 9, 2006.
#2 Removed forward looking statements like "Coming in ..."
#3 Removed JBI JSR as none of the soap stacks here are packaged out of the box with a JBI container.
#4 Replaced "Via..." with "?"
#5 JAX-RPC 1.1, JAX-WS 2.0 and JAX-WS 2.1 RI are combined together in Metro. Similarly JAXB 2.0 and JAXB 2.1 are combined together in Metro. JAX-WS 2.0 and JAXB 2.0 functionality is available in Java SE 6 as well.
#6 Only available through the JAX-RPC 1.1 APIs.
#7 Derived from ws Addressing review
#8 WSA 1.0 final: shares the same xmlns as the 2005-08 release.
#9 samples\databinding illustrates how to use castor with "wsdl2java -d none" generated code.
#10 Mex Module for Axis2 is available here
#11 Transfer Module for Axis2 is available here
#12 Apache Muse project has support for WS-Notifications

원문보기

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

KSUG에서 "회사 전체가 쓰는 프레임웍을 만드는 팀에 바라는 점"이라는 좋은 글 소개합니다.

(서경진) — Wed, 23 Jul 2008 10:33:36 +0900

KSUG에 좋은 글이 있어서 소개하고자 합니다.

최근 다수의 회사들이 생산성, 재사용성, 유지보수성, 품질보증 등 자사의 애플리케이션을 견고하게 하고 아웃소싱을 통해 개발되는 애플리케이션을 수치화, 정량화된 데이터를 통해 통제하고자 전사 표준 프레임워크를 구축하거나 도입하고 있습니다. 이와 같이 전사 표준 프레임워크를 구축하고 도입하는데 있어서 고려해야 할 사항들에 대하여 잘 정리하고 있습니다. 저희가 새롭게 시작하고자 하는 일에 많은 도움이 되는 내용들이 있어서 나름대로 느끼는바가 많습니다.

그럼 시작...

어느 정도 규모가 있는 소프트웨어 관련 회사라면 생산성, 유지보수성을 높이고 개발자의 학습비용을 줄이기 위해 전사 표준 프레임웍을 도입하고 있습니다. 그리고 잘 아시듯이, 그런 프레임웍들은 대부분 자바의 오픈소스 프레임웍들의 기반으로 해서 추가, 확장 개발되어 있습니다. 그동안 제가 몇 개의 전사표준 프레임웍을 접하면서 최종 어플리케이션 개발자로써 가지게 된 생각을 정리해 봅니다.

아래 내용은 어느 특정 회사의 프레임웍에만 초점을 두고 있는 내용은 아닙니다. 구체적인 코드의 예까지 들고 싶은 내용도 있지만, 여러 프레임웍에 해당하는 내용일지라도 공개적인 웹사이트에 그렇게 자세한 내용을 올릴 수 있는 전사표준 프레임웍은 오픈소스정책을 펴고 있는 애니프레임 밖에 없습니다. 그래서 지나치게 특정 프레임웍의 대한 비판으로만 해석될까봐 코드 예시는 이 글에는 포함시키지 않았습니다.

첫째, 기존 오픈소스가 제공하는 있는 기능을 중복구현하거나 감싸서 개발할 때는 그 의도를 어플리케이션 개발자에게 알려야 합니다. 오픈소스에서 유사한 이런 것이 있는데, 이런 이유 때문에 따로 작성했다던지, 래핑을 시켰다는 것을 명시해 두면 어플리케이션 개발자들이 그 모듈을 활용하는 할 때 도움이 될 것입니다.

more..

예를 들어, apache commons의 유틸리티들을 래핑한 클래스를 작성했다면, '이 클래스는 자주 반복적으로 나타나는 몇 개의 호출패턴을 묶어서 새로운 클래스로 래핑을 했고, 만약 이 클래스에서 수용할 수 없는 기능이 필요할 때는 직접 apache commons의 API를 호출하면 된다'라는 정도의 안내 문구와 내부에서 참조하는 API문서의 링크정도가 제공될 수 있습니다. 그렇게 한다면 개발자는 해당 클래스를 설계자의 의도대로 사용하면서도 추가로 필요한 기능에 대해서도 유연성 있게 대처할 수 있습니다. 그리고 래핑도 아닌 중복된 구현이라면 '널리 쓰이는 xx클래스의 xxx메서드보다 성능비교에서 더 뛰어난 결과가 보여서 이 클래스를 추가했다. 해당 오픈소스 커뮤니티에도 이 사실을 문의를 했고, 만약 다음 버전의 패치에서 우리가 제안한 구현방식이 적용된다면 차후에 이 클래스는 depreciate 될 수도 있다.'라는 식으로 안내를 할 수 있을 것입니다. 개발자들이 이해할 수 있는 명확한 이유를 문서화 해서 '몰라서 그 모듈을 안 쓴 것은 아니다.'것이 전달되어야지 전사 프레임웍을 만드는 팀이 더욱 신뢰를 얻을 수 있습니다. 유명 모듈과 기능이 중복이 되면서도 그 의도를 알 수 없는 코드를 발견하게 되면, 그 코드를 작성한 사람이 작업량을 많아 보이게 해서 성과를 과장해서 인정받을려고 이런 코드를 더 짠 것이 아닐까 하는 의심까지도 생기게 됩니다.

프레임웍에서 추가로 클래스가 하나 늘어날 때의 댓가는 코드 작성 비용 외에도 문서화, 교육, 지원 비용이 있음을 다 들 알고 계실 것입니다. 유명한 공개 모듈을 활용하면 대략적인 안내와 API문서 링크, 참고할 웹페이지와 책목록만 안내 문서에 넣어주면 끝날 일이 중복 구현시에는 새로 API문서 작성, 문의 답변, 디버깅 지원, 추가 확장 등의 짐이 따라 붙게 되어 있습니다. 전사프레임웍은 API는 회사의 자산이자 부채라는 말을 실감할 수 있는 예입니다. ¹ 그리고, 동등한 기능이라면 특정 회사 내에서만 쓰는 모듈보다는 회사 밖에서도 많이 쓰이는 모듈이 개발자들의 학습의욕을 더 불러 일으킬 수 있을 것입니다.

둘째, 사내에서 만든 기존 모듈도 지속적으로 개선하고, 때로는 과감히 버릴 수도 있어야 한다고 생각합니다. 기존 모듈의 가치를 지나치게 높게 평가하지 않고, 인터페이스와 구현을 끊임없이 재검토 되어야 합니다. 팀 내에서 높은 직급의 사람이 만들었던 코드라도 마찬가지어야 할 것입니다.

more..

셋째, 프레임웍의 개발단계에서도 결정사항과 주요 설계의 의도들에 대한 것들은 문서로 남겨지고 공유되어서, 어플리케이션 개발자들의 피드백을 받아야 한다고 생각합니다. 보통 모듈 공개 이후에 개발자들이 웹단의 프레임웍 선택 기준이라던지, 모듈의 설계에 대해서 많이 문의를 합니다. 그 때도 답변 담당자가 검토과정을 알지 못하면 상세한 대답을 하기가 어려울 것입니다. 'XX 프레임웍은 검토했던 담당자가 지금 여기에 없어서 저도 자세히는 모르겠네요. '라거나 '지금은 그 때 그 모듈을 작성했던 개발자가 없어서 확실히는 모르겠으나, 제 추측으로는...'라는 내용이 포함된 답변을 본적도 있습니다. 프레임웍 개발팀 내부의 업무 인계나 개발자들의 반복적인 문의를 잘 처리하기 위해서라도 그런 내용의 정리, 공유는 필요합니다. 그리고 그런 문의들은 결정사항이 확정된 후에 그것을 돌이킬 수 없을 때가 아닌, 검토 과정 중에서 받아서 실무 개발자들의 경험을 충분히 활용하고 더 많은 사람들의 지식을 모을 수 있어야 합니다.

more..

넷째, 배포되는 모듈과 샘플들은 최종 확정 전에 엄격한 설계 검토와 코드리뷰가 이루어 져야 합니다.

more..

다섯째, 프레임웍을 현장에서 적용할 때 선택할 수 있는 사안들이 유연하게 제공되고, 각각의 장단점과 선택의 기준등이 제시되었으면 좋겠습니다. 전사표준 프레임은 개발자들을 가두어 두는 벽이 되어서는 안 되고, 든든하게 딛고 뛸 수 있는 바닥이 되어야 할 것입니다. 그래서 그런 프레임웍에 모듈의 조합이나 설정 파라미터 등에 있어서 다양한 선택이 존재하는 것은 당연한 일입니다. 그러나 각 프로젝트마다 많은 선택의 조합들을 다 검토할 수 있는 여력이 안 되고, 구체적인 선택기준이 없다면 오히려 그런 선택의 폭들은 짐이 됩니다. 프로젝트에서 목소리 큰 사람의 의견대로 흘러가서 동의하지 못하는 구성원들이 생긴다면 갈등의 소지까지도 될 수 있겠습니다.

more..

여섯번째, 오픈 소스 프레임웍을 매개로 조직의 경계를 넘어선 공동작업을 시도해 보아야 한다고 생각합니다. 회사와 업계를 막론하고 Java 오픈소스 기반의 프레임웍들은 많이 쓰이고 있습니다. 그래서 많은 조직들에서 같은 고민들을 조직마다 따로 동시에 하고 있을 것으로 추측됩니다. 이런 상황에서 적용사례, 활용팁, 문제해결 사례, 프레임웍 간 비교검토 결과 등의 자료 공유와 코드 공유, 공동의 교육과정 개설 같은 일이 이루어 질 수 있다면 상호이익이 될 것입니다. .

more..

지금까지 나온 내용을 정리해보면 다음과 같습니다. 오픈소스 모듈을 래핑하거나 중복된 기능을 구현할 때는 의도를 개발자에게 알리고, 기존 모듈에 대해서도 개선을 해나가면서 때로는 과감히 범용적인 모듈로 교체할 수 있어야 합니다. 그리고 개발과정 중에서도 주요 결정사항과 설계안을 공유해서 피드백을 받고, 최종배포 전에는 설계안과 코드를 엄격하게 검증해야 합니다. 그리고 배포 후에는 유연한 선택 사항들과 구체적인 선택 기준을 제공하는 적용가이드를 제공하고, 회사 조직의 경계를 넘어선 협업도 모색해 보는 것이 좋습니다.

이런 것들을 이루는데 기술적으로는 스프링 프레임웍이 든든한 토대가 되어줄 것은 확실합니다. 잘 아시는 것처럼 유연한 구조로 인한 확장성, Spring portfoilo에 서 제공하는 폭넓은 기능의 모듈들, 빠른 발전 속도와 안정된 하위호환성, 그리고 세계적으로 많은 사용자로 인한 튼튼한 사용자 층 등이 그 이유입니다. 그리고 스프링프레임웍의 공식포럼들을 이용해서 외국개발자들과도 정보를 주고 받음과 동시에 우리 KSUG(http://forum.ksug.org )의 포럼을 통해서도 조직의 벽을 넘어서서 성과물 공유를 할 수 있을 것입니다.

원문보기

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

CoC를 이용하여 iBATIS 설정 간소화하기

(장의진) — Mon, 14 Jul 2008 14:01:58 +0900

서브모듈 별로 분리하여 시스템을 개발하려면 설정파일을 잘 분리해야 한다.
iBATIS 인 경우는 sqlmap-config 파일에 모든 mapping 파일을 등록해야 하므로
사실상 설정 파일을 모듈별로 분리하기는 어렵다.
이 부분에 대하여 고민하고 있던 중에 Spring 프레임워크가 구원투수로 나섰다.

Spring 버전 2.5.3을 이용하면 이 문제를 깔끔(?)하게 처리할 수 있다.

새롭게 추가된 SqlMapClientFactoryBean의 mappingLocations 프로퍼티를 통해
sqlmap mapping 파일을 일일히 지정하지 않고 패턴을 이용하여 일괄적으로 지정할 수 있게 되었다.

위와 같이 설정하면 sqlmap-config 파일은 아래와 같이 단순해 진다.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE sqlMapConfig PUBLIC "-//ibatis.apache.org//DTD SQL Map Config 2.0//EN" "http://dev.daewoobrenic.co.kr/dtd/sql-map-config-2.dtd">

<sqlMapConfig>
<settings useStatementNamespaces="true" cacheModelsEnabled="false"/>
</sqlMapConfig>

주의해야 할 것은 iBATIS 2.3.2 이상의 버전을 사용해야 하며
DTD 파일에서 sqlMap 을 필수에서 옵션으로 변경해 주어야 한다.
우선 테스트를 위해서 src 디렉토리에 com.ibatis.sqlmap.engine.builder.xml 팩키지를
만들고 기존의 sql-map-config-2.dtd 복사하여 아래와 같이 변경을 하였다.

<!ELEMENT sqlMapConfig (properties?, settings?, resultObjectFactory?, typeAlias*, typeHandler*, transactionManager?, sqlMap*)+>

아직까지는 DTD를 수정해야 하는 번거러움이 있지만
개발자 분들의 노가다를 줄이는데 조금이라도 도움이 되었으면 좋겠다^^

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Character Set과 Encoding 이해하기

(서경진) — Fri, 11 Jul 2008 13:36:04 +0900

문자셋과 인코딩의 정의

문자셋 (charset, Character Set)

하나의 언어권에서 사용하는 언어를 표현하기 위한 모든 문자(활자)의 모임을 문자셋(charater set)이라고 한다. 다시 말하면 우리가 얘기하는 언어를 책으로 출판할 때 필요한 문자(활자)를 모두 모은 것이라고 생각하면 된다. 추가적으로 부호와 공백 등과 같은 특수 문자도 문자셋에 포함된다.

영어의 경우 알파벳 대소문자와 특수 문자 등으로 간단하게 문자셋을 구성할 수 있지만 한글의 경우 출판에서 가,나,다 등으로 출판함으로 훨씬 다양한 문자셋을 가지고, 또한 한자를 병행해서 사용함으로 문자셋의 범위는 더욱 넓어진다.

추상적인 글자 셋은 여러 개의 인코딩을 가질 수 있다.
MIME 문자셋은 IANA에서 정의하며 인터넷 및 XML 파일에서 사용한다.

인코딩 (encoding)

인코딩은 문자셋을 컴퓨터가 이해할 수 있는 바이트와 매핑하는 규칙이다. 예를 들면 ASCII Code에서 A,B,C 등은 문자셋이고 A는 코드 65, B는 코드 66 등 바이트 순서와 매핑한 것이 인코딩이다. 따라서 문자셋을 어떻게 매핑하느냐에 따라 하나의 문자셋이 다양한 인코딩을 가질 수 있다.

추상적인 문자셋을 구체적인 bit-stream으로 표기하는 방법
여러가지 문자셋을 동시에 표시할 수 있다.
대부분의 인코딩에서는 대소문자를 구분하지 않는다.
대한민국 문자셋(charater set)에서 가장 많이 사용하는 인코딩은 "UTF-8", "KSC5601", "ISO-8859-1" 이다.

문자셋(인코딩)의 예

한글 : 8bit KSC5601 (8bit EUC-KR, 7bit ISO-2022-KR, ISO-2022-Int)
영문 : KSC5636, US-ASCII (둘 간의 차이는 화페 단위 뿐)
한글+영문 : KSC5861 (EUC-KR), KSC5636 + KSC5601를 모두 포함한다.
유니코드 : 4byte Unicode < ISO-10646 UCS (ISO-8859-1, UTF-8, UTF-16)

문자셋과 인코딩은 동일한 명칭을 가질 수 있어 서로 혼용하여 사용되는 경우가 많다.
EUC-KR은 원래 유닉스용 표준이었는데 인터넷으로 확장되어 사용된다.
KSC5601은 인터넷에서 원활한 한글(완성형) 사용을 위하여 정의된 표준이다.
EUC (Extended UNIX Code), UTF (UCS Transformation format)

기본 인코딩

Windows : 시스템 언어와 관련된 코드 페이지를 따름
- 영문 Windows는 CP1252 인코딩을 사용
- 한글 Windows는 MS949 인코딩을 사용

Unix : LANG 환경 변수로 지정된 로케일에 해당하는 인코딩
- Solaris는 LANG 환경 변수가 ko, ko_KR일 경우 EUC-KR 인코딩을 사용
- HP는 LANG 환경 변수가 ko_KR, ko_KR.eucKR일 경우 EUC-KR 인코딩을 사용
- Unix에서 locale -a 명령을 사용하여 LANG 환경 변수에 지정 가능한 문자셋을 확인할 수 있다.

HTML : ISO-8859-1와 ISO-10646
XML : UTF-8
웹 브라우져 : 내부적으로 모두 유니코드로 처리를 한다.
HTTP/1.0 : ISO-8859-1
HTTP (URL,URI) : US-ASCII, %hexadecimal_code, JavaScript escape() 함수 사용
Java : 유니코드 2.0
직렬화된 Java Class : UTF-8
J2EE : ISO-8859-1
Oracle : UTF-8 (AL32UTF8), 한국에서는 KSC5601 (KO16KSC5601)

다양한 환경에서 인코딩 설정

웹 브라우져 설정

"도구 -> 인터넷 옵션 -> 언어" 메뉴를 선택한다.
영어[en]와 한국어[ko]를 추가하고 원하는 언어를 가장 상단에 위치한다.

JVM 설정

일반적으로 LANG 환경 변수를 설정해 주면 자동으로 설정이 된다.

locale -a                               Solaria unix 명령어로 지원 가능한 encoding을 확인한다.
env  LANG  ko                           csh에서 Encoding을 설정한다. (KSC5601, EUC-KR)
LANG=ko                                 ksh에서 Encoding을 설정한다. (KSC5601, EUC-KR)

JVM 옵션 설정 (UTF-8, ISO-8859-1, KSC5601)

-Dfile.encoding=8859_1                  필수 항목
-Dfile.client.encoding=8859_1
-Dclient.encoding.override=8859_1       JVM 버전에 따라 (사용안함)

JSP를 사용하여 JVM 옵션 확인 (encoding.jsp)

file.encoding = <%= System.getProperty("file.encoding") %><br>
file.client.encoding = <%= System.getProperty("file.client.encoding") %><br>
client.encoding.override = <%= System.getProperty("client.encoding.override") %><br>

HTML 설정

HTML 파일을 UTF-8로 만들어 저장한다.

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

XML 설정

XML 파일을 UTF-8로 만들어 저장한다.

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

JSP 설정

JSP 파일을 UTF-8로 만들어 저장한다.

<%@ page pageEncoding="UTF-8" %>
<%@ page contentType="text/html;charset=UTF-8" %>

Servlet 설정

HTTP 요청의 인코딩 지정

request.setCharacterEncoding("UTF-8");

HTTP 응답의 인코딩 지정

response.setContentType("text/html; charset=UTF-8");

web.xml 설정

<mime-mapping>
    <extension>html</extension>
    <mime-type>text/html;charset=UTF-8</mime-type>
</mime-mapping>

Default Oracle Database 문자셋

Default Oracle Database 문자셋 : UTF-8 (AL32UTF8), 한국에서는 KSC5601 (KO16KSC5601)

AL32UTF8, KO16KSC5601 (KSC5601), WE8ISO8859P1 (8859_1)

Default Oracle Database 문자셋 확인 방법

sqlplus system/manager

select parameter || ' : ' || value parameter_value
  from NLS_DATABASE_PARAMETERS
 where parameter = 'NLS_CHARACTERSET'
    or parameter = 'NLS_NCHAR_CHARACTERSET';

select name || ' : ' || substr(value$, 1, 40) parameter_value
  from sys.props$
 where name = 'NLS_CHARACTERSET';

select parameter || ' : ' || value parameter_value
  from NLS_INSTANCE_PARAMETERS, V$NLS_PARAMETERS, NLS_SESSION_PARAMETERS;

Oracle Database 문자셋 변경 방법

환경 변수 또는 %ORACLE_HOME%/dbs/init[SID].ora 을 설정한다.

NLS_LANG='American_America.Ko16ksc5601'
ORA_NLS33='$ORACLE_HOME/ocommon/nls/admin/data'
NLS_DATE_FORMAT='YYYY-MM-DD'

DriverManager에서 문자셋 설정 방법

java.util.Properties props = new java.util.Properties();
props.put("charSet", "KSC5601" );
DriverManager.getConnection(dbUrl, props);

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

[eclipse] Jeus4.2 , eclipse3.3 Remote Debugging 설정방법

(서경진) — Thu, 10 Jul 2008 09:42:19 +0900

설정

Copy C:\Jeus42\bin\jeus.bat -> C:\Jeus42\bin\start_jeus_for_debugging.bat
아래 색칠된 부분 추가(아래 추가된 부분만 보여줌)

call wsboot -> webtob 실행시 추가
java -classic -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8888,suspend=n,server=y -server -Xbootclasspath/p:"%JEUS_HOME%\lib\system\extension.jar";
"%JEUS_HOME%\lib\system\jaas.jar" -classpath "%JEUS_HOME%\lib\system\bootstrap.jar" -Djeus.session.version=SOCKET -Djava.library.path="%PATH%;%JEUS_HOME%\lib\system" -Djeus.home="%JEUS_HOME%" -Djeus.servlethome="%SERVLET_HOME%" -Djeus.ejbhome="%EJB_HOME%" -Djeus.clienthome="%CLIENT_HOME%" -Djeus.config.home="%JEUS_HOME%\config" -Djeus.log.home="%JEUS_HOME%\logs" -Djeus.earhome="%EAR_HOME%" -DJEUS_WSDIR="%JEUS_HOME%\webserver" -Djava.naming.factory.initial=jeus.jndi.JNSContextFactory -Djava.naming.factory.url.pkgs=jeus.jndi.jns.url -Djeus.baseport="%JEUS_BASEPORT%" -Djeus.tm.checkReg=true -Djeus.ejb.classloadingmode=JAR jeus.server.JeusBootstrapper -xml -U제우스관리자ID -P제우스관리자비밀번호 %*
-> address=8888은 eclipse에서 리모트 연결할 포트를 선택해서 설정해준다.
C:\Jeus42\bin\stop_jeus_for_debuggin.bat 작성

call wsdown -i -> webtob 실행시 실행중지
jeusadmin <노드명> jeusexit -U제우스관리자ID -P제우스관리자비밀번호
Jeus42\config\JEUSMain.xml 수정

컨테이너 이름을 default로 설정

<engine-container><name>default</name>...</engine-container>
eclipse에서 Run External Tools > Open External Tools Dialog... > Program > New

Main Tab : Location 에 C:\Jeus42\bin\start_jeus_for_debugging.bat 선택

Working Directory 에 디버깅할 프로젝트 선택(Jeus에서 디버깅할 Web App prj.)

다시 New

Main Tab : Location 에 C:\Jeus42\bin\stop_jeus_for_debugging.bat 선택

Working Directory 에 디버깅할 프로젝트 선택(Jeus에서 디버깅할 Web App prj.)
eclipse에서 Run > Open Debug Dialog... > Remote Java Application

Connect Tab : Name 에 Jeus Debug 입력

Project 에 5.에서 선택한 프로젝트명 선택

Connection Type : Standart(Socket Attach)

Connection Properties : Host 에 Jeus 서버 주소, Port에 2.에서 address에 설정해준 포트(8888) 입력

Debugging

Run External Tools > Open External Tools Dialog... 에서 start_jeus_for_debuggin 선택 후 Run 버튼 클릭 -> Consol창에서 Jeus 정상부팅확인(혹은 설정 5에서 설정 후 Run 버튼 클릭)
Run > Open Debug Dialog... 에서 Remote Java Application > Jeus Debug 선택 후 Debug 버튼 클릭 -> Debug perspective 에서 정상적으로 연결되었는지 확인(혹은 설정 6에서 설정 후 Debug 버튼 클릭,정상 연결되었을 경우 Jeus Thread 리스트를 Debug View에서 볼 수 있다.)
한번 실행 이후엔 Run History, Debug History에서 간단하게 실행가능
Debugging할 파일에 Break Point 설정 후 Debugging

참고

http://openframework.or.kr/JSPWiki/Wiki.jsp?page=JeusRemoteDebugging

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

좋은 사회를 만드는 기술^^

(장의진) — Tue, 01 Jul 2008 15:54:46 +0900

요즘 몇몇 똑똑한(?) 대학생들은 자동으로 수강신청을 해주는 프로그램을
만들어서 땀흘리지 않고 수강신청을 하려고 하고
이로 인해 서버의 부하가 발생하고 땀 흘려 수강신청하려는 선량한 학생들이
피해를 입는다고 합니다.

이 문제를 해결할 수 있는 방법은 여려가지가 있겠지만
Struts2 웹프레임워크를사용하는 경우는
Token Intercept를 사용하면 쉽게 문제를 해결할 수 있습니다.
http://struts.apache.org/2.x/docs/token ··· tor.html

Back, Refresh 혹은 버튼 더블클릭으로 인한 동일한 폼데이타의 중복전송도
방지할 수 있겠네요^^

설정방법은 아래와 같습니다.

1. Struts 설정파일에 Token Interceptor를 등록한다.

<action name="transfer" class="...OOOAction">
<interceptor-ref name="defaultStack"/>
<interceptor-ref name="token"/>
<result name="invalid.token">doublePost.jsp</result>
<result name="success">OOOO.jsp</result>
</action>

2. jsp 페이지에 token tag를 추가한다.

<s:form action="OOO">
<s:token/>
...
<s:submit value="OOOOO"/>
</s:form>

"끝"

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

간단 팁) Java 1.4에서 Spring TestingFramework 분위기 내기

(setq) — Fri, 27 Jun 2008 16:20:04 +0900

스프링의 테스팅 프레임워크를 사용하게 되면 각종 테스트에 필요한 applicationContext 설정 파일을 테스트 클래스와 동일한 패키지/동일한 이름(-context.xml)으로 기본적으로 지정이 되기 때문에 불필요한 코딩이 좀 줄어드는 편입니다만, 자바 1.4를 주로 쓰다보니 그런 편리한 기능을 두고 매번 getConfigLocations를 만들고 있습니다.

뭐, 종종 하는 짓이긴 하지만 또 상속입니다. 다중 상속이 됐으면 한 판에 끝나겠지만 뭐 그냥 DI만 필요한 경우, 트랜젝션 관리도 필요한 경우, jdbcTemplate가 필요한 경우의 클래스들이 따로 따로 있기 때문에 각각 만들어놓고 쓰는 수고를 좀 해야겠지요 -_-

자바 1.4에서도 돌아갈 수 있는 스프링의 테스트용 추상 클래스 중에서 한 놈을 뽑아서 거기서 확장을 하겠습니다.
거기에 getConfigLocations를 정의해놓고, 생성자에 약간의 세팅만 해 주면 그나마 비슷한 분위기를 낼 수는 있습니다.
대강 보시면 아시겠지만 스프링에서 제공하는 ClassUtils 를 이용하였습니다.

public abstract class AbstractTests extends
AbstractDependencyInjectionSpringContextTests {

public AbstractTests () {
setDependencyCheck(false);
}

protected String[] getConfigLocations() {
return new String[] { ClassUtils.addResourcePathToPackagePath(getClass(), ClassUtils.getShortName(getClass())
+ "-context.xml") };
}
}

이제 이 놈을 상속 받은 테스트 클래스들은 동일한 패키지 내에 "테스트클래스이름-context.xml" 파일을 만들어서 스프링 빈 설정을 하시면 되겠습니다. 애플리케이션 공통으로 쓰는 applicationContext.xml 파일 등등은 import 선언으로 가져와버리면 되겠죠.

1.4에서 하나 아쉬운 게 또 있다면 @autowired 를 쓸 수 없기 때문에 set메소드는 일일이 만들어줘야 된다는 점이 있습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.