Index Changes
This is version 60. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

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.


1All v2 applications should deploy and run in V3 without changesP0-
2Fuji framework code should not contain GF V3 specific codeP0-
3V3 should support composite applications that contain EAR, WAR, EJB jar, Jersey Jar etcP0-
4EAR, WAR inside a V3 composite application is not expected to the contain jbi.xml that marks it as a Java EE SE deploymentP1-
5Fuji container should leverage @Resource and register endpoints for Jersey jarsP1Need to get more details from Andi
6All V2 open-esb admin cli commands will be supported in V3P0-
7Monitoring support will be provided P0 Yoke and team are working on this
8Admin Console integration will be providedP0 Gopalan's team is working on this
9Configuration support integration with V3P0Configuration 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: = (1...n) serviceunit.jar + (1...n) ejbmodule.jar + (1...n) application.ear
  • V3 applications: = (1...n) serviceunit.jar + (1...n) application.ear + (1...n) jersey.jar + (1...n) ruby.jar + ...
  • Assumptions:
    • 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.

  • Options:
    • 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.

Imported interfaces

Exported interfaces

CLI integration

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.
cd $gf-root
jar xvf fuji-gf-container-1.0-M7-SNAPSHOT.jar

Update tool

  • Fuji GF Container and Fuji Framework and its dependencies will be available as an update center module.

Issues addressed:

  • Top level feature issue -
  • Fuji container -

Issues pending:

  • IPS image for Fuji container -
  • CLI integration -

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

Run time

  • 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.

Design time

  • 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

Design time

Run time

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 were addressed during M9

1. Fixed issue 2234 - fuji-glassfish container causes deployment failure of plain ejb-webservice
2. Fixed issue 2235 - asadmin deploy for assembly with http-bc service unit, dosent start it
3. Fixed issue 2350 - Fuji container bundle should be moved to modules/autostart
4. Write up for issue 2111 - Research on handling Java EE deployments without descriptor jbi.xml
5. Worked on issue 2112 - handle deployments of SAs with EARs inside

of issues to-do

The following issues have to be completed for Fuji integration with GlassFish V3.

Issue 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 -

JSPWiki v2.4.100
« Home Index Changes Prefs
This particular version was published on 04-Nov-09 06:32 AM, -0800 by Annies Abduljaffar