of issues to-do
Fuji GlassFish V3 Integration
GlassFish V3 is an open-source, lightweight Web 2.0 development and deployment platform. It uses the HK2 module management system and runs on many OSGi platforms including Apache Felix. Project Fuji forms the core component of Open ESB v3 effort and represents Sun's next generation open source integration runtime, focused on providing a lightweight, developer-friendly, and extensible platform for composite application development. This document describes the plan to integrate Fuji with GlassFish v3.
|1||All v2 applications should deploy and run in V3 without changes||P0||-|
|2||Fuji framework code should not contain GF V3 specific code||P0||-|
|3||V3 should support composite applications that contain EAR, WAR, EJB jar, Jersey Jar etc||P0||-|
|4||EAR, WAR inside a V3 composite application is not expected to the contain jbi.xml that marks it as a Java EE SE deployment||P1||-|
|5||Fuji container should leverage @Resource and register endpoints for Jersey jars||P1||Need to get more details from Andi|
|6||All V2 open-esb admin cli commands will be supported in V3||P0||-|
|7||Monitoring support will be provided || P0|| Yoke and team are working on this|
|8||Admin Console integration will be provided||P0|| Gopalan's team is working on this|
|9||Configuration support integration with V3||P0||Configuration support in plain FujiFelix has to be defined first|
Fuji Sniffer and Container
- A GlassFish V3 sniffer will be developed in Project Fuji to detect any Fuji artifacts that are being deployed into the system using the standard GlassFish deployment mechanisms.
- This sniffer will be in the look out for META-INF/jbi.xml file in the incoming artifacts and map them to the Fuji container.
- A Glassfish V3 container will be developed in Project Fuji to handle deployments of Fuji artifacts. This container will be based on V3 OSGiContainer and will install components and applications as bundles.
- Fuji GlassFish container will have a dependency declared to the Fuji framework bundle to make sure this bundle is started and available when an Fuji artifact is deployed.
Fuji Composite Sniffer and Composite Container
- V2 applications: CompositeApplication.zip = (1...n) serviceunit.jar + (1...n) ejbmodule.jar + (1...n) application.ear
- V3 applications: CompositeApplication.zip = (1...n) serviceunit.jar + (1...n) application.ear + (1...n) jersey.jar + (1...n) ruby.jar + ...
- The service assembly zip may contain jbi.xml that has information about connections between service units.
- The service assembly jbi.xml does not have information about the ear, ejbs or other jars in jbi.xml.
- A first level Container, FujiCompositeContainer will be available to look out for incoming JBI composite applications.
- This container will have a composite archive handler that handles the EARs, WARs and service units in the composite application.
- All identified service units are separated and a new archive is created and handed off as a deployment to the simple FujiContainer described above.
- Any other archive inside the applications is handed off to interested archive handler and deployer. This way we cover deployments targeted at any GlassFish container.
- For EARs, the composite container has special handling to invoke a new deployment command. TODO: Need a way to tie in the composite application with the EAR in the application registry.
Implementation Details - Handling Service Assembly deployment
Option C has been implemented.
- Option A: Install the entire SA as a bundle using FujiDeployer and call back using V3 apis to handle ear/ejb jars. We are not considering this because this would add V3 specific code in Fuji framework and handling all possible application types will become cumbersome.
- Option B: Have a CompositeArchive Handler explode the SA zip and pass on the ears and ejb jars to interested parties and install each service unit as independent bundle. We may not be able to consider this because we would lose the service assembly level connections information in jbi.xml and this model would deviate from how the service assemblies are handled in plain Felix.
- Option C: Have a CompositeArchiveHandler explode the SA zip. When a sub-archive does not have a jbi.xml, call all interested sniffers/handlers/containers and hand over the deployment. Create a new sub-archive that has the Service Assembly jbi.xml and all service units and hand it off to Fuji Deployer.
The Fuji container bundle will add new services for each new asadmin command it wants to add to V3. Some of these commands may include listing binding components, service engines, service assemblies and also life cycle commands for components and applications. Configuration and monitoring features may add more commands to this list.
- Fuji GF Container will be developed as a self contained HK2 module.
- Fuji framework will not need any V3 specific changes. As the framework is implementing OSGi extender pattern, the bundle events will be handles automatically.
- Fuji GF Container and Fuji Framework and its dependencies are available as a separate distribution.
jar xvf fuji-gf-container-1.0-M7-SNAPSHOT.jar
- Fuji GF Container and Fuji Framework and its dependencies will be available as an update center module.
- Top level feature issue - https://open-esb.dev.java.net/issues/show_bug.cgi?id=970
- Fuji container - https://open-esb.dev.java.net/issues/show_bug.cgi?id=1431
- IPS image for Fuji container - https://open-esb.dev.java.net/issues/show_bug.cgi?id=1839
- CLI integration - https://open-esb.dev.java.net/issues/show_bug.cgi?id=1870
Blocking issues in V3
- Issue 8126 - Container services not discovered dynamically. This has been marked as RFE and will be fixed post v3.
- Phase 1: M8 deliverable - Fuji Composite Container should installation of JBI components and deployment of V2 applications (with Java EE SU) and V3 applications.
- Phase 2: M9 deliverable - Handle EAR, WAR inside a composite application.
- Phase 3: M9 deliverable - Enhancements for Java EE deployments in V3.
- Phase 4: M9 deliverable - Admin CLI support.
- Phase 5: M10 deliverable - @Resource handling and registering endpoints from container itself.
- Phase 6: M10 deliverable - IPS image for the container and upgrade tool integration. Replace fujiglassfish distribution with fuji-gf-container.
Java EE Service engine applications that were created for Open ESB V2 will continue to work in Open ESB v3. In addition to that enhancements will be made to make the experience more user friendly.
How it works in V2
- A web service is packaged as a war with a special marker file - jbi.xml. E.g., the jbi.xml has the provides element
<provides interface-name="tns:AddNumberServiceInterface" service-name="tns:AddNumberService" endpoint-name="AddNumberPort"/>
- This war is in turn embedded in a composite application and the was is specified as a service unit for sun-javaee-engine like this
- JBI runtime handles the deployment of the composite application zip. The war file is handed off to the Java EE Service Engine.
- Java EE Service Engine accepts the war file and calls the GlassFish deployment facility to deploy the war file and the web service.
- In addition, Java EE Service Engine scans the war and activates the endpoints provided in jbi.xml of the war file.
- Also a dummy composite application that contains a dummy service unit with a marker jbi.xml is deployed. This jbi.xml contains consumes element for the same service activated before, like this
<consumes interface-name="tns:AddNumberServiceInterface" service-name="tns:AddNumberService" endpoint-name="AddNumberPort"/>
- When the dummy application is deployed, Java EE Service engine scans it and activates the endpoints specified in the dummy service unit jbi.xml.
- A EJB module/web service module is created first.
- A composite application project is created and the module created in the the previous step is added to it.
Enhancements for V3
Questions / Open issues:
Fuji GlassFish container supports installation of JBI components, deployment of V3 applications and V2 applications (with Java EE Service Units).
Setup JBI container
- Download and install GlassFish from here.
- Go to AS_INSTALL_ROOT, e.g., /test/glassfishv3/glassfish
- Download the Fuji container for GlassFish from here
- In AS_INSTALL_ROOT, do jar xvf fuji-gf-container-1.0-M8-SNAPSHOT.jar
- Start the domain domain1. Note: the domain has to be started, stopped and started again due to GlassFish issue 8911
Install a JBI component
- Go to AS_INSTALL/bin.
- asadmin deploy component.jar
Deploy a V3 Service Assembly bundle
Deploy a V2 application with a Java EE SE service unit
The following issues have to be completed for Fuji integration with GlassFish V3.
Issue 1870 - https://open-esb.dev.java.net/issues/show_bug.cgi?id=1870
asadmin install and deploy commands are working as documented in M8 deliverable tab. Special commands have to be added to extend asadmin command set.
When Fuji supports more CLI commands for configuration, monitoring and such, equivalent commands will be added using the same mechanism.
about issues in-progress
The following issues are in progress.
Issue 2112 - https://open-esb.dev.java.net/issues/show_bug.cgi?id=2112