Fuji GlassFish V3 Integration
Overview
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.
Requirements
| No. | Requirement | Priority | Comments |
|---|
| 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 + ...
- 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.
Packaging
- 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.
Download:
http://download.java.net/maven/open-esb/fuji/fuji-gf-container/1.0-M7-SNAPSHOT/fuji-gf-container-1.0-M7-SNAPSHOT.jar
Usage:
cd $gf-root
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.
Issues addressed:
- 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
Issues pending:
- 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.
Schedule
- 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.
Overview
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
...
<target>
<artifacts-zip>calc-web-client-web.war</artifacts-zip>
<component-name>sun-javaee-engine</component-name>
</target>
- 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 Build 61 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
Example:
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.
1. Issue 1870 - CLI commands
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.
2. Issue 2111 - Issue Java EE SE integration
https://open-esb.dev.java.net/issues/show_bug.cgi?id=1870
Design and implementation of how to handle Java EE services in V3. Current support is documented in this wiki in section JavaEEServiceEngine.
3. Errors in latest GlassFish builds during component start-up
This does not have a corresponding issue. There are some errors at Fuji framework start-up while trying to update logger configuration. While this is not specific to the container and should be seen in FujiGlassFish distribution also, this needs to be investigated. Mismatch in Felix version or API changes could be a potential cause.
[#|2009-10-18T21:30:56.956-0700|SEVERE|glassfish|null|_ThreadID=28;_ThreadName=Thread-3;|*ERROR* [org.osgi.service.cm.ManagedService, id=33, bundle=211]: Unexpected problem updating Configuration PID=fuji-configuration.component-logger.sun-file-binding, factoryPID=null, bundleLocation=/Users/annies/b66/glassfishv3/glassfish/modules/autostart/jbi-framework.jar|#]
[#|2009-10-18T21:30:56.956-0700|SEVERE|glassfish|null|_ThreadID=28;_ThreadName=Thread-3;|java.lang.ClassCastException: java.util.ArrayList cannot be cast to java.util.Vector|#]
[#|2009-10-18T21:30:56.956-0700|SEVERE|glassfish|null|_ThreadID=28;_ThreadName=Thread-3;| at com.sun.jbi.logging.LoggerConfigurationService.updated(LoggerConfigurationService.java:156)|#]
[#|2009-10-18T21:30:56.957-0700|SEVERE|glassfish|null|_ThreadID=28;_ThreadName=Thread-3;| at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1389)|#]
[#|2009-10-18T21:30:56.957-0700|SEVERE|glassfish|null|_ThreadID=28;_ThreadName=Thread-3;| at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)|#]
4. Streamline the packaging
Fuji container's source is in FUJI-ROOT/core/glassfish and the packaging code is in FUJI-ROOT/packaging/release-packages/fuji-gf-container. At some point the packaging has to be modified to include CLI extensions also.
Another packaging module has to be added to repackage the container as an IPS package. After that is made available, the primary way to install Fuji over GlassFish should be installing glassfish and getting the container from the update center. This would mean periodic updating of the container image in the update center repository and establishing a verification test setup before doing the same.
After the above mentioned steps have been accomplished, FujiGlassFish distribution should be phased out. It was put together as a stop-gap measure and the idea of overwriting GlassFish's config.properties with our own version would not scale. For the production/final release there may be another installer needed that could simulate the steps of a plain GlassFish install followed by obtaining and installing the container from the update center.
5. Issue 970
This is the top level issue for V3 integration and for developer release should be resolved when the above mentioned issues and the issues in the In-Progress section are resolved. There may be needs to add some additional items to this to make the work complete for production release. These items may be related to configuration and monitoring and not enough details are available now. Some requirements are in this wiki at the Requirements table.
1. Issue 2112:
Issue 2112 - https://open-esb.dev.java.net/issues/show_bug.cgi?id=2112.
FujiContainer processes the incoming service assembly by parsing the archive and creating a separate, new module for the service assembly that contains the archives with jbi.xml.
Any other archive that is present is not processed for now. The plan is to be able to deploy even a generic war file or ear file without any JBI specific information.
The handling will be very similar to the way GlassFish's EARHandler handles the archives. As the FujiCompositeArchive handler is based on the same the support is built-in.
But this needs verification and some changes.
ModuleDeploymentContexts:
In the current Fuji container, extended deployment context instances are being created in FujiCompositeDeployer and FujiCompositeArchiveHandler (as Anonymous Inner Classes). The information that we store in one deployment
context, module-name, was lost while the OSGi Container trying to retrieve it it is dealing with another instance of the ExtendedDeploymentContext. This is the reason behind the deployment errors that go like this
NullPointerException at creating RefCountingClassLoader at OSGiDeployer.load()
As a fix for this, we have the following hack in FujiCompositeDeployer.
moduleContext.getAppProps().put("module-name", FileUtils.makeFriendlyFilename(application.getName())+"-container-created-sa");.
This would not work for the following cases - when the manifest of the incoming service assembly contains bundle headers(in which case the module name is the bundle name and not the default application-name-container-created-sa) and in cases where the incoming archive has other archives like war and ear. The fix is to use the newly added API in glassfish to save the module specific extended deployment context like this.
Index: container/src/main/java/com/sun/jbi/glassfish/container/composite/FujiCompositeArchiveHandler.java
@@ -375,6 +372,9 @@
subArchive.setParentArchive(context.getSource());
ClassLoader subCl = handler.getClassLoader(cloader, subContext);
//cloader.addModuleClassLoader(moduleURI, subCl);
+
+ ((ExtendedDeploymentContext)context).getModuleDeploymentContexts().put(moduleURI, subContext);
+
Also this fix is needed for FujiCompositeArchiveHandler
--- container/src/main/java/com/sun/jbi/glassfish/container/composite/FujiCompositeArchiveHandler.java (revision 1119)
+++ container/src/main/java/com/sun/jbi/glassfish/container/composite/FujiCompositeArchiveHandler.java (working copy)
@@ -222,9 +222,7 @@
subArchive = source.getSubArchive(moduleUri);
ArchiveHandler subHandler = deployment.getArchiveHandler(subArchive);
if (subHandler!=null) {
- subTarget = target.createSubArchive(
- //FileUtils.makeFriendlyFilename(subArchive.getName()));
- subArchive.getName());
+ subTarget = target.createSubArchive(FileUtils.makeFriendlyFilename(moduleUri));
subHandler.expand(subArchive, subTarget, context);
And the ExtendedDeploymentContext has to be retrieved from FujiCompositeDeployer instead of creating a new one.
Index: container/src/main/java/com/sun/jbi/glassfish/container/composite/FujiCompositeDeployer.java
===================================================================
--- container/src/main/java/com/sun/jbi/glassfish/container/composite/FujiCompositeDeployer.java (revision 1119)
+++ container/src/main/java/com/sun/jbi/glassfish/container/composite/FujiCompositeDeployer.java (working copy)
@@ -360,6 +360,7 @@
ExtendedDeploymentContext moduleContext = ((ExtendedDeploymentContext)context).getModuleDeploymentContexts().get(moduleUri);
if (moduleContext != null) {
//This is where I return the existing deployment context and not create a new one
return moduleContext;
}
Sample applications for testing.
"Add any Netbeans Ear project with JAX-WS WS to Composite Application project and use. Also if you have Java CAPS installed you can even add Deployment Profile to Composite Application project. Second variety is actually called "JBI Bridge". Mark White and Girish Patil have some sample applications for testing.
2. Issue 1839:
https://open-esb.dev.java.net/issues/show_bug.cgi?id=1839
All blocking issues have been resolved. The container services are discovered at start-up after the changes to the layout as done in fix for issue 2350. This makes the job of packaging the container simple.
There are some details about how to handle the packaging, in this thread - http://markmail.org/message/3t4foxg53x2f74as
![[RSS]](http://wiki.open-esb.java.net/images/xml.png)
