도전의 미학...

이번 달 마소에는 특집 기사로 Spring 3.0에 대한 내용이 실렸습니다.

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

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

그간 스프링 교육을 해왔지만 그보다 한 발 더 나아가고, 더 많은 고민을 통해 구성한 교육을 만들기 위해 의견 수렴을 합니다. 

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

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

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

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

드디어 3.0이 정식으로 세상에 모습을 드러냈습니다. 그간 풍문으로 많은 변화를 들어왔는데 이제 본격적으로 3.0에 대한 학습을 시작할 시점이 왔습니다.

일터에서도 3.0을 검토하기도 해야 해서 일단 체인지 로그부터 살펴보는 중입니다.
그나러자 스프링 트윗분들께서 분단위로 카운트까지 하면서 열심이시네요^^.

|| Spring 3.0.0 is Now Available ||

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

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

근래 들어 여유 시간은 모두 하이버네이트 책 번역을 하는데 쏟아 붇고 있습니다.
원래부터 번역에는 크게 소질이 없고, 거기다가 시간도 없고, 책도 만만치 않다보니 어려움이 많습니다 @@

특히나 JPWH는 기존에 하이버네이트 번역 책이 없기 때문에 대부분의 용어에 대한 번역을 새로 정의하고 지나가야 하는 일이 정말 쉽지 않습니다..

제가 맡은 부분에 나오는 대부분의 용어는 어느 정도 정리가 됐는데, 그 중 아무리 통빡(?)을 굴러봐도 확 와닿는 뜻이 없는 단어가 'eagerly' 입니다.

뜻은 명확합니다. 연산 요청 시에 요청에 해당하는 모든 결과값을 불러온다는 것이지요. 이에 대응이 되는 용어로는 'lazy'가 있습니다. 이 용어도 번역이 만만치 않습니다.

lazy는 보통 'lazy loading'이라는 용어로 표현이 되는데, 잠정적으로는 '늦은 로딩'으로 번역하기로 했습니다. 이렇게 되니 그 반대가 되는 'eagerly'의 뜻을 정하기가 더 쉽지가 않습니다. 'lazy'가 늦은이면, 'eagerly'는 빠른?? -_-;

네. 좋은 아이디어 있으면 저한테도 알려주세요^^.
내부적으로 역자들간의 공유가 되면 하이버네이트 관련 용어집을 올리는 것도 의미가 있을 것 같습니다. 얼마전 모임에서 느낀건데 그 의미를 한글로 명확하고, 간결하게 설명할 수 있어야 완벽하게 이해했다고 말할 수 있습니다.

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

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

근 1년간 Java Persistence With Hibernate의 번역본을 준비하고 있습니다. 책 분량이 상당하기 때문에, 저 혼자 준비하는 건 아니고, 또한 이런 저런 일들이 겹쳐서 아직 마무리 되지는 못했지만, 아마도 올해 말까지는 마무리 되지 않을까 생각됩니다.

그런데 오늘 번역 마무리를 져야 하는 또 다른 이유가 생겼습니다.

Christian Bauer가 JPwH의 2판(second-edition)에 대한 언급을 블로그에 공개했습니다. 개빙 킹이 불러서 2판을 내자고 했다더군요..
아직 생각을 정리하고 있는 듯한데, 2판이 나오기 전에 얼른 마무리 해야겠죠^^.

Christian Bauer 생각으로는 2판에서는 초기 설정과 같은 초보자를 위한 분량은 빼고 싶다고 합니다. 초보자를 고려해서 책의 초반에 들어가는 분량이 너무 많다는 생각이 들고, 이렇게 초보자에 필요한 초기 설정에 대한 내용은 별첨(appendix)로 첨부하겠다는 생각입니다.

이렇게 구성해도 책 분량은 1판(800페이지 정도..)과 비슷할 것다고 합니다. 2판에서는 JPA2에 대한 내용도 많이 들어갈 것 같고, 내용도 좀더 충실해질 것 같아 기대가 됩니다.(더 충실해진다면, 그만큼 더 어려워 지겠군요 @@)

