Whiteship's Note


한국 스프링 사용자 모임 포럼 개시 http://forum.ksug.org/



사용자 삽입 이미지
두둥!! 어서 질문을 올려주세요. 포럼에서 다루는 프레임워크들은 다음과 같습니다.

Struts, Struts2, WebWork, iBatis, Hibernate, JPA, Velocity, Freemarker, JasperReport, JSF, JRuby, Groovy, AspectJ, EasyMock, EclipseLink, Jakarta Commons, Maven, Quartz, Tiles, Spring Web Flow, Spring Security, Spring DM/OSGI, Spring Batch, Spring Integration, Spring LDAP, Spring IDE, Spring Modules, Spring JavaConfig, Spring Rich Client, Spring.NET, DI/IOC, Bean Container, Data Access, Transaction, Web, SpringMVC, Remoting, JMS, AOP, JMX, EJB, Configuration, Testing, Mocks, JCA

이제 스프링을 공부하시거나 사용하시다가 막히시면 저 곳에 글을 올려주시면 됩니다.
신고
top


20080627 GMP

모하니?/GMPing : 2008.06.27 09:42


News

charter | 챠러 | 전세내다. 전세낸 ex) charter fishing boats
soar | 소어 | 치솟다 ex) soaring fuer prices

Screen English

I knew you could do it.
  엑센트!!

Today Expression

Let me know if you can.
Let me know if you need me.
Let me know if you here anything.
Let me know if you come.
Let me know if you want be alone.
Let me know if you change your mind. => It's not likely to happen.

Sound Sound Play

video 비디오
audio 아디오
radio 레디오
edible 에더블 ex) Is this edible?
radical 레디컬

불난 집에 부채질 하다. add fuel to the fire.
야! 속보이거덩! I know who you are.
신고

'모하니? > GMPing' 카테고리의 다른 글

20080715 GMP  (0) 2008.07.15
20080710 GMP  (0) 2008.07.10
20080708 GMP  (0) 2008.07.08
20080707 GMP  (0) 2008.07.07
20080705 GMP  (0) 2008.07.05
20080704 GMP  (0) 2008.07.04
20080703 GMP  (0) 2008.07.03
20080702 GMP  (0) 2008.07.02
20080701 GMP  (0) 2008.07.01
20080627 GMP  (0) 2008.06.27
20080626 GMP  (0) 2008.06.26
top


서버에 위치한 파일 다운로드 링크 달기

모하니?/Coding : 2008.06.26 18:05


    var excelformdown = function(){
        location.href = "${actionURL}";
    }

일단 화면에서 어떤 이미지 버튼을 클릭하면 자바스크립트로 특정 URL을 호출하게 하도록 하고...

저 URL을 처리할 핸들러에서 파일을 응답으로 돌려주면 된다.

    @RequestMapping
    public void excelformdown(HttpServletResponse response){
        giveExcelForm("sales.xls", response);
    }

저 메소드 안 에서는 응답 유형을 multipart로 설정하고, 파일 이름을 설정해준다. 그리고 파일을 찾아서 output 스트림에 write() 해준다.
신고
top


home 용량이 꽉 찼다

Linux : 2008.06.26 17:58


파일질라로 파일 업로드를 하는데 다음과 같은 에러가 났다.

451 Failure writing to local file.

뭐지.. 쓰기 권한이 없는건가.. 그럼 내가 이전엔 어떻게 업로드를 했던거지.. 뭘까 뭘까.. 이번에도 고민하다가 사부에게 문의했더니 df -h 로 디스크 용량을 확인해보라는 답변. 이쯤되면 거의 걸어다니는 구글이라고 할 수 있겠다.

확인해보니, /home 파티션이 꽉찼다. 조그만 파일 몇 개 올릴 만한 공간도 없다. 누가 많이 쓴건지 이 폴더 저 폴더 뒤지다가 영화 파일이 올라와있는 폴더를 발견. 영화를 다운 받진 않았다. 이미 본거라서..ㅋ 어쨋든 이걸 어쪈댜. 지워버리면 FTP 사용자가 황당해 할 거 같고, 그렇다고 가만히 두면 또 꽉 차서 이런 일이 벌어질꺼고..

그래서 결정. home 디렉터리 바꾸기.

/app 밑은 15G나 되는 상대적으로 많은 공간이 있길래 /etc/passwd 파일을 열어서 해당 사용자의 홈디렉터리를 /app/사용자명 으로 변경.

권한도 변경해줘야겠지?

chown -R 사용자명 /app/사용자명

그룹도 바꿔줄까..

chgrp -R 사용자명 /app/사용자명

제대로 됐는진 몰겠다. 그 사용자의 비번을 모르니..ㅋㅋ 몰라~
신고
top

TAG ftp
Linux : 2008.06.26 17:58 Trackback. : Comment.

톰캣 인코딩 설정해야 하는 경우

모하니?/Coding : 2008.06.26 17:51


updated 090623

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" useBodyEncodingForURI="true"/>

--------------------------------------------------------------------------
검색창에 한글만 입력하면 다음과 같은 에러가 발생한다.

org.postgresql.util.PSQLException: ERROR: character 0xc3a7 of encoding "UTF8" has no equivalent in "EUC_KR"

웹 페이지도 EUC-KR로 설정되어 있고 Postgres DB도 EUC-KR을 사용하고 있다. web.xml에 인코딩 필터를 확인해봤더니, 그것도 역시 EUC-KR로 설정되어 있다.

알턱이 없으니 사부에게 문의해서 알아냈다.

톰캣 5.5 이상 부터는 Post 방식에는 인코딩 필터를 적용할 수 있지만 GET 방식은 서버가 connector에 설정한  (server.xml) URIEncoding의 값으로 인코딩 함.

<Connector port="8209" protocol="AJP/1.3" redirectPort="8543" URIEncoding="euc-kr" />

위는 아파치랑 연동되어 있어서 아파치와 연동하는 부분에 인코딩 설정. 아마도 저 값의 기본값이 UTF-8이었거나 아파치쪽의 기본값이 UTF-8 이었나보다. 몰겠다. 자세히는;
신고
top


20080626 GMP

모하니?/GMPing : 2008.06.26 10:02


스크린 잉글리쉬

I blew the whole case.(=I ruin the everything.) didn't I?
It doesn't matter. The important thing is your are alive. You could have died.

오늘의 Expression
When is it?

When is it on? // 언제 방송해?
When is it due? // 출산예정일 언제야?
When is the final? // 기말고사 언제야?
When is the dead line? // 마감이 언제야?
When is your pay day? // 월급 날 언제야?
When is the boarding time? // 탑승 시간 언제야?

Sound Sound Play

D가 양쪽에 오는 경우에 'ㄹ'로 발음

Are you kidding me? // 키링
readding, // 리링
wedding, // 웨링
tradding, // 트레이링
speedding, // 스피링
proceedding, // 프로시링

Learn more

막다른 곳
= dead end

입이 무겁다.
= I can keep the secret.
= You're secret safe with me.

GMP RSS : http://cast.danpod.com/gmp/index.php/rss
신고

'모하니? > GMPing' 카테고리의 다른 글

20080715 GMP  (0) 2008.07.15
20080710 GMP  (0) 2008.07.10
20080708 GMP  (0) 2008.07.08
20080707 GMP  (0) 2008.07.07
20080705 GMP  (0) 2008.07.05
20080704 GMP  (0) 2008.07.04
20080703 GMP  (0) 2008.07.03
20080702 GMP  (0) 2008.07.02
20080701 GMP  (0) 2008.07.01
20080627 GMP  (0) 2008.06.27
20080626 GMP  (0) 2008.06.26
top

TAG 20080626, GMP

Spring DM 1.1.0 RC1 배포됐네요.

Spring DM/etc : 2008.06.25 23:29


http://www.springframework.org/osgi
with-dependencies가 겨우 13MB 밖에 안 합니다.


신고
top


BundleContext로 할 수 있는 일

Spring DM/OSGi : 2008.06.25 23:12


BundleActivator 다음으로 가장 중요한 OSGi API를 꼽으라면, BundleContext일 겁니다. 어쩌면 BundleActivator보다 중요할지도 모르죠. OSGi 플랫폼에 설치한 번들과 관련된 문맥 정보를 담고 있는 객체니까요. 어떤 용도로 쓸 수 있는지 알아두면 좋겠죠?

시스템 전역에서 사용할 설정 프로퍼티즈 룩업

ID로 설치된 다른 번들 찾기

설치된 모든 번들 목록 가져오기

번들을 프로그래밍을 통해서 라이프사이클 다루기

새로운 번들을 프로그래밍을 통해서 설치하기

프레임워크가 관리하는 영속 저장소에서 파일 가져오거나 저장하기

프레임워크 내부에 있는 어떤 번들의 상태 변화를 알려주기 위한 번들 리스너 등록 또는 해지하기

프레임워크 내부에 있는 어떤 서비스의 상태 변화를 알려주기 위한 서비스 리스너 등록 또는 해지하기

