[SPRING] OSGi로 JSF / Facelets / Spring 애플리케이션을 모듈화하는 방법은 무엇입니까?

OSGi로 JSF / Facelets / Spring 애플리케이션을 모듈화하는 방법은 무엇입니까?

나는 DI / bean 관리를 위해 Spring을 사용하는 매우 큰 JSF / Facelets 애플리케이션으로 작업하고있다. 내 응용 프로그램은 모듈러 구조를 가지고 있으며 현재 모듈화 표준화 방법을 찾고 있습니다.

내 목표는 여러 모듈 (가능한 경우 서로에 따라)에서 웹 응용 프로그램을 작성하는 것입니다. 각 모듈에는 다음이 포함될 수 있습니다.

내가 (거의 모든 비용을 지불하지 않고) 피하기를 원한다면 모듈 리소스 (예 : Facelets 템플릿)를 WAR에 복사하거나 모듈의 서블릿, 필터 등에 대한 web.xml을 확장해야합니다. 이 모듈을 사용하여 웹 응용 프로그램을 확장하려면 웹 응용 프로그램 (WEB-INF / lib, bundles, plugins, ...)에 모듈 (JAR, 번들, 이슈 ...)을 추가하십시오.

현재 클래스 패스 리소스를 기반으로하는 맞춤 모듈화 솔루션으로이 작업을 해결합니다.

마지막으로 OSGi에 대해 많이 읽었으며 OSGi를 표준화 된 모듈화 접근법으로 사용할 수있는 방법과 고려할 점이있었습니다. OSGi를 사용하여 개별 작업을 해결할 수있는 방법에 대해 생각해 보았습니다.

내 질문은 다음과 같습니다.

나는 당신의 의견에 대해 일반적으로 감사 할 것입니다.

해결법

