플러그인으로 Java 웹 애플리케이션 확장

Question

관리할 수 없을 정도로 엉망이 된 웹 애플리케이션이 있습니다.

나는 그것을 일반적인 "프레임워크" 부분(여전히 페이지 및 이미지와 같은 웹 항목을 포함함)과 추가 기능과 화면을 추가하는 여러 모듈로 나누고 싶습니다.나는 이 리팩토링이 타사 확장을 위한 플러그인 시스템으로도 유용하게 사용되기를 바랍니다.

모든 모듈은 별도의 배포 단위(이상적으로는 war 또는 jar 파일)여야 합니다.

나는 여러 개의 일반 war 파일을 만들려고 했지만 Tomcat은 (서블릿 사양에 따라) 이러한 war 파일을 서로 완전히 분리하여 유지하므로 예를 들어 클래스를 공유할 수 없습니다.

"기본" 클래스 경로를 보려면 플러그인이 필요합니다.

플러그인을 나열하고 구성을 설정하는 등 플러그인을 제어하려면 기본 애플리케이션이 필요합니다.

나는 플러그인 자체(종속성을 지정하지 않는 한)와 동일한 Tomcat에서 실행될 수 있는 다른 관련 없는 웹 애플리케이션 간의 완전한 분리를 유지하고 싶습니다.

"기본" 응용 프로그램 URL 접두사 아래에 뿌리를 두고 싶지만 반드시 그럴 필요는 없습니다.

나는 Tomcat을 사용하고 싶지만(큰 아키텍처 변경은 너무 많은 사람들과 협력해야 함) EJB 또는 OSGi 세계에 깔끔한 솔루션이 있다면 듣고 싶습니다.

Answer 1

나는 당신이 설명하는 것과 동일한 문제를 해결하기 위해 Osgi를 사용한다는 아이디어를 촉발했습니다. 특히 나는 사용을보고있다 스프링 동적 모듈.

Answer 2

Java Portlets를 살펴보십시오. http://developers.sun.com/portalserver/reference/techart/jsr168/ - 간단히 말해서, 자체 포함 된 J2EE 웹 애플리케이션 사이의 상호 운용성을 허용하는 사양

편집하다포틀릿은 거의 프레임 워크가 불가능하다는 것을 언급하는 것을 잊었으므로 부모 애플리케이션에 Spring을 사용할 수 있으며 개별 개발자는 포틀릿에서 원하는 것을 사용할 수 있습니다.

Answer 3

Maven을 사용하여 프로젝트를 분리 한 다음 전쟁과 항아리 사이의 의존성을 해결하도록 보셨습니까? 전쟁 사이의 도서관의 복제로 끝나게 될 것입니다. 그러나 필요한 경우에만 (그리고 이것은 펑키 한 클래스 로더 재미에 들어 가지 않으면 문제가되지 않아야합니다).

Tomcat은 또한 비교적 투명한 방식으로 한 전쟁에서 다른 전쟁으로 이동 해야하는 경우 크로스 컨텍스트 응용 프로그램을 구성 할 수 있습니다 ...

동일한 단일 웹 앱 (루트) 아래에 물건을 유지하려면 사용자가 상대적으로 투명하게 만들기 위해 무대 뒤에서 관련 다른 웹 앱으로 전달되는 프록시 웹 앱을 만들 수 있습니까?

Answer 4

주요 문제는 시스템의 물리적, 정적 자산을 중심으로 하는 것입니다. 나머지는 간단하고 효과적으로 jar입니다.

WAR은 Tomcat에서 별도의 클래스로더로 분리되어 있지만 세션 수준에서도 분리되어 있습니다(각 WAR은 개별 웹 앱이며 자체 세션 상태를 가집니다).

Glassfish에서 WAR이 EAR에 번들로 포함된 경우 클래스 로더를 공유하지만(GF는 EAR에서 플랫 클래스 로더 공간을 사용함) 여전히 별도의 세션 상태를 갖습니다.

또한 서버의 다른 WAR로 "전달"할 수 있는지 확실하지 않습니다.문제는 상대 URL을 사용하여 웹 앱의 루트로 전달하고 각 웹 앱에는 자체 루트가 있으므로 단순히 "여기에서 거기로 갈 수 없다"는 것입니다.리디렉션할 수 있지만 전달과 동일한 것은 아닙니다.

따라서 웹앱의 이러한 기능은 컨테이너 내에서 동질적으로 배포하려는 시도에 반대됩니다.

그보다는 개별 모듈을 가져와서 단일 웹 앱으로 "병합"하는 "어셈블러" 유틸리티를 만드는 것이 가장 중요한 팁이라고 생각합니다.web.xml과 내용을 병합하고 jar와 클래스를 정규화하는 등의 작업을 수행할 수 있습니다.

WAR은 Java 세계의 기능이자 버그입니다.나는 컴파일된 애플리케이션을 설치 측면에서 "드래그 앤 드롭" 방식으로 배포할 수 있기 때문에 이 기능을 좋아하며, 이 기능은 지금 접하는 것보다 훨씬 더 많이 사용됩니다.하지만 나는 당신의 고통을 느낍니다.우리는 여러 앱에서 공유하는 공통 "핵심" 프레임워크를 갖고 있으며 기본적으로 이를 유지하기 위해 지속적으로 병합해야 합니다.우리는 그것을 스크립트로 작성했지만 여전히 약간의 고통을 겪습니다.

