[podtech content=http://media1.podtech.net/media/2007/07/PID_011810/Podtech_eclipse_europa_mylyn_demo.flv&postURL=http://www.podtech.net/home/3514/europa-mylyn-demo-task-management-and-context-filtering-for-teams&totalTime=1092000&breadcrumb=11fbc5f50fac473f98ad162fb642cca8]

cvs에서의 module이 일반 모듈과 alias, amphersand module 등의 단순한 기능을 지원하는 반면, cvsnt의 module2는 아예 다른 모듈로부터 특정 디렉토리를 떼어와서 기존 디렉토리를 치환할 수도 있다.

물론 이에 대한 안정성 문제가 남아있기는 한데, 일단 시도는 해 보고 생각해볼 일이다.

가능하면 안정적인 cvs module을 이용하려고 했지만 개발소스를 모듈화 하기 위해서는 삽입 뿐 아니라 치환도 필요했다. :)

우선 기본 소스 트리 부터 정리가 필요하다.   모듈 서로간에는 의존 관계가 없도록 짜여져있어야 하고, 공통 분모를 뽑아내서 예쁘게 정돈해놓는다.

그 다음 모듈을 둘 디렉토리를 정하여 일정한 틀에 맞춰 차곡차곡 쌓아놓는다.

그러면 기본 소스 트리 정리는 끝난다.

다음으로는 CVSNT module2 파일을 생성한다. (도움말 파일을 참조)

베이스 모듈을 하나 정의해서 공통 분모만 남는 것으로 정의하고

다른 모듈들은 베이스 모듈에 자기 소스를 덧 대는 방식으로 정의한다.

그럼 module2 정의도 끝난다.

그럼 각각의 정의된 모듈별로 소스를 checkout 받아본다. 제대로 받아지면 일단 성공.

Spring OSGi 를 적용시켜보든지 아니면 일전에 작업해놓은 beanFactory를 이용하여 정적 모듈 처리할 것인지 고민해봐야겠다.

단순한 일에서 예외사항이 만들어지고 점점 더 복잡해져간다.

점점 더 사용자 입장에서 대상이 모호해지고 복잡, 거대해지는 것을 느끼게 되면서 신뢰할 수 없게 된다.

이는 일반적 시스템 뿐 아니라 단위 시스템에도 적용되는 이야기다.

시스템을 그려봐야겠다.

각각의 컨텍스트를 A  context, B context라고 하면

A  context의 구조는

Spring + iBatis sqlMap 을 이용한 Struts 애플리케이션이고

B context의 구조는

iBatis dao + sqlMap을 이용한 Struts 구조와 더불어 (1)

ResultSet을 jsp로 반환하는, jdbc api를 이용한 제3세계의 dao를 이용하는 구조(2) 가 병행되고 있는 애플리케이션이다.

B context에서 Tomcat datasource를 이용할 경우(2)가 Clob 처리를 전혀 (길이와 상관 없이) 못하기 때문에 해결 방법을 찾다 찾다 못 찾아서 컨테이너에서 제공하는 서비스를 쓰지 않고 별도의 Database connection을 만들어서 임시 변통으로 처리를 해서 해결된 것 처럼 보였다.

그러나 A context가  동시에 올라가면 (2)가 마찬가지로 문제를 발생시키니 원인을 찾지 못해서 전전긍긍하다가 DB Connection pool을 별도로 만들어 A, B context에서 이용하는 datasource를 분리시켜주니 해결이 됐다.

농담으로 A contexte의 애플리케이션이 ‘기가 센 것 같다’ 라고는 했는데, 그 말이 왠지 맞는 것 같기도 하다. 아무래도  Spring의 lob handler helper class에서 connection 관련된 문제를 발생시키는 것 같다.

암튼 재밌는 세상이다.

2. 그러나 Spring 1.2.8에서 2.0으로 이전하면서 기존의 naming 라이브러리와 충돌이 있었다. 테스트 돌려봐야한다.

3. 옮기는 김에 기존 라이브러리 관리 체계를 Spring 배포본 형태로 이관하였다. 라이브러리 의존관계나 충돌 문제를 다루는 일이 상당히 시일을 많이 소요하기 때문에 이번에 정리했다.

(주 : 선프리웨어의 패키지는 제대로 설치되지 않는다. 아파치 컴파일시 APR-UTIL 버전 요구사항 체크에서 에러를 낸다. 1.2 이상인데도 불구하고)

CLOB 컬럼에 대하여 2000자, 20000자, 200000자에 대하여 각각 테스트를 해보니 각각
- 소켓에서 읽을 데이터가 없습니다
- 소켓에서 읽을 데이터가 없습니다
- IO 예외 상황: Software caused connection abort: socket write error
이런 예외들을 발생시킨다.
(테스트 중에 실수로 트랜젝션을 선언하지 않았었는데, 결과는 희한하게 마찬가지다.)

반면, DriverManagerDataSource를  설정하여 직접 연결한 단위테스트는 트랜젝션을 선언하지 않아도 위의 케이스들에 대하여 성공적으로 데이터를 입/출력하였다.

그래서 다시 설정 파일들을 뒤지다보니

1. Oracle 10g에서는 9i 이전처럼 OracleLobHandler를 쓸 필요 없이 DefaultLobHandler를 쓰면 된다.

2. Tomcat 5.5의 commons-dbcp는 애플리케이션의 jar와 충돌을 피하기 위해서 패키지가 변경되어 있다.
이때문에 기존 Spring의 CommonsDbcpNativeJdbcExtractor 동작하지 않았는데,
Spring 2.0 API doc을 보니 이번 버전에서는 일반 배포본 dbcp나 톰캣버전의 dbcp에서 모두 동작한다고 적혀있다.

Spring 2.0 발표일은 앞으로 3일 남았다.  이것만 바꾸면 되려나.

org.xml.sax.SAXParseException: Invalid byte 3 of 3-byte UTF-8 sequence.

처음에는 이것이 BOM 문제인 줄 알았는데 가만히 메시지를 살펴보니 한글이 들어있는 부분이다.Eclipse의 XML 편집기에서는 XML파일을 로딩할 때 XML 헤더에서 선언한 인코딩으로 문서 전체의 문자 인코딩을 결정하고 있다.
만약 XML 헤더에 문자 인코딩을 EUC-KR로 하게 되면 문서 전체의 문자 인코딩이 EUC-KR로 바뀐다.
이런 경우에는 별 문제가 없이 넘어가는 듯 하다.
XERCES가 시스템 환경에 따라 동작이 바뀌는 듯 하다.
JSP나 JAVA의 경우에는 아직 문제를 발견하지 못했다.

계속 미뤄오다가 하루 바짝 밀어붙이니 마음이 편해진다.

문서나 만들어야지.