1. ==============================

   1.당신이하려고하는 것은 몇 가지주의 사항을 제외하고는 행할 수 있다고 들립니다.

   당신이하려고하는 것은 몇 가지주의 사항을 제외하고는 행할 수 있다고 들립니다.

   보기 레이어 : 우선,보기 레이어가 약간 과장된 소리를냅니다. 런타임에 바인딩 된 관리 빈과 같이 극적인 것을 만들어 내려는 시도와 관련된 두통을 피할 수있는 맞춤 구성 요소를 사용하여 JSF 구성 요소를 모듈화하는 다른 방법이 있습니다.

   모듈 자체 : 둘째로, 모듈은 특히 모듈 식으로 보이지 않습니다. 첫 번째 글 머리 기호 목록은 모듈 자체가 아닌 상호 운용 가능한 웹 응용 프로그램을 만드는 것처럼 말합니다. 모듈에 대한 나의 생각은 각 구성 요소가 명확하고 명확한 이산 목적을 가지고 있다는 것입니다. ex가 vi의 기초가되는 방식처럼. OSGi 라우트를 다운 시키려면 모듈러를 다음과 같이 정의해야합니다 : 모듈화는이 논의를 위해 구성 요소가 핫 스왑 가능하다는 것을 의미합니다. 즉, 구성 요소가 핫 스왑 가능하다는 것을 의미합니다. 즉, 응용 프로그램을 중단하지 않고 추가 및 제거 할 수 있습니다.

   의존성 : 저는 모듈에 대한 당신의 묘사가 "아마도 서로에 달려 있습니다"라고 조금 걱정합니다. 아마도 이미 알고있을 것입니다.하지만 의존 관계는 지시 된 비순환 그래프를 형성해야합니다. 순환 종속성을 도입하면 앱의 최종 유지 가능성 측면에서 상처의 세계를 요구합니다. OSGi의 가장 큰 약점 중 하나는 순환 종속성을 막지 못하기 때문에이를 적용하는 것은 사용자의 몫입니다. 그렇지 않으면 의존성이 kudzu와 같이 커지고 점차적으로 시스템의 나머지 생태계를 질식시킬 것입니다.

   서블릿 : Fuhgeddaboudit. Servlet 3.0 스펙이 생산 될 때까지 (Pascal이 지적한대로) 서블릿을 웹 애플리케이션에 늦게 바인딩 할 수는 없습니다. 별도의 유틸리티 서블릿을 시작하려면 자체 서블릿에 넣어야합니다.

   OK, 너무 많은주의 사항. 이것이 어떻게 효과가 있을지 생각해 봅시다.

   자신 만의 JSF 모듈을 정의했다면 ... 정확히 무엇입니까? 정의 된, 사소한 목적, 즉 로그인 화면을 제공합시다. 그래서 로그인 화면을 만들고 OSGi를 사용하여 앱에 늦게 바인딩 한 다음 ... .jspx 페이지에서 로그인 기능을 정의하지 않았다면 앱에 로그인 기능이 있다는 것을 어떻게 알 수 있습니까? 앱이 알 수없는 무언가로 이동하는 것을 어떻게 알 수 있습니까?

   조건부 include 등을 사용하여이 문제를 해결할 수있는 방법이 있지만 (예 : ), 관리되는 loginBean이 다른 모듈에있을 때 상황이 조금 복잡해질 수 있습니다. 아직 앱에 소개되지 않았다. 사실, loginBean이 존재하지 않는 한 서블릿 예외가 발생합니다. 그럼 어떻게 하시겠습니까?

   모듈 중 하나에서 API를 정의합니다. 모듈간에 공유하려는 모든 관리 Bean을이 API 계층의 인터페이스로 지정해야합니다. 그리고 모든 모듈에는 사용할 인터페이스의 기본 구현이 있어야합니다. 이 API는 모든 상호 운용 가능한 모듈간에 공유되어야합니다. 그런 다음 OSGi 및 Spring을 사용하여 지정된 Bean과 그 구현을 연결합니다.

   나는 이것이 내가이 문제에 어떻게 접근 할 것인가가 아니라는 것을 잠시 생각할 필요가있다. 전혀. 로그인 페이지처럼 간단하거나 주식 차트만큼 복잡하다면 개인적으로 JSF 구성 요소를 만드는 것을 선호합니다. 그러나 요구 사항이 "관리 빈을 모듈화 (예 : 핫 스왑 가능)하고 싶습니다."라고 생각하면 이것이 작동하도록하는 유일한 방법입니다. 그리고 나는 그것이 작동 할 것이라는 것을 완전히 확신하지 못합니다. 이 이메일 교환은 JSF 개발자가 방금 작업을 시작한 것이 문제라고 제안합니다.

   나는 일반적으로 관리 Bean을 뷰 계층의 일부로 간주하며 뷰 로직에만 사용하고 다른 모든 것은 서비스 계층에 위임합니다. 관리 빈을 늦게 바인딩하는 것은 내 마음에, 그들을 뷰 계층에서 비즈니스 로직으로 승격시키는 것입니다. 모든 자습서가 서비스에 너무 집중되어있는 이유가 있습니다. 대부분의 경우 앱을 "헤드리스 (headless)"로 실행하기 위해 필요한 것이 무엇인지 고려하고 싶고, 예를 들어 Android 폰에서 모든 기능과 함께 실행되도록했습니다.

   그러나 다른 뷰 템플릿으로 스왑해야하는 것과 같이, 자신이 작업 한 것 자체가 뷰 로직입니다. OSGi / Spring은 도움을 줄 수 있어야하지만, 앱에서 OSGi의 Service Registry가 수행 한 작업과 거의 동일한 구현을 선택해야합니다.

   정적 리소스가 남습니다. 이들을 모듈화 할 수는 있지만 이러한 리소스를 검색 할 인터페이스를 정의해야하며 기본 구현을 제공하여 앱이 없을 경우 숨 막힐 수 있도록해야합니다. i18n이 고려 사항이라면 이것은 좋은 방법이 될 수 있습니다. 정말로 모험을 원한다면 정적 리소스를 JNDI로 푸시 할 수 있습니다. 이렇게하면 완전히 핫스왑이 가능 해지고 프로그래밍 방식으로 사용할 구현을 해결하려는 어려움을 피할 수 있지만 몇 가지 단점이 있습니다. 실패한 조회는 앱에서 NamingException을 발생시킵니다. 그리고 그것은 과잉입니다. JNDI는 일반적으로 앱 구성을 위해 웹 앱에서 사용됩니다.

   남은 질문은 다음과 같습니다.

   당신은 조금 있습니다. 이런 종류의 일을하는 앱을 보았지만 상당히 독특한 요구 사항을 발견 한 것 같습니다.

   모듈을 핫 스왑 가능하게하려면 OSGi와 더 가벼운 ServiceLocator 인터페이스를 선택하십시오.

   구성 요소 경계가 어디에 있는지에 대해 알지 못하면 실제로 말할 수 없습니다. 현재로서는 OSGi가 할 수있는 것보다 더 많은 일을하도록 밀고있는 것처럼 보입니다.

   그러나 내 말을 듣지 마십시오. 나는이 장소에서 다른 독서 자료를 발견했다.

   그리고 Spring Slices에 관해서 물어 보았으므로, 이것은 당신을 시작하기에 충분할 것입니다. Git 클라이언트가 필요하며 소스 코드를 살펴보면 앱을 스스로 익힐 수있는 것처럼 보입니다. 초기 프로토 타입 코드입니다.