일반적인 프레임워크 이벤트를 알려주기 위한 프레임워크 리스너 등록 또는 해지하기

참조 : http://neilbartlett.name/blog/osgibook/
신고

'Spring DM > OSGi' 카테고리의 다른 글

OSGi 툴 세트 Pax  (0) 2008.10.21
Shared Mutable State  (2) 2008.09.25
The Price of Freedom  (0) 2008.09.25
Concurrency and OSGi  (0) 2008.09.25
BundleContext로 할 수 있는 일  (0) 2008.06.25
2 Security Layer  (0) 2008.02.18
1. Introduction  (0) 2008.02.17
top


번들 라이프사이클

Spring DM/exercise : 2008.06.25 22:56


전에 한 번 그림도 그려보고 아드리안의 발표자료에서도 봤지만, 이번엔 Neil이 그린 라이프사이클입니다.

사용자 삽입 이미지

install 커맨드를 사용해서 번들을 설치하면 맨 먼저 INSTALLED 상태가 되고,
start 커맨드를 사용하면 번들이 필요로 하는 패키지나 서비스를 참조할 수 있는지 확인한 다음 RESOLVED 상태가 되고, 자동으로 자신이 공개할 서비스를 서비스 레지스트리에 등록하고 ACTIVE  상태가 됩니다.

이 상태에서 update 명령을 실행하면 일단 RESOLVED 상태로 넘어가야 하기 떄문에 STOPPING 과정을 거치는데 이 과정에서 자신이 등록했던 서비스를 서비스 레지스트리에서 제거하고 RESOLVED 상태에서 INSTALLED 상태로 변하고 여기서 실제 번들 파일을 update 합니다. 이 때 이미 번들이 위치한 정보를 알고 있기 때문에 위치를 다시 알려줄 필요는 없겠죠. 그런 다음 원래 상태가 ACTIVE 상태였기 떄문에 다시  start를 합니다. 그럼 처음과 같이 RESOLVED -> STARTING 을 걸쳐 ACTIVE 상태가 됩니다.

이 상태에서 이번에는 stop 커맨드를 사용하면 번들은 RESOLVED 상태가 됩니다. 왜? 이미 해당 번들이 필요한 서비스나 패키지들이 가용하다는 것을 검증한 상태기 때문이죠.

해당 번들을 아예 안 쓸꺼면 그 땐 uninstall 해버리면 됩니다. 현재 상태가 어떤 상태이든 관계없이 저 고리를 따라서 이동한 뒤 설치된 번들 목록에서 사라질 겁니다. 다음에 그 번들을 다시 설치하고 싶으면 위치를 또 알려줘야 합니다. 그게 update와 uninstall/install의 가장 큰 외관상 차이며, 개념적인 차이기도 합니다.

Anyway 무사히 모든 번들들이 RESOLVED 되기를 빕니다.

참조 : http://neilbartlett.name/blog/osgibook/

신고
top


Whiteship's 스프링 DM 레퍼런스 1.0 m1 배포

Spring DM/etc : 2008.06.24 11:18



Can u feel the fire~ I get higher~. Nobody nobody nobody no~ can't nobody hold me down~.
Whiteship's 스프링 DM 배포 로드맵

현재 버젼 m1
1. 편집 상태가 상당히 허접합니다.
2. 초장부터 끝장까지 일관적이지가 않습니다. 초반에는 거의 편역과 요약 형태인데, 뒤로 갈 수록 번역 스타일로 변해갑니다.
3. 시간이 넉넉치 않아서, 일단 처리하고 볼려는 심산입니다.

m2 는 다음주 쯔음에...
1. 편집 상태를 좀 더 다듬어서. 링크도 살리고, 기타 등등.
2. 제목을 번역

m3 은 다다음주 쯔음에...
1. 전반적인 문채를 다듬어서 필요한 부분을 추가하고 필요 없는 부분은 삭제. 즉 내용을 수정합니다.
2. 그림과 표를 추가합니다.

v1 정식버젼 배포는 다다다음주 쯔음에..
1. docbook을 이용해서 HTML과 PDF 파일로 배포하기 시도.
2. 잘 되면, maven을 이용해서 빌드

v2 스프링 DM 레퍼런스 구현 기약 없음.
1. 레퍼런스 내용을 다루는 모든 예제 코드 만들기
2. 스프링 DM, OSGi를 익히는데 필요한 로우 레벨의 지식 탐구 정리(Classloading과 Cuncrrency)

v3 더더욱 기약 없음.
1. 스크린 캐스팅 추가

다운로드는 이 곳에서..
신고
top


bnd를 소개합니다.

Spring DM/exercise : 2008.06.23 23:25


bnd는 겉보기에는 간단한 jar 파일 하나지만, 사실 이클립스 플러그인인데다가, Ant 태스크 정의를 가지고 있고, Maven 플러그인이며, 실제 독립적으로 어떤 기능을 수행하는 Java 애플리케이션이기도 하다. 그야말로 본좌라고 할 수 있다.

http://www.aqute.biz/Code/Download

위 링크에 가면 bnd-버전.jar 파일을 바로 다운받을 수 있습니다. 간단하군요. 다른 프로젝트들처럼 zip 파일로 샘플이며 문서며 소스 코드도 묶어두지 않고 바로 jar 파일입니다.

흠...사용법(콜솔 명령어, Eclipse 플러긴, Ant 스크립트, Maven 플러긴)은

http://www.aqute.biz/Code/Bnd

위의 링크 하단에 있습니다.

신고
top

TAG Bnd, OSGi

Eclipse에서 Felix 사용하기

Spring DM/exercise : 2008.06.22 11:39


참조: http://neilbartlett.name/blog/osgibook/

OSGi 스펙 4.0 구현체 중 하나로, 아파치 재단의 프로젝트입니다. Equinox가 OSGi 구현체로 많이 사용되고 있지만, Felix는 Equinox에 비해 상당히 Compact하게 구현한거라 jar 파일 용량이 반 밖에 안 되며, 스펙도 매우 철저하게 따르고 있기 때문에 Felix에서 구동한 번들이 Equinox나 Knopflepfish에서도 무난히 동작한다고 합니다.

1. 먼저 Felix를 다운로드 받습니다.

http://felix.apache.org/site/downloads.cgi

2. 다음 압축을 풀고 원하는 위치로 이동시킵니다.

저는 C:\java\felix-1.0.4 로 이동시켰습니다.

3. 이클립스에 라이브러리를 등록합니다.

사용자 삽입 이미지
위의 화면을 보시면 아시겠죠? Preferences에 Java -> Build Path -> User Libraries에 New를 클릭한 뒤 Felix라고 입력합니다.

사용자 삽입 이미지
다음은 실제 라이브러리를 추가하는 과정으로 Add Jar 버튼을 누른다음 2번 과정에서 옮겨둔 폴더로 이동한 다음 bin/felix.jar 파일을 선택해줍니다. 그럼 위의 화면과 같이 jar 파일이 추가된 걸 확인할 수 있습니다.

4. Felix 프로젝트 만들기

일반 Java 프로젝트 하나를 생성합니다.
사용자 삽입 이미지
이름에는 전 OSGi Felix라고 줬습니다. 다음 Next를 클릭합니다. 라이브러리를 추가하기 위해섭니다.

사용자 삽입 이미지
Add Library를 클릭하고 User Library를 클릭하면 3번에서 추가한 Felix 라이브러리를 선택할 수 있습니다.

5. 프로젝트 세팅하기

Felix를 구동하는데 필요한 번들과 설정파일을 복사해서 위에서 만든 프로젝트로 붙여넣어 줍니다. 해당 번들과 설정파일은 2번에서 작업한 폴더에 보시면 bundle과 conf라는 폴더 안에 들어있고 그 두 개의 폴더를 복사해서 붙여주면 됩니다.

사용자 삽입 이미지

사용자 삽입 이미지

다음은 설정파일을 변경해서 로그 메시지를 좀 더 많이 뿌리도록 설정합니다. 위에 보이는 config.properties파일을 열고 felix.log.level=4 를 felix.log.level=1로 변경해줍니다.

이제 프로젝트 세팅은 끝났습니다. 실행해 봐야겠죠.

6. 실행 환경 설정하기

사용자 삽입 이미지
Run Dialog로 들어가서 Java Application에 하나의 인스턴스를 만들고 Name에는 Felix를 주고, Project에는 위에서 세팅을 마친 프로젝트 OSGi Felix를 선택해줍니다. 다음 Main은 Search 버튼을 눌러보면 두 개의 클래스가 찾아지는데 그 중에서 아래에 있는 Main을 선택합니다.

사용자 삽입 이미지
자 그럼 이 상태가 되었고 이제 실행할 준비도 끝났습니다.

7. 실행하기

Run을 클릭합니다.

사용자 삽입 이미지

프로파일 이름을 달라고 하네요. 아무 이름이나 줍니다. 전 tutorial이라고 줬습니다.

사용자 삽입 이미지
그럼 뭔가가 설치되는게 보입니다. 뭔 뜻인지는 모르겠습니다. 패스.