언제 출간 될지 모르겠지만 기대해 볼만 합니다.

ps. 그 전에 (아마도 조만간?) 번역되어 출간되는 JPwH 1판을 보시는 것도 도움이 되겠죠^^.

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

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

최근 프레임웍 개발 버전을 JDK 1.5 지원 기능을 추가했던 적이 있었습니다. 기존에는 JDK 1.4의 호환성 보장을 목적으로 JDK 1.4 기반으로 모든 기능을 개발했었는데, 이런저런 요구사항으로 JDK 1.5 기반의 기능들을 추가하게 된 것입니다.

이에 따라 발생하는 중요한 이슈는 배포의 문제였습니다. JDK 1.5 기반의 코드는 JDK 1.4로 컴파일이 불가능 하니, 각각의 JDK에 따라서 컴파일을 하고 배포할 수 밖에 없습니다.

이런 JDK 버전에 따른 문제는 아마 서비스를 제공하거나, 공통 라이브러리(또는 프레임웍)을 제공하는 분들이라면 한 번쯤 고민해봤을 만한 문제라고 생각합니다.

이를 처리할 수 있는 방법으로는 먼저 JDK 1.4 지원 버전과 JDK 1.5 버전을 나누어 제공할 수 있습니다. (국내 프레임웍에서는 애니프레임을 예로 들 수 있습니다.) 또는 하나의 배포 버전(JAR)에 각각의 버전에 맞게 컴파일된 클래스를 포함해서 배포하는 방법도 있습니다.

마침 하이버네이트 개발하는 Steve Ebersole란 친구가 역시나 이에 대한 고민을 올려주었습니다.

Simultaneously Supporting JDBC3 and JDBC4 with Maven

JDBC 3과 JDBC 4를 지원하고자 하는데, JDBC 3은 JDK 1.4를 타겟으로, JDBC 4는 JDK 1.6을 타겟으로 하고자 한다군요..
위에서 잠시 언급했듯이 이 친구도 하나의 JAR에 각각의 버전에 맞게 컴파일된 배포 버전을 사용하려고 했습니다.

그런데 불행하게도 Maven에서는 이 구성이 불가능하다고 합니다. (메이븐에는 아직 그렇게 관심이 없기에 자세히 읽어보지는 않았습니다.)
이 친구가 제안한 두 가지 방법은

1. 하나의 소스 디렉토리를 구성해 놓고, 각각의 JDK 버전에 맞게 설정된 두 개의 설정을 사용하고, 중복해서 들어가지 않도록 include/exlucde 설정을 하는 방법
2. 3개의 모듈로 분리. JDk 1.4, JDK 1.5, 공통 모듈로 분리하는 방법

댓글로 또 다른 방법으로 패치를 하거나, 별도의 플러그인을 소개해주기 합니다.
Maven이 훌륭한 툴이기는 하지만, 역시나 배포는 (그 자체가) 어려운 문제입니다.

저 같은 경우에는 (다행이도?) Ant 기반으로 배포를 하기에 각자 JDK 버전에 맞게 컴파일을 한 후 하나의 배포 버전(JAR)로 묶는 방법을 구성했습니다. 소스는 별도의 디렉토리로 구성했습니다.

- src          : JDK 1.4 기반 소스
- test          : JDK 1.4 기반 테스트 소스
- tiger-src  : JDK 1.5 기반 소스
- tiger-test : JDK 1.5 기반 테스트 소스

Spring 방식과 비슷합니다^^. 단순하며,직관적이죠. (역시나 Spring은 여러모로 참고할 부분이 많습니다..)