2. ==============================

   2.현재 프로젝트에서 동일한 문제에 직면하고 있습니다. 제 생각에 OSGi는 표준 및 향후 지원 측면에서 가장 우수하고 깨끗한 솔루션이지만 현재 웹 애플리케이션에서 사용하려고하면 몇 가지 문제가 발생할 수 있습니다.

   현재 프로젝트에서 동일한 문제에 직면하고 있습니다. 제 생각에 OSGi는 표준 및 향후 지원 측면에서 가장 우수하고 깨끗한 솔루션이지만 현재 웹 애플리케이션에서 사용하려고하면 몇 가지 문제가 발생할 수 있습니다.

   클래스 로더와 리소스 필터를 기반으로하는 맞춤 솔루션은 나에게 매우 적합합니다. 예를 들어 Hudson 소스 코드 또는 JPF (Java Plug-in Framework) 프로젝트 (http://jpf.sourceforge.net/)를 학습 할 수 있습니다.

   web.xml을 확장 할 때 Servlet 3.0 사양 (http://today.java.net/pub/a/today/2008/10/14/introduction-to-servlet-3.html#)에 대해 운이 좋을 수 있습니다. pluggability-and-extensibility)을 지원합니다.

3. ==============================

   3.Servlet 3.0 스펙에 의해 소개 된 "web module deployment descriptor fragment"(aka web-fragment.xml)는 여기서 좋을 것입니다. 사양은 다음과 같이 정의합니다.

   Servlet 3.0 스펙에 의해 소개 된 "web module deployment descriptor fragment"(aka web-fragment.xml)는 여기서 좋을 것입니다. 사양은 다음과 같이 정의합니다.

   Java EE 6은 현재 당신을위한 옵션이 아닙니다. 여전히 표준화 된 솔루션이 될 것입니다.

4. ==============================

   4.엔터프라이즈 OSGi는 상당히 새로운 영역이므로 필요에 따라 직접 솔루션을 얻을 수 있다고 생각하지 마십시오. 그건 내가 춘분 (osgi 엔진 이클립스 뒤에 누락 된 것으로, 따라서 가장 큰 사용자 기반을 가진 것 중 하나)이 일관된 구성 / DI 서비스라고 말했다. 우리 프로젝트에서 최근에 비슷한 요구가 있었고 간단한 구성 osgi 서비스를 구축하지 못했습니다.

   엔터프라이즈 OSGi는 상당히 새로운 영역이므로 필요에 따라 직접 솔루션을 얻을 수 있다고 생각하지 마십시오. 그건 내가 춘분 (osgi 엔진 이클립스 뒤에 누락 된 것으로, 따라서 가장 큰 사용자 기반을 가진 것 중 하나)이 일관된 구성 / DI 서비스라고 말했다. 우리 프로젝트에서 최근에 비슷한 요구가 있었고 간단한 구성 osgi 서비스를 구축하지 못했습니다.

   모듈 가시성이 어떤 경우에는 클래스 액세스를 방해 할 수 있으므로 모듈 응용 프로그램에 내재 된 문제 중 하나는 DI 주위에 있습니다. 우리는 너무 이상적이지 않지만 작동하는 등록 된 친구 정책을 사용하여이 문제를 해결했습니다.

   구성 외에도 모듈 식 응용 프로그램을 작성하기위한 기초로 OSGi를 사용하는 방법에 대한 지침은 최근에 발표 된 Equinox 서적을 참조하십시오. 예제는 Equinox에만 적용될 수 있지만 원리는 모든 OSGi 프레임 워크에서 작동합니다. 링크 - http://equinoxosgi.org/

5. ==============================

   5.Spring DM Server (Eclipse Virgo로 전환 중입니다. 아직 릴리스되지 않았습니다). 최근 출시 된 OSGi 엔터프라이즈 스펙에는 많은 좋은 점이 있습니다.

   Spring DM Server (Eclipse Virgo로 전환 중입니다. 아직 릴리스되지 않았습니다). 최근 출시 된 OSGi 엔터프라이즈 스펙에는 많은 좋은 점이 있습니다.

   스프링 DM 튜토리얼 중 일부는 도움이 될 것입니다. 하지만 표준 모듈을 사용하여 웹 번들 외부에서 리소스와 클래스를로드 할 수 있습니다. 그 점에서, 그것은 적합합니다.

   세션 컨텍스트는 세션에서 예상대로 처리됩니다. 그러나 웹 브로드 캐스트간에 세션을 공유하는 데 문제가 있는지 여부는 확실하지 않을 수도 있습니다.

   하나의 웹 번들을 가지고있는 것을 볼 수도 있습니다. Eclipse 확장 레지스트리는 웹 애플리케이션의 기능을 확장합니다.

from https://stackoverflow.com/questions/2575669/how-to-modularize-a-jsf-facelets-spring-application-with-osgi by cc-by-sa and MIT license