현재 설치된 번들들의 상태를 참조하려면 ps를 입력합니다.
사용자 삽입 이미지
음.. 총 네개의 번들이 동작중이군요.

사용할 수 있는 명령어를 참조하려면 help를 입력합니다.

사용자 삽입 이미지

끝~
신고
top

TAG Eclipse, Felix

머리를 볶았습니다.



난생첨 파마라는 걸 해봤네요. 전에 올렸던 사이트 오프라인 매장에 가서 머리를 했습니다. 지우 쌤이라는 분이 해주셨는데, 자신의 직업을 좋아하시는 분 같아서 참 보기 좋았습니다.

볶은 머리의 제 모습이 아직 제 눈에도 익숙치가 않아서 뭔가 거시기 합니다.

사용자 삽입 이미지

이거 올리고 있는데 전화가 왔네요;

사용자 삽입 이미지
어서 마무리하고 자야지..

ps: 내일 아침에 놀랄 우리 어머니... 넘 놀라지 마시길..
신고
top


스프링 DM 레퍼런스 편역(not 번역) 완료

Spring DM/etc : 2008.06.22 00:32


파트 3 Other Resouces와 파트 4 Appendixes를 제외한 파트 1, 2, 3(1장부터 9장까지 편역을 드디어 완료했습니다. 얼마 되지도 않는데 정말 오래도 걸리네요. 어찌됐든 일독, 정독, 요약, 편역 했다는데 의미를 두고 링크를 정리해봅니다. 원하시는 분이 계시다면, PDF나 웹 페이지로 정리해서 배포할 생각도 있는데, 원하시나요?

1 장. Why Spring Dynamic Modules?
2 장. Requirements
3 장. What is new?
4 장. Bundles and Application Contexts
    4.1. The Spring Dynamic Modules Extender bundle
    4.2. Application Context Creation
    4.3. Bundle Lifecycle (2)
    4.4. The Resource abstraction
    4.5. Accessing the BundleContext
    4.6. Application Context Destruction
    4.7. Stopping the extender bundle
5 장. Packaging and Deploying Spring-based OSGi applications
    5.1. Bundle format and Manifest headers
    5.2. Extender configuration options
    5.3. Required Spring Framework and Spring Dynamic Modules Bundles
    5.4. Spring XML authoring support
    5.5. Importing and Exporting packages
    5.6. Considerations when using external libraries
    5.7. Diagnosing problems
6 장. The Service Registry
    6.1. Exporting a Spring bean as an OSGi service
    6.2. Defining references to OSGi services
    6.3. Exporter/Importer listener 베스트 프랙티스
    6.4. Service importer global defaults
    6.5. 서비스 Exporter와 서비스 Importer의 관계
7 장. 번들 다루기
8 장. Web Support
    8.1. 지원하는 웹 컨테이너
    8.2. Web support 사용법
    8.3. WAR classpath in OSGi
    8.4. web extender 설정하기
    8.5. Customizing the standard deployers
    8.6. OSGi-ready libraries and web development
    8.7. Spring-MVC Integration
9 장. Testing OSGi based Applications
    9.1. OSGi Mocks
    9.2. Integration Testing
신고
top


9.2. Integration Testing

Spring DM/Chapter 9 : 2008.06.22 00:15


OSGi처럼 제한적인 환경에서는 여러분들이 작성한 클래스의 가시성과 버전관리, 번들이 다른 번들과 제대로 동작하는지를 확인하는 것이 중요하다.

통합 테스트를 편하게 하기위해, 스프링 DM 프로젝트는 테스트 클래스 계층구조를 제공한다(org.springframework.osgi.test.AbstractOsgiTests를 기반으로) . 이걸 사용해서 자동으로 OSGi 환경에서 실행되는 일반적인 JUnit 테스트 케이스를 작성할 수 있다.

보통 스프링 DM 프로젝트가 지원하는 시나리오는 다음과 같다:
  • OSGi 프레임워크 시작하기(Equinox, Knopflerfish, Felix)
  • 테스트에 필요하다고 기술된 번들 설치 및 시작
  • 테스트 케이스를 fly 번들 안으로 패키징하고, manifest 작성하고 OSGi 프레임워크에 해당 번들을 설치하기
  • OSGi 프레임워크 안에서 테스트 케이스 실행하기
  • 프레임워크 종료하기
  • 테스트 결과를 OSGi 밖에 있는 원래 테스트 케이스 객체에 전달하기

주의할 것
테스팅 프레임워크의 목적은 OSGi 통합 테스트를 OSGi 환경 밖에서 테스트 하는 것이다(Ant/Maven 같은 곳에서). 테스팅 프레임워크는 OSGi 번들로 사용하기 위해 만들어 둔 것이 아니다.

다음을 쭉 살펴보면 JUnit 기반 통합 테스트를 작성하는 것이 쉬워질 것이다.

본 챕터의 나머지는 스프링 DM 테스팅 스위트가 제공하는 기능들을 설명한다.

9.2.1. 간단한 OSGi 통합 테스트 작성하기

진단 프레임워크에는 특정 기능을 제공하는 여러 클래스들이 있는데, 여러분이 작성한 대부분의 클래스들은 org.springframework.osgi.test.AbstractConfigurablBundleCreatorTests를 상속하면 된다.

이 클래스를 확장하고 BundleContext 필드를 사용하여 OSGi 플랫폼을 사용해보자.

public class SimpleOsgiTest extends AbstractConfigurableBundleCreatorTests {

public void testOsgiPlatformStarts() throws Exception {
    System.out.println(bundleContext.getProperty(Constants.FRAMEWORK_VENDOR));
    System.out.println(bundleContext.getProperty(Constants.FRAMEWORK_VERSION));
    System.out.println(bundleContext.getProperty(Constants.FRAMEWORK_EXECUTIONENVIRONMENT));
    }
}

간단하게 JUnit 테스트를 실행하듯이 테스트를 실행하면 된다. Equinox 3.2.x 에서 실행하면 다음과 같은 결과를 얻을 수 있다

Eclipse
1.3.0
OSGi/Minimum-1.0,OSGi/Minimum-1.1,JRE-1.1,J2SE-1.2,J2SE-1.3,J2SE-1.4}

보시다시피, 테스팅 프레임워크는 테스트 실행에 필요한 번들들 필요한 번들들(스프링, 스프링 DM, slf4j ...)을 자동으로 설치해준다.

9.2.2. 테스트에 필요한 것들 설치하기

스프링 DM jar와 테스트 자체를 제외하면 몇몇 라이브러리나 통합 테스트 대상이 되는 코드에 대한 의존도가 높다.

아파치 커먼스 Lang에 의존하고 있는 다음의 테스트 코드를 살펴보자.

import org.apache.commons.lang.time.DateFormatUtils;
    ...
      public void testCommonsLangDateFormat() throws Exception {
        System.out.println(DateFormatUtils.format(new Date(), "HH:mm:ssZZ"));
    }
}

위 코드를 실행하면, 다음과 같은 예외가 발생할 것이다.

java.lang.IllegalStateException: Unable to dynamically start generated unit test bundle
     ...
Caused by: org.osgi.framework.BundleException: The bundle could not be resolved.
Reason: Missing Constraint: Import-Package: org.apache.commons.lang.time; version="0.0.0"
    ...
    ... 15 more

테스트는 org.apache.commons.lang.time 패키지를 필요로 하지만, 이걸 공개한 번들은 존재하지 않는다. 이 문제를 해결하기 위해 commons-lang 번들을 설치해본자.(2.4 이상의 버전을 설치해야 한다. 그래야 OSGi 라이브러리다.)

설치되어야 할 번들을 getTestBundlesNames 또는 getTestBundles를 사용해서 명시할 수 있다.

기본적으로 테스트 스위트는 로컬 maven2 저장소를 사용하여 구성물을 위치시킨다. 구성물 그룹 아이디, 이름, 버전을 콤마로 구분한 문자열로 나열한 것을 기본 locator가 읽어서 해당 구성물을 찾아서 설치한다. 커스텀 locator를 구현하여 설정할 수 있다. org.springframework.osgi.test.provisioning.ArtifactLocator 인터페이스를 구현한 다음 끼워 맞추면 된다.

통합 테스트를 다음과 같이 수정하여 필요한 번들을 설치하자.

protected String[] getTestBundlesNames() {
     return new String[] { "org.springframework.osgi, cglib-nodep.osgi, 2.1.3-SNAPSHOT",
         "org.springframework.osgi, jta.osgi, 1.1-SNAPSHOT",
         "commons-lang, commons-lang, 2.4" };
     };
}

테스트를 다시 실행하면 위의 번들들이 OSGi 플랫폼에 설치된다.

노트

위에서 언급한 구성물들이 여러분의 로컬 메이븐 저장소에 있어야 한다.

9.2.3. Advanced testing framework topics

테스팅 프레임워크는 커스터마이징을 많이 할 수 있다. 이 번 챕터에서 여러분에게 유용한 후킹을 소개하고자 한다. 하지만, 이런 팁들이 테스트 코드의 복잡도를 높일 수도 있다.

