Whiteship's Note


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


Chapter 8. Web Support

Spring DM/Chapter 8 : 2008.06.12 22:30


1.1.0 배포판 부터 도입된 주요 기능은 웹 애플리케이션 지원이고 이로인해 웹 애플리케이션을 OSGi에 배포하기 쉬워졌다.

웹 애플리케이션을 OSGi 위에서 돌리는 가장 큰 문제는 클로스로딩이다. 웹 애플리케이션에는 번들 영역(Bundle Space)라던지 가져온 패키지(Imported pachages)라는 개념이 없다. 각각의 웹 컨테이너들은 자신만의 클래스 로딩 계층구조를 가지고 있는 클래스패스를 사용하여 OSGi 공간과 출돌을 발생시킬 수 있다. 스프링 DM은 이런 문제들을 웹 컨테이너와 OSGi 공간 사이에 다리 역할을 하여 로딩이 더이상 문제가 되지 않도록 하고 있다. 그 기능과는 별개로, 스프링DM에서 웹 지원은 웹 컨테이너와 직접 통합하여 WAR 처리가 말그대로 서버에서 처리된다. 모든 설정과 기능(non-blocking vs blocking IO, thread pool, specification support(Servlet 2.3, 2.4, 2.5) 등등등)이 가용하다. 모든 타겟 컨테이너의 커스텀 설정 파일과 web.xml 문법이 모두 사용 가능하다.(스프링 DM은 전혀 이걸 파싱하지 않는다.) 요약하자면, 타겟 컨테이너가 지원하는 모든 것들이 스프링 DM을 사용한 OSGi WAR로 가용하다는 것이다.


'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


Chapter 7. 번들 다루기

Spring DM/Chapter 7 : 2008.06.12 22:03


스프링 DM은 기존에 존재하는 번들 또는 새로운 것을 설치하기 위한 스키마 엘리먼트를 제공한다. 적절한 OSGi 서비스를 대체하기 위해 사용하는 용도가 아니고, bundle은 해당 번들에 application context 라이프사이클에 따라 특정 행위를 할 수 있는 방법을 제동한다.

bundle 엘리먼트는 org.osgi.framework.Bundle 타입의 빈을 정의할 때 사용한다. 그들의 라이프사이클을 주도하는 등의 직접 번들을 다룰 수 있는 간편한 방법이다. 가장 간단하게는 symbolic-name 속성만 기술하면 된다.

<bundle id="aBundle" symbolic-name="org.xyz.abundle"/>

aBundle이라는 빈은 Bundle 타입의 어떤 속성이든지 주입될 수 있다.

만약 필요한 번들이 설치되어 있지 않다면, location 속성을 사용하여 설치할 위치를 나타낼 수 있으며 또한 action/destroy-action 속성을 사용하여 번들 라이프사이클을 제어할 수 있다. location 속성은 번들 jar 파일이 존재하는 위치를 명시할때 사용한다. action 속성은 번들 객체에 호출되어야 할 라이프사이클 액션을 설정한다. action의 값으로는 insatll, start, update, stop, uninstall이 있다. 이런 액션들은 Bundle 인터페이스에 있는 메소드들 이름과 일치한다.

각각의 action 값들이 현재 번들 상태에 따라 어떻게 해석될지는 다음 표와 같다.

표생략

예제:

<!-- 아래의 번들은 설치한 다음 시작할 것이다.-->
<bundle id="aBundle" symbolic-name="org.xyz.abundle"
   location="http://www.xyz.com/bundles/org.xyz.abundle.jar"
   action="start"/>

스프링 DM 예제에 들어있는 virtual-bundle 엘리먼트를 사용하여 OSGi 번들을 실제 존재하는 파일과 별개로 생성하여 사용할 수 있다.

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

Chapter 7. 번들 다루기  (0) 2008.06.12
top