상당 기간 프레임웍을 개발하고, 배포를 하다보니 겪는 이슈나 어려움이 많습니다.
배포 얘기가 나왔으니 말인데, 이렇게 기반 환경(JDK)의 버전에 따른 배포 버전이 달라지는 것 말고도, 기능적인 요구사항이나 내부 구조 변경에 따라 라이브러리 자체의 배포 버전이 달라져야 하는 경우에는 문제가 더욱 심각해집니다.

아마도 프레임웍 수준의 배포 버전이라면 단순히 코어 소스에 대한 버전 관리 뿐만 아니라, 그와 관련된 테스트, 지원 컴포넌트, 예제 등에 대한 버전 관리도 필요해지므로, 유지보수 비용이 거의 곱하기 2(X2) 정도가 되기도 합니다. 물론 이렇게 이슈가 되어 그 기회에 전체 프로세스를 정리해볼 기회도 되더군요.. 이 얘기는 다음에 한 번더 정리해볼 만한 문제입니다.

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

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

개발자는 설계된 인터페이스를 기준으로 서비스를 개발한다.
개발된 서비스는 OSGi의 컴포넌트로 패키징 된다.
배포(결제) 요청을 한다.
승인이 된다.
승인된 컴포넌트는 클라우딩 환경에 배포된다.
클라우딩 환경은 전사가 공유하는 서비스 환경이다.

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

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

놀세 님의 블로그에서 흥미로운 글을 하나 읽었습니다.

Seam(JSR-299)과 Spring(JSR-330)의 만남

gavin king이 jsr-299을 진행하고 있고(얼마전에는 이름도 변경했던 것죠..), spring과 google guice가 손을 잡았다는 기사도 봤었는데, 그 기사만 보고 지나갔지 이런 흥미로운 일들이 일을 생각해보지는 못했습니다^^;

당연한 일인데 말이죠..

놀세님의 블로그에 나오듯이 jsr-330은 아직 걸음마 수준인데 반해, jsr-299는 상당히 진전이 된 상태이고, 이번 java one에서도 jee 6 관련 세션으로 진행까지고 하고 있습니다.

진행 상황만 보면 사실 jsr-299가 한창 차리고 있는 상을 뒤늦게 한 친구(jsr-330)가 나타나 상 앞에 앉아서 맛있는 반찬 그릇을 자기 앞으로 가지고 가려는 듯 보입니다. 내부에 어떤 히스토리가 더 있겠는지는 모르겠지만요..

방금 전에 올라온 인포 큐에는 이에 대한 다양한 사람과 투표자(voter)들의 코멘트가 올라왔는데, 역시 gavin은

I think it would be a huge mistake to introduce a second set of annotations which are semantically identical to those in 299 and address the exactly the same problem - gavin

그리고 Antonio Goncalves란 분은 약간 우회적으로 현 상황을 표현해주기도 하셨습니다.

I hope we are not starting a new battle like the one between Java Module (JSR 277), Modularity Support (JSR 294) - Antonio

음..일단 전반적인 분위기는 이렇습니다.

여기까지는 분위기고, 중요한건 두 친구들의 표준 수립이 어떤 모양으로 되어 있고, 지향하는 바가 무엇인지를 한 번 살펴봐야 여기서 하는 얘기들에 공감을 할 수 있을 것 같습니다.

다음번에는 양쪽 내용을 한 번 살펴보도록 하겠습니다.

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

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

세션 유지 때문에 애플리케이션을 하나로 띄워야 하나?

그런가요..
그럴까요..

음..

가만히 생각해보면 여기서 말하는 세션은 HttpSession이 아니라 사용자 세션 정보를 말하는 겁니다..
싱글 사인 온..
클러스터링?

모듈화는 먼 나라 얘기..

오늘 하루 종일 가장 많이 들은 말은

"일단 띄워!"
"일단 띄워!"
"일단 띄워!"

일단 띄우려면, 지금 있는 대로 쓰지 머 하러 비싼 돈 들이면서 프로젝트 할까요('')?
알수 없는 일 >.<

툴툴 포스팅은 두 개로 끝내고 공부하러 가야겠어요==33

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

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