9.2.3.1. 테스트 manifest 커스터마이징

자동 생성된 manifest가 테스트에 적당하지 않을 수도 있다. 예를 들어 manifest에 몇몇 새로운 헤더나 필수가 아니라 부가적인 import가 필요할때가 있다.

간단한 경우, 자동 생성된 manifest를 조작할 수 있다. 아래의 예제에서 번들 클래스패스를 명시적으로 설정하고 있다.

protected Manifest getManifest() {
      // let the testing framework create/load the manifest
      Manifest mf = super.getManifest();
      // add Bundle-Classpath:
      mf.getMainAttributes().putValue(Constants.BUNDLE_CLASSPATH, ".,bundleclasspath/simple.jar");
      return mf;
}

또 다른 방법으로 여러분이 직접 작성한 manifest 파일을 getManifestLocation() 메소드에 설정할 수도 있다.

protected String getManifestLocation() {
      return "classpath:com/xyz/abc/test/MyTestTest.MF";
}

둘 모두 manifest에 다음과 같이 설정되어 있어야 한다.

“Bundle-Activator: org.springframework.osgi.test.JUnitTestActivator”

저렇게 설정되어 있지 않으면, 테스팅이 제대로 동작하지 않을 것이다. 또한 JUnit, Spring, Spring DM의 특정 패키지들을 import 해줘야 된다.

Import-Package: junit.framework,
  org.osgi.framework,
  org.apache.commons.logging,
  org.springframework.util,
  org.springframework.osgi.service,
  org.springframework.osgi.util,
  org.springframework.osgi.test,
  org.springframework.context

테스트 클래스가 사용할 패키지 import에 실패하면 테스트는 실패할 것이고 NoDefClassFoundError가 발생할 것이다.

9.2.3.2. 테스트 번들 컨텐츠 커스터마이징

기본적으로, 테스트 대상이 되는 번들을 테스트 할 때 테스팅 인프라는 ./target/test-classes 폴더 밑에 있는 모든 클래스, xml, 프로퍼티 파일들을 사용한다. 이건 메이븐 구조에 맞게 설계된거다. 이런 설정을 두 가지 방법으로 변경할 수 있다.
  • AbstractConfigrableBundleCreatorTests getXXX 메소드를 구현하는 프로그래밍을 하는 방법.
  • 테스트 케이스와 비슷한 이름을 가진 프로퍼티 파일을 작성하는 선언적인 방법. 예를 들어, com.xyz.MyTest 가 사용할 설정 프로퍼티 파일은 com/xyz/MyTest-bundle.properties 파일이어야 한다.
표 9.1. 기본 테스트 jar 컨텐츠 설정

생략

이 옵션은 특정 리소스를 필요로 하는 테스트를 작성할 때 유용하다. AbstractConfigurableBundleCreatorTests와 AbstractOnTheFlyBundleCreatorTests를 살펴보면 보다 많은 후킹 메소드를 찾을 수 있을 것이다

9.2.3.3. MANIFEST.MF 생성 이해하기

테스트 번들 컨텐츠를 기반으로 테스트 manifest를 자동 생성 해주는 테스팅 프레임워크의 유용한 기능 중 하나다. 바이트코드를 분석하여 필요로 하는 페키지들을 import 하는 manifest를 작성해준다. 생성된 번들은 테스트를 실행하기 위한 용도기 때문에, 다음과 같은 가정을 전제로 한다.
  • 아무런 패키지도 export하지 않는다.
  • 페키지를 나누는 기능(서로 다른 번들에서 같은 패키지에 클래스들을 제공하는 기능)을 지원하지 않는다. Split package는 OSGi 스펙 3.13에 따라서 권장하지 않는다.
  • 테스트 번들은 오직 테스트 클래스들만 가지고 있다. 기본 설정을 변경하려면, createManifestOnlyFromTestClass 가 true를 반환하도록 재정의하라.

protected boolean createManifestOnlyFromTestClass() {
    return true;
}

노트

번들에 담겨있는 클래스들의 수와 크기에 Manifest를 작성하는데 필요한 시간이 비례한다.

일반적인 OSGi 번들용 manifest를 작성하는 것이 목적이 아니라, 빠르고 간단하게 테스트를 위한 것을 만들기 위한 용도이다.

9.2.4. OSGi application context 만들기

스프링 DM 테스팅 스위트는 스프링 테스팅 클래스들을 기반으로 하고 있다. application context를 만들려면, getConfigLocation 메소드를 재정의하여 application context 설정파일 위치를 알려주면 된다. 실행시에, OSGi application context가 생성되고 테스트 케이스를 실행할 동안 캐쉬될 것이다.

protected String[] getConfigLocations() {
   return new String[] { "/com/xyz/abc/test/MyTestContext.xml" };
}

9.2.5. 사용할 OSGi 플랫폼 설정하기


테스팅 프레임워크는 3개의 OSGi 4.0 구현체, Equinox, Knopflefish, Felix를 지원한다. 이걸 사용하려면 테스트 클래스패스에 이들이 존재해야 한다. 기본적으로 테스팅 프레임워크는 Equinox를 사용한다. 이 설정을 바꾸는 방법은 두 가지다.
  • getPlatformName() 메소드를 사용하는 프로그래밍적인 방법.
Platforms 인터페이스 구현체의 이름을 설정하여 사용할 플랫폼을 알려준다.

protected String getPlatformName() {
   return Platforms.FELIX;
}
  • org.springframework.osgi.test.framework 시스템 속성을 사용한 선언적인 방법
만약 이 속성이 설정되면, 테스팅 프레임워크는 이 값을 플랫폼 구현체의 풀 네임 값으로 사용할 것이다. 만약 문제가 생기면, Equinox를 다시 사용할 꺼고 경고 메시지를 로깅한다. 이 옵션은 (Ant나 Maven같은) 빌드 툴에게 유용하다. 왜냐면 테스트 코드를 변경하지 않고도 특정 타켓 환경을 알려줄 수 있으니까.

9.2.6. 테스트 의존성 대기하기

테스팅 프레임워크에 내장된 기능 중 하나는 테스트를 실행할 때 필요한 의존성들이 설치 될 때까지 기다리는 것이다. OSGi 플랫폼의 동시성 때문에, 번들이 설치됐다고 해서 해당 번들이 제공하는 서비스가 동작중이라는 것을 보장할 수는 없다. 테스트가 필요로 하는 서비스가 완전히 가용하기 전에 테스트를 실행하는 건 테스트 결과를 더럽히는 일이다. 기본적으로 테스팅 프레임워크는 사용자가 설치한 번들을 모두 조사해서, 스프링을 사용한 번들일 경우 해당 번들이 완전히 시작될 때까지(시작 상태가 되면 서비스 설치된거니까..) 기다린다. 이 기본 행위를 shouldWaitForSpringBundlesContextCreation 메소드에서 변경할 수 있다. AbstractSynchronizedOsgiTests를 참조하라.

9.2.7. 테스팅 프레임워크 성능

테스팅 프레임워크가 제공하는 모든 기능을 고려했을 떄, 성능적인 측면에서 병목현상을 야기하지는 않을지 의심스러울 것이다. 먼저, 테스팅 프레임워크가 자동으로 해주는 모든 일들은 어떻게 해서든 해야만 하는 일들이다. 그 작업들을 손수하기에는 에러가 발생할 여지가 너무 많고 시간 소비도 만만치 않다.

현재의 인프라는 거의 반년간 사용해 왔다. 통합 테스트(120개 정도)를 실행하는데 노트북에서 3분 30초 가량 걸린다. 대부분의 시간은 OSGi 플랫폼을 시작하고 끄는데 소비된다. "테스팅 프레임워크"는 오직 10%가량의 시간만 소비한다.

하지만 우린 필요한 설정을 보다 최소화하고, 보다 더 빠르고 똑똑하게 만들려고 한다. 좋은 아이디어가 있으면 이슈트래커나 포럼을 통해서 언제든지 제안해달라. 
신고

'Spring DM > Chapter 9' 카테고리의 다른 글

9.2. Integration Testing  (0) 2008.06.22
9.1. OSGi Mocks  (0) 2008.06.17
Chapter 9. Testing OSGi based Applications  (0) 2008.06.17
top


파이어폭스 3.0 용 All-In-One Gesture

Good Tools : 2008.06.19 23:34


http://pagesperso-orange.fr/marc.boullet/ext/extensions-en.html

위에 있습니다. 아직까지 한국 모질라 업데이트 사이트에는 2.0 버전으로 올라와 있어서 아직 안 나온건줄 알았는데 어떤 분이 3.0 나왔다고 댓글로 달아놨네요. 멋진분입니다.

저거 없인 웹 서핑을 못하겠습니다. OTL

뭔지 모르시는 분들을 위해 간략하게 설명 드리면 다음과 같습니다. 마우스 오른쪽 버튼을 누른 상태에서 선으로 그림을 그리면 브라우져가 말 귀를 알아 듣습니다.