Answer 5

"또한 서버의 또 다른 전쟁에"앞으로 "를 수행 할 수 있는지 확실하지 않습니다. 문제가있는 문제는 웹 앱의 루트에 상대 URL을 사용하고 각 WebApp은 고유 한 루트를 가지고 있다는 것입니다. 당신은 단순히 "여기서 도착할 수 없다". 당신은 리디렉션 할 수 있지만, 그것은 앞으로와 같은 것은 아닙니다. "

그 전쟁으로 누군가가 할 수있는 한 다른 전쟁으로 전달할 수 있습니다.

유리 피쉬와 귀의 여러 전쟁 : 그것은 의미가 있습니다.

메인 클래스를 Tomcat의 공유 클래스 경로에 넣으면 개별 플러그인을 별도의 전쟁 파일에 넣을 수 있습니다.

기본 앱은 Server.xml에서 정의하는 Tomcat 서블릿의 일부일 수도 있습니다. 이것은 마스터 서블릿 일 수 있으며 다른 모든 전쟁은이 마스터 서블릿에 의해 통제 될 수 있습니다.

말이 돼 ?

Br,
~ a

Answer 6

플러그인 기능의 복잡성에 따라 Axis와 함께 구현 된 웹 서비스를 고려하고 있습니다.

그런 다음 기본 응용 프로그램은 서비스를 제공하는 URL로 웹 응용 프로그램 (플러그인)으로 구성됩니다.

내가 알 수 있듯이 장점은 두 가지입니다.

• 두 전쟁, 즉 SOAP/XML 메시지 사이에 멋지고 깨끗하고 디지털화 가능한 API를 얻습니다.
• 전체 응용 프로그램 회귀 테스트없이 단일 플러그인을 업그레이드 할 수 있습니다.

단점은 일부 축 프로젝트를 설정해야하며 일종의 플러그인 구성이 있어야한다는 것입니다. 또한 서비스 웹 애플리케이션에 대한 액세스를 제한해야하므로 약간의 구성이 필요할 수 있습니다.

플러그인이 동일한 데이터베이스에서 작동하는 경우 캐시 시간을 제한하거나 전쟁 스패닝 캐싱 레이어를 구성해야합니다.

Answer 7

또한 런타임에 플러그인(또는 모듈)을 추가하고 기존 실행 중인 웹앱을 향상시킬 수 있는 공통 또는 추상 프레임워크를 개발하려고 노력해 왔습니다.

이제 말씀하신 것처럼 WAR 또는 JAR 파일을 사용하여 수행하는 방법을 선호합니다.WAR 파일의 문제는 기존 앱에 플러그인으로 배포할 수 없다는 것입니다.Tomcat은 이를 별도의 웹 컨텍스트로 배포합니다.바람직하지 않습니다.

또 다른 옵션은 JAR 파일을 사용하고 일부 사용자 정의 코드를 작성하여 해당 JAR 파일을 WEB-INF/lib 폴더에 복사하고 클래스를 기존 클래스 로더에 로드하는 것입니다.문제는 JSP 또는 구성 파일과 같은 Java가 아닌 파일을 배포하는 방법입니다.이를 위해 두 가지 솔루션이 있습니다.JSP 대신 속도 템플릿을 사용하십시오. (b.) 컨텍스트 경로 대신 클래스 경로에서 JSP를 읽는 일부 사용자 정의 코드를 작성하십시오.

OSGI 또는 Spring Dynamic 모듈은 훌륭하지만 현재로서는 너무 복잡해 보입니다.느낌이 오면 다시 조사하겠습니다.

나는 플러그인의 라이프사이클을 관리하고 패키지된 JAR 파일에서 JSP를 계속 사용할 수 있는 간단한 API를 찾고 있습니다.

배포 시 플러그인의 jar 파일을 해제하고 파일을 올바른 디렉토리에 복사할 수도 있습니다.

Answer 8

응용 프로그램을 별도의 모듈로 분할 할 생각이라면 실제로 OSGI보다 더 좋은 것은 없습니다. GreenPages 예제를 살펴보십시오. 응용 프로그램에 필요한 항아리를 포함하는 상위 모듈 (Core)을 만들 수 있습니다.

구성 요소 프로그래밍에 대해 알고 있다면 곧 OSGI 모듈이 인터페이스처럼 행동하며 다른 모듈에 사용할 것을 노출해야합니다. 일단 이해하면 아주 간단합니다. 어쨌든 OSGI를 사용하는 방법을 배울 때는 정말 고통 스러울 수 있습니다. 우리는 Jackson의 버전으로 JSON을 사용하여 Module에 JAR로 추가 한 문제가있었습니다. 당신은 항상 당신의 요구에 대해 어떤 버전의 JAR 버전이로드되었는지를 두 번 확인해야합니다.

불행히도 OSGI 접근조차도 우리가 찾고있는 것을 해결하지 못합니다. 런타임에서 지속적인 모델과 기존 양식을 확장하는 방법.