오른쪽: 앞 페이지
왼쪽: 이전 페이지
위로: 새 탭
아래로 + 오른쪽(니은이 되겠죠.): 탭 닫기
아래로 + 왼쪽: 최소화
위 + 아래: 새로고침

이밖에도 이미지 확대/축소, 북마킹 등 여러 기능을 마우스로 실행할 수 있습니다. 귿이죠!
 
ps: 파이어버그는 언제나오나.. 빨랑 3.0 지원해줘~
신고
top


Table 애노테이션

Hibernate/Annotation : 2008.06.19 09:00


패키지: javax.persistence

라이브러리: persistence-api-1.0.jar

속성:
- catalog: 테이블의 카탈로그
- name: 테이블 이름. 기본값은 entity 이름
- schema: 테이블의 스키마
- uniqueConstraints: Unique 제약을 걸 컬럼 설정.

예제
@Table(uniqueConstraints = @UniqueConstraint(columnNames = { "date", "item_id", "bay_id" }))
pubic class Inv { ... }

신고

'Hibernate > Annotation' 카테고리의 다른 글

@CollectionOfElements 애노테이션  (0) 2008.09.19
Table 애노테이션  (0) 2008.06.19
JPA @Transient  (0) 2007.09.27
JPA @JoinColumn  (1) 2007.09.22
JPA @ManyToOne  (0) 2007.09.22
JPA @OneToMany  (0) 2007.09.22
top


감독과 선수의 관계

모하니?/Thinking : 2008.06.18 23:55


감독이 선수보고 교체로 들어가서 골을 넣으라고 지시했다 치자... 아니다. 사실 골을 넣으라고 지시하진 않을꺼다. 그건 너무 당연한거고 골을 넣기 위한 작전을 지시했을 것이다. 좌측으로 파고 들어서 2대1 패스로 문전으로 돌파하여 찬스를 만들어라. 정도로 지시했을 수 있겠다. 그리고 실제로 그 선수가 경기장에 들어갔다.

아차.. 상황이 좋치 않다. 하필 아까까지 좌측에 있던 수비수가 우측에 있던 수비수와 위치를 바꿨다. 감독은 좌측에 있는 수비수가 허접하다는 파악했고 내가 충분히 제치고 들어갈 수 있다고 생각했을텐데 상황이 바꼈다. 우측 수비수는 거의 세계최강이다. 내가 호날두도 아니고, 별로 뚫을 자신이 없다.

이 상황에서 1번 선수는 감독이 시킨대로 좌측 돌파를 시도한다. 그리고 돌파시도는 막히고 감독의 작전은 수포로 돌아간다.

같은 상황에서 2번 선수는 지시의 목적은 '골'이지 지시를 꼭 따를 필욘 없겠다는 개념을 지니고 있다. 그래서 갑자기 우측 선수와 수신호로 위치를 바꾸자는 신호를 보냈고 평소 호흡이 잘 맞는 사이인 우측 선수는 내가 무슨 생각을 하고 있는지 간파하고 뜻대로 나와 자리를 바꿨다. 상대 수비가 좀 당황한 모습이다. 감독의 작전은 정확하게 들어맞았다. 딱 하나 '좌측'에서 '우측'으로 한 글자 차이로 말이다.

사용자 삽입 이미지
[슬램덩크 중 상양의 선수겸 코치 김수겸]

자. 이제는 감독 차례다.

거짓말을 보태서 감독은 두 종류가 있을 수 있겠다. 방금 위의 선수가 넣은 골을 기뻐하는 감독과 화가난 감독말이다. 후자는 정말이지 무서운 감독이다. 전자가 바로 내가 좋아하는 스타일의 감독이다.

사용자 삽입 이미지

[슬램덩크 중 북산의 안감독]

화가난 감독도 타당하다. 자신이 심사숙고한 작전을 지 멋대로 바꿔버리고 심지어 진영마저 바꿔버린 선수를 용서할 수 없을 것이다. 저 선수 때문에 자신이 관리하는 모든 것이 흐트러졌기 때문이다.

그럼 네 명의 주인공

1. 지시대로 움직이는 선수
2. 지맘대로 움직이는 선수
3. 관장하는 감독
4. 방관하는 감독

넷 중에서 1, 3은 나쁘고 2, 4는 좋은 사람일까? 그렇치 않다. 1번과 3번이 만나면 그 만큼 찰떡궁합도 없다. 그러나 1번과 4번이 만나면 어떨까? 선수는 어쩔줄을 몰라할 꺼고, 감독은 속이 터질꺼다. 2번과 3번이 만나면 어떨까? 선수는 감독이 짜증나 죽을 지경이고, 감독은 선수를 빨리 다른 곳으로 보내고 싶거나 아예 후보로 빼버릴 거다.

자신과 맞지 않는 선수들에게 자신의 방식을 강요하는 감독이 프로젝트의 실패를 선수들에게 돌릴 수 있을까? 프로젝트 실패를 오로지 자신과 맞지 않은 감독 탓으로 돌릴 수 있을까? 프로젝트의 성공을 "좋은(?)" 혹은 "뛰어난" 아키텍트나 컨설턴트 때문이라고 해도 되는 걸까? 프로젝트의 성공을 개발자에게 돌려주는 현장은 있나?? 팀웤이 맞지 않는데 성공하는 프로젝트는 있나? 궁금하다...

감독은 감독 나름대로 선수는 선수 나름이지 감독이 선수를 자신의 방식대로 교육시켜서 끌고가야 하는건 아닌거 같다. 선수가 원하는 방식으로 키워줄 수 있는 감독이야 말로 진정한 교육을 하는 것이지 전자는 세뇌일 것이다.

마지막으로 감독 만큼이나 선수도 중요하다. 암만 똑똑하고 사려깊은 결정을 할 수 있다한들, 그걸 실행할 수 있는 선수가 없으면 상상의 나래를 펼친거나 마찬가지 아닌가. 실전에 상상따위가 가당한가? 만약 그렇다면, 나는 날아올라서 골을 상대편 골대에 쳐 넣으라고 하겠다.

그런데 문제는 현실에서는 위에서 언급한 네 명처럼 순수한 의도(경기의 목적은 오리지 승리 뿐이다.)를 가지고 경기에 임하는 사람들만 있는게 아니라는 것이다.

사용자 삽입 이미지
[슬램덩크 중 풍전의 에이스킬러 남훈]


신고
top


해학적인 대한민국 2008년 현대사

모하니?/Watching : 2008.06.18 11:42


동영상 한 방으로 쉽게 익힐 수 있습니다. 영어 공부도 되구요.
후반 19분 부터는 꼭 보세요.

신고
top


9.1. OSGi Mocks

Spring DM/Chapter 9 : 2008.06.17 22:28


대부분의 OSGi API들이 인터페이스고 EasyMock같은 라이브러리를 사용하여 목객체를 만들어 사용하는 것이 간단할 수도 있지만, 실제로는 상당히 많은 코드를 필요로 한다.(특히 JDK 1.4에서..) 테스트를 짧고 간결하게 유지하기위해, 스프링 DM은 org.springframework.osgi.mock 패키지 아래에 OSGi 목들을 제공한다.

이것들이 유용한지 아닌지는 여러분들에게 달려있다. 우린 스프링 DM 테스트 스위트를 만들 때 이들을 상당히 많이 사용했다. 아래의 코드는 그런 테스트 코드에서 흔히 볼 수 있는 코드 조각이다.

private ServiceReference reference;
private BundleContext bundleContext;
private Object service;
   
protected void setUp() throws Exception {
    reference = new MockServiceReference();
    bundleContext = new MockBundleContext() {

        public ServiceReference getServiceReference(String clazz) {
            return reference;
        }

        public ServiceReference[] getServiceReferences(String clazz, String filter)
                throws InvalidSyntaxException {
            return new ServiceReference[] { reference };
        }
       
        public Object getService(ServiceReference ref) {
            if (reference == ref)
               return service;
            super.getService(ref);
        }
    };

    ...
}
   
public void testComponent() throws Exception {
    OsgiComponent comp = new OsgiComponent(bundleContext);
   
    assertSame(reference, comp.getReference());
    assertSame(object, comp.getTarget());
}

마무리 하자면, 스프링 DM이 제공하는 라이브러리들을 사용해보고 여러분들이 가장 편한다고 느끼는 라이브러리를 사용하라. 우리가 작성한 테스트 스위트에서는 EasyMock 라이브러리와 통합 테스트를 많이 사용했다.
신고

'Spring DM > Chapter 9' 카테고리의 다른 글

9.2. Integration Testing  (0) 2008.06.22
9.1. OSGi Mocks  (0) 2008.06.17
Chapter 9. Testing OSGi based Applications  (0) 2008.06.17
top


Chapter 9. Testing OSGi based Applications

Spring DM/Chapter 9 : 2008.06.17 22:10


베스트 프랙티스를 잘 따르고 스프링 DM 지원 기능을 사용한다면, 여러분들이 작성한 bean 클래스들은 단위 테스트가 용이할 것이다. OSGi를 직접 참조하지도 않을 것이고, 최소한의 인터페이스 기반의 OSGi API(BundleContext와 같은..)만을 사용하여 mock 객체를 만드는 것도 쉬워질 것이다. 단위 테스트와 통합 테스트 둘 다 스프링 DM이 지원한다.
신고

'Spring DM > Chapter 9' 카테고리의 다른 글

9.2. Integration Testing  (0) 2008.06.22
9.1. OSGi Mocks  (0) 2008.06.17
Chapter 9. Testing OSGi based Applications  (0) 2008.06.17
top


8.7. Spring-MVC Integration

Spring DM/Chapter 8 : 2008.06.17 22:00


1.1부터 스프링 DM은 스프링 MVC 프레임워크와 밀접하게 통홥되었다. 이번 섹션에서 어떻게 스프링 MVC 애플리케이션을 OSGi 환경에서 실행할 수 있는지 살펴보겠다.

OSGi 플랫폼에서 제대로 사용되려면, 스프링 MVC를 새로운 환경으로 이전해야 한다. 스프링 DM은 OSGi를 인식하는 application context를 제공한다.(OsgiBundleXmlWebApplicationContext) 이것은 스프링 MVC의 XmlApplicationContext와 동일한 역할을 한다. application context는 웹 애플리케이션 BundleContext를 알고 있고 따라서 OSGi 영역에 있는 자원들을 읽고 OSGi 서비스를 공개하고 BundleContextAware를 지원하고 클래스패스에 포함되어있는 번들들을 컴포넌트스캔할 수 있다.

이 애플리케이션 컨텍스트를 사용하려면 스프링의 ContextLoaderListener의 contextClass라는 파라미터와 DispatcherServlet을 사용하면 된다.

<context-param>
  <param-name>contextClass</param-name>                                                                   (1)
  <param-value>
org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext
</param-value>    (2)
</context-param>

<listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>                        (3)
</listener>

<servlet>
  <servlet-name>petclinic</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>                              (4)
  <load-on-startup>2</load-on-startup>
  <init-param>
    <param-name>contextClass</param-name>                                                             (5)
    <param-value>
org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext
</param-value>  (2)
  </init-param>
</servlet>

(1) 스프링의 ContextLoaderListner가 최상위 웹 애플리케이션 컨텍스트 타입을 알기 위한
context-param 이름
(2) OSGi를 인식하는 web application context 풀네임
(3) 스프링 설정 읽어들이는 리스너
(4) 스프링 MVC 젤 앞단 컨트롤러
(5) 스프링의 DispatcherServlet이 웹 애플리케이션 컨텍스트 타입을 알기 위한 init-param

위와같이 설정하면,  스프링 DM 번들은 구동중인 BundleContext를 가져다 사용할 수 있으며 OSGi 환경을 인식할 수 있다.

노트

물론 스프링 MVC 애플리케이션에는 적절한 import 문들이 들어가있어야 한다. 즉 WAR도 번들이기 때문에 manifest 파일에 적절하게 설정되어 있지 않으면, 클래스패스가 맞지 않게되고 따라서 제대로 동작하지 않을 것이다.

신고

'Spring DM > Chapter 8' 카테고리의 다른 글

8.7. Spring-MVC Integration  (0) 2008.06.17
8.6. OSGi-ready libraries and web development  (0) 2008.06.17
8.5. Customizing the standard deployers  (0) 2008.06.14
8.4. web extender 설정하기  (0) 2008.06.12
8.3. WAR classpath in OSGi  (0) 2008.06.12
8.2. Web support 사용법  (0) 2008.06.12
8.1. 지원하는 웹 컨테이너  (0) 2008.06.12
Chapter 8. Web Support  (0) 2008.06.12
top


8.6. OSGi-ready libraries and web development

Spring DM/Chapter 8 : 2008.06.17 20:32


불행히도, 현재 대부분의 웹 개발용 라이브러리들은 OSGi 번들이 아니다. 즉 그 라이브러리들을 OSGi 공간에서 사용하려면 다른 번들에 내장된 채로 사용하는 수밖에 없다. 이 문제를 해결하기 위해서, 스프링 DM 프로젝트는 흔히 사용하는 라이브러리들을 OSGi에서 사용할 수 있는 형태로 바꾼 것들을 Maven 리파지토리에 올려서 제공하고 있다.

8.6.1. Deploying web containers as OSGi bundles

스프링 DM은 웹 컨테이너를 OSGi 서비스로 설치하는 것이 가능하게 한다. Tomcat 이나 Jetty 배포판이 그런 일을 하지는 않기 떄문에 스프링 DM은 간단하지만 유용한 두 개의 OSGi Activator를 스프링 DM 리파지토리에서 제공한다. 어떤게 설치되면, 프로그래밍적으로 기본 설정(커스터마이징 할 수 있다. activator는 공용이지만 설정은 쉽게 변경할 수 있다.)에 따라 적절한 웹 컨테이너를 시작시킨다.

8.6.1.1. Tomcat 5.5.x/6.0.x

아파치 톰캣 버전 5.5.x 와 6.0.x는 OSGi 구성물 형태로 catalina.osgi artifactId를 가지고 있다. 이 jar들은 오직 commons-logging, JMX, Servlet/JSP 라이브러리만을 필요로 한다.

게다가 저장소에는 톰캣 Activaor도 있는데 이들의 이름은 catalina.osgi.start로 되어있다. activator는 톰캣 XML 설정을 이해하며 서버를 localhost, 8080 포터에서 실행하기위한 기본 설정을 가지고 있다. 이런 기본 설정은 conf/server.xml 을 톰캣 activator에 Fragment로 붙여서 기본 설정을 재정의할 수 있다.

fragment를 붙이려면, 다음과 같이 manifest에 추가한다.

Fragment-Host: org.springframework.osgi.catalina.start.osgi

8.6.1.2. Jetty 6.1.8+/6.2.0

Jetty는 기본적으로 OSGi에서 사용할 수 있는 형태다. 따라서 어떤 변형을 하지 않아도 OSGi 플랫폼에 설치할 수 있다. 하지만, activator가 없기 때문에 스프링 DM이 톰캣 activator같은 걸 하나 제공해준다. 이 activator는 jetty.start.osgi라는 이름을 가지고 있다. 톰캣 activator와 마찬가지로 이녀석도 localhost에 8080 포트로 기본 설정을 포함하고 있다. 이 기본 설정을 바꾸려면 etc/jetty.xml 에 설정을 한다음 fragment로 붙이면 된다.

Fragment-Host: org.springframework.osgi.jetty.start.osgi

extender처럼, 각각의 activator들은 사용자가 아무것도 제공하지 않으면 기본값을 사용한다.

8.6.2. Common libraries

Servlet, JSP, Standard Taglib, Commons-EL 및 기타 라이브러리들을 스프링 DM 저장소에서 이용할 수 있다.
신고

'Spring DM > Chapter 8' 카테고리의 다른 글

8.7. Spring-MVC Integration  (0) 2008.06.17
8.6. OSGi-ready libraries and web development  (0) 2008.06.17
8.5. Customizing the standard deployers  (0) 2008.06.14
8.4. web extender 설정하기  (0) 2008.06.12
8.3. WAR classpath in OSGi  (0) 2008.06.12
8.2. Web support 사용법  (0) 2008.06.12
8.1. 지원하는 웹 컨테이너  (0) 2008.06.12
Chapter 8. Web Support  (0) 2008.06.12
top


아.. 우울해..

모하니?/Thinking : 2008.06.16 22:15


너무 긴장한 코스가 다 끝나갈 쯔음 맨 마지막 남은 좌회전 신호와 직진 신호가 햇갈려서 대박 실수 후 "내리세요. 다음에 오세요!" "...네..."

연습도 많이 했는데 떨어져버렸다. 떨어져서 그런지 더욱 더 피곤하다. 회사가서 일하는 대신 면허셤 보러 온건데 건진건 없고 우울함만 남았다. 연습은 필요없다. 차문을 열고 차문을 닫고 나올 때까지 모든 과정(기본 자세부터해서 어디서 깜빡이를 키고 기아는 몇 단으로 가고 차선은 어디서 변경하는지 등)이 전부 몸에 베어버릴 만큼 연습을 했다. 하지만 떨어졌다. 실전을 연습처럼... 해야 하는데 그게 정말 쉽지 않았다.


오늘은 너무 우울해서 아무것도 하기 싫다. 아무것도. 라곤해도.. 스프링 DM 레퍼런스나 봐야겠다.
신고

'모하니? > Thinking' 카테고리의 다른 글

Lonely  (0) 2008.08.10
if가 있는데 왜 else if 가 있느냐구요?  (2) 2008.08.07
AnyFrame 프레임워크에 대한 소견  (10) 2008.07.19
Anyframe 보다가 흥분 해버렸네요.  (11) 2008.07.17
감독과 선수의 관계  (4) 2008.06.18
아.. 우울해..  (2) 2008.06.16
고객이 너무 바빠서 새로운 시스템에 적응할 시간조차 없다면  (0) 2008.06.11
한국 왜 이래...  (0) 2008.06.01
세상은 무섭다...  (0) 2008.04.01
IT 신조어가 필요한 시대  (0) 2008.03.28
바보  (2) 2008.03.25
top


8.5. Customizing the standard deployers

Spring DM/Chapter 8 : 2008.06.14 00:31


디플로이어는 시작시에 필요한 서비스들을 룩업한다. 필수 요소인 경우 디플로이어는 해당 서비스를 참조할 수 있을 때까지 기다리고, 만약 시간이 지나도 참조할 수 없을 때는 예외를 발생시킨다. 만약에 기본 타임아웃 설정이나 서비스 룩업 필터가 정의되어 있지 않으면, 스프링 DM의 reference 엘리먼트를 사용하여 설정할 수 있다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:osgi="http://www.springframework.org/schema/osgi"
   xmlns:p="http://www.springframework.org/schema/p"                                     (4)
   xsi:schemaLocation="http://www.springframework.org/schema/beans  
     http://www.springframework.org/schema/beans/spring-beans.xsd
     http://www.springframework.org/schema/osgi
     http://www.springframework.org/schema/osgi/spring-osgi.xsd">

    <osgi:reference id="myTomcatServer"                                                  (1)
        interface="org.apache.catalina.Service"
        filter="(environment=testing)"
        cardinality="0..1"/>
        
    <bean id="warDeployer"                                                               (2)
        class="org.springframework.osgi.web.deployer.tomcat.TomcatWarDeployer"
        p:service-ref="myTomcatServer"/>                                                 (3)

</beans>

1    사용자 정의 OSGi 서비스 룩업
2    디플로이어 정의Deployer definition (이름이 중요하다.)
3    서비스 속성 할당(p namespace 사용)
4    스프링의 p 네임스페이스 선언

위의 설정에 필요한 패키지를 import 해야 한다는 것을 주의 하자. 그리고 위는 웹 Extender에서 사용해야 하기 때문에 Fragment로 설정한다. 우선 import 해야 하는 패키지는 Catalina 패키지고, 그안에 있는 Service  인터페이스는 다른 패키지에 있는 Connector라는 것의 의존하고 있다. 따라서 다음과 같이 설정한다. 그러지 않으면, ClassNotFoundException 이나 NoClassDefFoundException이 발생한다.

# Catalina packages
Import-Package: org.apache.catalina,org.apache.catalina.connector
# Spring-DM Web Extender
Fragment-Host: org.springframework.bundle.osgi.web.extender



신고

'Spring DM > Chapter 8' 카테고리의 다른 글

8.7. Spring-MVC Integration  (0) 2008.06.17
8.6. OSGi-ready libraries and web development  (0) 2008.06.17
8.5. Customizing the standard deployers  (0) 2008.06.14
8.4. web extender 설정하기  (0) 2008.06.12
8.3. WAR classpath in OSGi  (0) 2008.06.12
8.2. Web support 사용법  (0) 2008.06.12
8.1. 지원하는 웹 컨테이너  (0) 2008.06.12
Chapter 8. Web Support  (0) 2008.06.12
top


Spring One 2008 세션 주제 살펴보기



로드존슨의 키노트로 Spring One 2008이 시작.
Spring Core
- Spring 2.5 on the Way to 3.0
- OSGi Programming Mode
- Using Spring Security 2
- Spring Transaction Choices for Performance
- Five Aspects You Don't Know About
- Working with Hibernate with Spring 2.5
- Open Forum with Rod Johnson
- Applying the Spring Frameworks for Model-Driven Architecture
- Making Sense of AOP Choices
- Spring Architecture and Best Practices

Spring Enterprise
- Enterprise Application Management
- Enterprise Development Tools for Spring
- Spring Dynamic Modules for OSGi
- Enterprise Integration with Spring Batch
- Enterprise Integration Patterns with Spring

Spring Web
- Decorating Web Pages with AJAX using Spring JavaScript
- Using Spring Web Services
- What's new in Spring MVC 2.5 and beyond
- JavaServerFaces - The Biggest Loser of Java Web Frameworks?
- RESTful Web Services in Spring
- Spring Web Flow 2.0 Deep Dive

Spring In Production
- Spring - Case Study
- Persistence Tuning for the Spring Environments
- Introduction to the Springsource Application Platform
- Building Web Applications with the Springsource Application Platform
- Inside SpringSource Application Platform
- Classloading in OSGi

Partner Talk
- EclipseLink--High Performance Persistence for Spring
- Case study - Spring and Spring MVC in Production
- Model Centric Design and Development of RIAs for Spring

하나같이 주제들도 좋고 무언가 기대하게 만드는 군요. 위 세션들 중에 일부는 어떤 블로그에 요약본을 올려주고 있습니다. 저같이 갈증나시는 분들은 그걸로라도...
신고
top


8.4. web extender 설정하기

Spring DM/Chapter 8 : 2008.06.12 23:57


core extender와 마찬가지로, 웹 Extender도 OSGi fragment로 설정될 수 있다. 같은 패턴을 사용해서, 웹 extender는 자신의 번들 영역에있는 META-INF/spring 폴더 밑에 있는 XML 파일들을 찾고 그것들을 하나의 application context로 조립하여 자신의 설정파일로 내부적으로 사용한다. 이런 기본 설정을 재정의 하려면, 아래 표에서 적당한 빈 이름을 찾아서, 그것들을 원하는 대로 정의한 다음 그걸 다음의 코드를 사용하여 fragment로 spring-osgi-web.jar에 붙이면 된다.

Fragment-Host: org.springframework.bundle.osgi.web.extender

다음의 빈들이 현재 Web extender에 의해 인식가능하다.

표생략

8.4.1. 웹 배포자 변경하기

톰캣 배포자에서 제티로 바꾸는 예제는 다음과 같다. META0INF/spring/jetty-deployer.xml에 다음과 같이 설정한다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans  
       http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="warDeployer"                                                               (1)
        class="org.springframework.osgi.web.deployer.jetty.JettyWarDeployer" />          (2)
</beans>

1    web extender에 의해 사용되고 있는 미리 정의한 빈 이름
2    org.springframework.osgi.web.deployer.WarDeployer 인터페이스를 구현하고 있는 Bean 구현체

파일을 만들었으면, 스프링 DM 웹 Extender 번들d에 OSGi fragment로 붙어있는 번들이 되어야 한다. 따라서 Fragment-Host 헤더를 사용한다.

Fragment-Host: org.springframework.bundle.osgi.web.extender

자 이제 위의 조각(Fragment)이 spring-osgi-web.jar 번들에 끼워졌기 때문에 웹 애플리케이션을 제티에 배포한다.

미리 만들어둔 제티 Fragment를 스프링 DM 메이븐 저장소에서 jetty.extender.fragment.osgi 아티팩트id로 사용할 수 있다.
신고

'Spring DM > Chapter 8' 카테고리의 다른 글

8.7. Spring-MVC Integration  (0) 2008.06.17
8.6. OSGi-ready libraries and web development  (0) 2008.06.17
8.5. Customizing the standard deployers  (0) 2008.06.14
8.4. web extender 설정하기  (0) 2008.06.12
8.3. WAR classpath in OSGi  (0) 2008.06.12
8.2. Web support 사용법  (0) 2008.06.12
8.1. 지원하는 웹 컨테이너  (0) 2008.06.12
Chapter 8. Web Support  (0) 2008.06.12
top


8.3. WAR classpath in OSGi

Spring DM/Chapter 8 : 2008.06.12 23:35


서블릿 스펙에는 WAR 내부에 특별한 의미를 지니는 위치와 몇가지 규칙들을 정의하고 있다. 이번 섹션에서는 이것들이 OSGi 환경에서 어떻게 처리되는지 살펴볼 것이다.

8.3.1. Static Recsources

WAR 번들을 설치할 때, static resource들의 경우, 스프링 DM은 번들 영역에서 가용한 것이 무엇인지만 신경쓴다. 이게 무슨 뜻이냐면 번들 jar 내부에 있는 것들과 거기에 붙어있는 fragment만을 사용할 수 있다는 것이다. 서블릿 스펙에 보면, 웹 애플리케이션에 접속한 클라이언트가 아니라 WEB-INF 폴더 이하에 있는 자원들만ServletContext API를 통해 사용 가능하다고 되어있다. 게다가 클래스패스(imported pachages, required bundles 또는 dynamic imports)에 있는 모든 자원은 애플리케이션 코드에서 읽어들여 사용할 수 있지만 그 밖에서는 참조할 수 없다.

8.3.2. 서블릿

기존의 WAR 배포와의 주요 차이점은 서블릿 패키지들을 WAR 번들에서 사용할 수 있도록 명시적으로 import되어야 한다는 것이다. 해당 패지키들을 Import -Package 속성에 추가한다.

Import-Package: javax.servlet,javax.servlet.http,javax.servlet.resources

추가적으로, 서블릿 스펙은 WAR의 클래스패스를 몇몇 미리 정의된 위치에 근거하고 있다. 빠르게 살펴보면 다음과 같다:
  • WEB-INF/classes: 모든 리소드들은 WEB-INF/Classes 밑에 있다
  • WEB-INF/lib/*.jar: 모든 jar 파일들은 WEB-INF/lib 밑에 있다.
여기에 추가로, 각각의 컨테이너 구현체들은 WAR 클래스패스에 추가되는 common 라이브러리들을 제공할 수 있다. OSGi 이기 때문에, WAR 클래스패스는 다시 구성한다. 스프링 DM은 미리 정의된 위치는 무시하고 항상 OSGi 클래스패스를 사용한다. 즉 WEB-INF/classes에 포함되어 있거나 WEB-INF/lib에 포함되어 있다 하더라도 WAR 번들이 import한 패키지들만 사용할 수 있다는 것이다. 다시 말하자면, WEB-INF/classes 밑에 있는 모든 클래스들중에 WAR OSGi 클래스패스에서 가용하지 않은 것들은 없는거나 마찬가지다.

미리 정의된 WAR 위치들을 설정하는 가장 쉬운 방법은, 그것들을 번들 클래스패스에 추가하는 것이다.

Bundle-Classpath: .,WEB-INF/classes,WEB-INF/lib/some.jar,WEB-INF/lib/lib.jar

번들 클래스패스에 추가하기 전에 그들을 OSGi 번들로 설치할 수 있는지 없는지 생각해야한다. 그렇게 함으로써 귿르을 다른 WAR에서도 사용할 수 있고 OSGi 버전잉을 할 수 있다. 동일한 VM에 같은 라이브러리의 상이한 버전이 여럿 존재하는 것이 가능해 진다.

8.3.3. JSP

JSP를 처리하려고, 스프링 DM은 Tomcat Jasper2 엔진을 통합했다. 즉 JSP 1.2, 2.0, 2.1을 지원한다는 것이다. OSGi화된 버전들은 스프링 DM 리파지토리에서 가용하다. OSGi 번들이 Jasper 클래스들을 import할 필요가 없다.

8.3.3.1. 태그 라이브러리들

JSP 스펙은 태그 라이브러리 생성하여 "JSP 페이지에서 재사용할 수 있는 기들을을 모듈화 하여 선언할 수 있도록"했다. 또한 재사용 가능한 taglib들은 자바 클래스들(Tag 구현체)와 어떤 태그들을 사용할 수 있는 기술한 파일을 컴포넌트로 가지고 있다. 스프링 DM은 taglib들을 jar 형태로 WEB-INF/lib 밑에 두거나 풀어져있는 상태로 WEB-INF/classes 밑에 두는 JSP 컨벤션을 확장하여, 번들 클래스패스(imported pachages, required bundles)에 있는 모든 taglib들을 찾아낸다.

스프링 DM은 번들 클래스패스 내에서 자동으로 taglib 파일(*.tld)들을 찾아서 그들을 Jasper 엔진에서 사용할 수 있게 해준다. 하지만, tag 정의가 자동으로 찾아지는 반면 tag 클래스들은 그렇지 않다. 여기서도 OSGi 클래스패스가 우선한다. 즉, 태그를 사용하려면, war 번들이 tag에 해당하는 클래스를 import 해야한다. 안그러면 태그를 사용할 수 없다.

많은 태그를 방출하는 라이브리들을 다룰 때, Impoert-Pachage 대신 Required-Bundle 헤더를 사용할 수 있다.

Require-Bundle: org.springframework.osgi.jstl.osgi

위의 헤더를 사용하면, JSP Standard Tag Library(JSTL)이 내보내는 모든 클래스들을 war 번들이 참조할 수 있고 따라서 JSP 내에서 사용할 수 있다.

주의할 것

Require-Bundle을 사용하기 전에 그 용법에 대해 OSGi 스펙 3.13 참조하라.

war 클래스패스에 어떤 매카니즘을 사용하든 상관없이, 여러 WAR들이 그것들을 공유하게 할 수 있다. 각각의 번들들은 오직 패키지만 import 할 수 있고 라이브러리 jar를 통째로 가져오진 못한다. 사실, 다른 번들들이나 Jar에 들어있는 패지키들을 선택적으로 사용하여 원하는 행위를 도출해 낼 수 있다. 매우 막강한 기능으로 웹 애플리케이션 배포를 용이하게 한다.


신고

'Spring DM > Chapter 8' 카테고리의 다른 글

8.7. Spring-MVC Integration  (0) 2008.06.17
8.6. OSGi-ready libraries and web development  (0) 2008.06.17
8.5. Customizing the standard deployers  (0) 2008.06.14
8.4. web extender 설정하기  (0) 2008.06.12
8.3. WAR classpath in OSGi  (0) 2008.06.12
8.2. Web support 사용법  (0) 2008.06.12
8.1. 지원하는 웹 컨테이너  (0) 2008.06.12
Chapter 8. Web Support  (0) 2008.06.12
top


8.2. Web support 사용법

Spring DM/Chapter 8 : 2008.06.12 23:11


WAR가 아닌 번들처럼, 스프링 DM 웹은 extender pattern을 사용하여 WAR를 찾고 설치한다. 하지만, 표준 스프링 DM Extender와 가장 큰 차이는 오직 스프링 DM이 WAR를 설치와 제거를  실행한다는 것이다. 실제 웹 애플리케이션 생성과 쓰레드 관리는 WAR가 설치된 웹 컨테이너에게 맡긴다. 스프링 DM 웹은 단지 언제 WAR를 웹 컨테이너로 배포할지와 언제 내릴지를 알려줄 뿐이다. 웹 애플리케이션을 생성하고 관리하는 것은 컨테이너에게 달려있다.

스프링 DM 웹을 사요하려면 다음을 설치해야한다.:
  • spring-osgi-web.jar: 스프링 DM 웹 지원
  • spring-osgi-web-extender.jar: 스프링 DM 웹 extender

시작한 OSGi WAR 번들을 찾고 그들을 지원하는 웹 컨테이너에 설치하기 위한 번들들이다. 기본적으로 Tomcat이 사용된다 하지만 이걸 Jetty나 다른 커스텀 서버로 변경할 수 있다. war 번들이 멈추면, 스프링 DM은 그와 관련된 웹 애플리케이션을 중지시키고 내린다. 기존의 웹 개발과의 차이점은, 서블릿 클래스들이 항상 우선권을 가지는 OSGi 클래스패스에 명시적으로 import 되야 한다는 것이다.

웹 애플리케이션을 실행하는 건 웹 컨테이너기 때문에, 스프링 설정 파일들을 META-INF/spring 폴더에 넣거나 스프링 DM manifest들을 사용할 필요가 없다. 그냥 간단하게 WAR에 있는 파일들을 번들로 묶고 웹 프레임워크를 사용하여 스프링 컨테이너를 시작시키면 된다. 스프링 MVC 연동을 할 수 있다. 스프링 Extender도 계속해서 필요한데, 이 게 있어야 네임스페이스를 처리할 수 있다. 만약에 이게 없으면, 스프링 네임스페이스(osgi:, aop: 심지어 beans: 까지도)를 처리할 수 없다.
신고

'Spring DM > Chapter 8' 카테고리의 다른 글

8.7. Spring-MVC Integration  (0) 2008.06.17
8.6. OSGi-ready libraries and web development  (0) 2008.06.17
8.5. Customizing the standard deployers  (0) 2008.06.14
8.4. web extender 설정하기  (0) 2008.06.12
8.3. WAR classpath in OSGi  (0) 2008.06.12
8.2. Web support 사용법  (0) 2008.06.12
8.1. 지원하는 웹 컨테이너  (0) 2008.06.12
Chapter 8. Web Support  (0) 2008.06.12
top


8.1. 지원하는 웹 컨테이너

Spring DM/Chapter 8 : 2008.06.12 22:41


현재까지는, Apache Tomcat 5.5.X/6.0.X 그리고 Jetty 6.1.8+/6.2.X를 사용할 수 있다.(다른 컨테이너들도 쉽게 끼워넣을 수 있다.). 웹 지원은 JDK 1.4 호환가능하다. 선택한 컨테이너가 필요로 하는 JVM을 확인하라. 일반적으로, Servlet 2.4/JSP 2.0은 JDK 1.4를 사용하고 Servlet 2.5/JSP2.1은 JDK 1.5를 필요로 한다.
신고

'Spring DM > Chapter 8' 카테고리의 다른 글

8.7. Spring-MVC Integration  (0) 2008.06.17
8.6. OSGi-ready libraries and web development  (0) 2008.06.17
8.5. Customizing the standard deployers  (0) 2008.06.14
8.4. web extender 설정하기  (0) 2008.06.12
8.3. WAR classpath in OSGi  (0) 2008.06.12
8.2. Web support 사용법  (0) 2008.06.12
8.1. 지원하는 웹 컨테이너  (0) 2008.06.12
Chapter 8. Web Support  (0) 2008.06.12
top







티스토리 툴바