Ubuntu Wiki

• Launchpad Entry: j2ee

• Created: 2008-05-28

• Contributors: ThierryCarrez

• Packages affected:

Summary

To further meet enterprise users needs, Ubuntu server must provide a Java application server stack that could scale up to a full J2EE ("Java EE") stack. There are several solutions, but at the moment they all require lots of packaging work to be done before starting packaging the Java EE server itself.

Release Note

Ubuntu server now features a complete, high-performance and modular Java EE server stack that you can use to deploy all your Java applications and web services.

Rationale

Java development (web applications, beans, web services...) is very common in the enterprise world. Ubuntu server currently doesn't provide an integrated Java EE server stack and it is up to the user to install manually a third-party application server, especially if they want to use more than just a servlet container. To make it easier for those users and increase Ubuntu server adoption in the enterprise world, we need to integrate and support a Java EE server stack in main.

Use Cases

Josh is a Java developer and wants to deploy his latest web applications on a test server to show his boss how well he did. He quickly sets up an Ubuntu machine and installs the web application server, without needing the bloat of a full Java EE stack.

A few month later, Josh migrated his web applications as web services. He can upgrade his test installation so that it now supports the required Java EE features.

Martin works at Made-up Co., a company developing Java components that are used as middleware in Java application servers. He wants to provide an easy way for customers to demonstrate and evaluate Made-up software. He decides to ship ready-to-run Ubuntu JEOS VMs including the Ubuntu Java EE server stack, integrated with their middleware software and demos.

Julia looks for the ideal deployment environment for her company web applications in production. She needs a scalable, high-performance, supported and Java-EE-certified stack. After careful testing, she picks up Ubuntu Server as the best tool for the job.

Design

Requirements

• Java EE 5 compatibility
• Modular system (scale from web container to full J2EE stack)
• Must build from source with reasonable additional dependencies to package ("main" target)

Potential choices

The complete list of candidates and feature matrix can be found in the "discussion" section below. The only solution available today that is both JavaEE5-compatible and modular is Geronimo. The other two possibilities are Glassfish v3 and JBoss 5, which are still work in progress.

Both Geronimo and Glassfish v3 are based on a next-generation OSGi architecture and gather momentum in the Open Source world. JBoss is a well-established FOSS solution which was always designed with modularity in mind. Geronimo is JavaEE5-compliant, Glassfish v3 will be JavaEE6-compliant, and JBoss 5 aims to get Java EE 5 compliance.

Geronimo is a lot more dependent on third-party dependencies and its build system is more complicated. Glassfish v3 has less dependencies, but is still at the early stages of development. A Glassfish v3 "Prelude" version should be ready for Intrepid. Both rely on maven to build, which in its current form cannot be used to build packages (it downloads dependencies and dependency tree information (.pom files) during the build). JBoss only uses ant, which makes it easier to build for package targets. However it also requires lots of dependencies to be packaged and included in repositories first.

The end result is that including a Java EE application server in Ubuntu is not a small task, and that a lot of prerequisite tools and dependencies must be packaged first. We should therefore target the application server that we think will be the best one in the future, not necessarily restricting the choice to what is ready for production today.

Proposed implementation

Geronimo or Glassfish v3 would be used as the Java EE stack for Ubuntu Server, provided the number of dependencies to package and include in "main" so that it can fully build from source is reasonable. In the mean time, we'll provide Tomcat 6 as a web container solution for Ubuntu (see Tomcat6StackSpec).

Go, no-go

A complete analysis of the dependencies we would have to package and include in "main" must be done before any work is started on the subject. This analysis would target Glassfish v3 "Prelude" first, but should also evaluate extra needs for the full Java EE version. Based on that analysis, a go / no-go decision will be taken, and targets and deadlines ("v3 Prelude for Intrepid" ?) will be set.

Platform needs

Maven needs to be supported as a build system for Ubuntu packages, potentially patching it so that it uses locally-installed packages and dependency info rather than downloading it from repositories. This is a platform task that affects lots of packages, and is the subject of the MavenSupportSpec.

Outstanding Issues

• Glassfish v3 "Prelude" edition is not a full Java EE stack.
• Glassfish v3 is recent code that might not be production-ready
• Can we easily get around the included "Update Center" features in GF to avoid the direct download of modules/plug-ins and use Ubuntu packages instead ?
• GUI is very Sun-branded and has elements (registration popups, ads for Glassfish training, copyright notice including IP and patent assertions) which look quite odd in an open source product

BoF agenda and discussion

Several implementation options were discussed and evaluated:

Tomcat 5.5

Current package problems :

• dependency on JRE (java2-runtime), should be on JDK (java2-compiler) (LP: #179447, #112626)
• file permissions incompatible with admin interface (LP: #234127, #220871)
• incompatibility with openjdk (LP: #229404, #212521)
• 5.5.26 needed to fix CVE-2007-5333 (LP: #220540, #228665)

Additional packages needed in main to build :

• libcommons-daemon-java
• libcommons-digester-java
• libcommons-el-java
• libcommons-fileupload-java
• libcommons-httpclient-java
• libcommons-launcher-java
• libcommons-modeler-java
• libstruts1.2-java

Tomcat 6

• Tomcat is now downstream of Glassfish, lost contributors from Sun.
• Used by developers and as a servlet container inside other products, rarely in production by itself.

Random packaging notes :

• Fix commons-daemon.home=${base.path} in build.properties

• Needs libecj-java as additional build dep + force jdt.jar=/usr/share/java/ecj.jar

• Needs to pull native connectors source as well and edit tomcat-native.tar.gz=...

• No need to copy all jars to lib/ at packaging time, use the depends ones

Geronimo

• "release often" (every 2-4 months)
• Right featureset/Ubuntu-style management options
• Modular design. Technologically on par with JBoss and Glassfish v+1.
• Good upstream maintenance relationship.
• Best admin UI : modular, professional-looking

Running Geronimo :

• Running instructions recommend Sun JDK >=1.5

• tomcat6-j2EE version does not run with OpenJDK-6

  • Invalid keystore format issue : http://pastebin.ca/1032465

  • Known issue in OpenJDK : http://www.nabble.com/OpenJDK---Glassfish-Client-td17512837.html

• jetty6-j2EE version runs with OpenJDK-6

Building Geronimo :

• Should be built as modular packages with a few metapackages (geronimo-miniG-tomcat, geronimo-J2EE-tomcat...)
• Building with gcj
  • Very (really) slow - aborted
• Building with OpenJDK-6
  • Need to override JDK version check in build.xml

  • Fails with org.apache.geronimo.axis2.pojo.POJOWebServiceContext is not abstract and does not override abstract method <T>getEndpointReference(java.lang.Class<T>,org.w3c.dom.Element...) in javax.xml.ws.WebServiceContext : JDK 1.6 incompatibility (new getEndpointReference abstract method in jax-ws)

  • Build instructions require Sun's JDK 1.5.

  • Geronimo team provided patch to build under 1.6 @ https://issues.apache.org/jira/browse/GERONIMO-4089

  • Very reactive help on FreeNode #geronimo, by Kevan Miller (kevan) and Jarek Gawor (jgawor)

  • Builds with MAVEN_OPTS="-Xmx768m -XX:MaxPermSize=256m" in ~/.mavenrc

  • Tests at the end of the build fail with loader constraint violation error : http://pastebin.ca/1032462

  • Runs OK, tests are OK when run separately

Packaging Geronimo :

• Geronimo uses all the features of Maven to pull as much external stuff as it can

• Must ensure we have source code for everything that is pulled, and that everything would be a main target

• Solution 1 : use maven to build
  • Might need to patch maven to support this mode
  • Package all required dependencies and maven plugins (462 jarfiles of which only 123 are already packaged)
  • Package all required dependencies of dependencies (if any)
  • Add all .pom files to the source
  • run "mvn -o" to force offline mode
  • might not work as maven wants multiple versions of the same jar
• Solution 2 : use ant to build, together with maven-ant-helper (current Debian way)
  • need to reinvent the build system and reimplement all required maven tasks (normally handled by plugins)
  • Package all required dependencies (393 jarfiles of which 123 are already packaged)
  • Package all required dependencies of dependencies (if any)
  • Figure out the best order in which to build
  • This should work, but lots of work to package initially and to maintain (to build something big that heavily relies on Maven to build, you basically have to create and maintain a Debianized mirror of the Maven artifact repositories).
• Geronimo ships with a few (20) slightly-modified third-party JAR files with a Maven hack to make sure those are picked instead of the regular ones that Maven would fetch. It is mostly Apache-projects packages for which Geronimo needs a patch that hasn't made it into a release. Geronimo doesn't provide the patchfiles used to build those (though in some cases you can find them in the third-party project bugzilla or VCS with minimal research).

GlassFish v2

Two sources in multiverse :

• glassfish (builds from source : glassfish-activation, glassfish-appserv, glassfish-jmac-api, glassfish-mail, glassfish-javaee, glassfish-toplink-essentials) : incomplete GlassFish with the build-from-source bits

• glassfishv2 (builds from binary blobs : glassfishv2-bin, glassfishv2, glassfishv2-doc) : complete GF by Sun

Running glassfishv2 :

• Install fails at configure glassfish-v2 : missing English.pm in @INC while running /usr/share/glassfishv2/config/install/install.pl (missing libtimedate-perl package in depends)
• Invalid keystore format running with OpenJDK-6 (same error as Glassfish), runs OK with Sun's JDK

• Good admin UI, but way too much Sun-branded

GlassFish v3

• Alpha code
• Only the framework and web container in V3TP2
• Build system :

  • 60 external JARs required to compile or at runtime, of which 6 are already in Main, 7 in Universe and 1 in Multiverse (see list)

  • Using Maven pulls 82 more JARs (+34 slightly different versions) of which 17 are already packaged

JOnAS 4

• Twice a year, a new JOnAS release is delivered
• Can make use of pristine Tomcat 5.5 or Jetty 5.1

Building JonAS4 :

• "Source" package includes 134 pre-built jars, difficult to tell if they all build from source
• Sources build with gcj

• Does not build using OpenJDK-6 (org.objectweb.jonas.dbm.JManagedConnection is not abstract and does not override abstract method...)

JOnAS 5

• New architecture, OSGi based (like Glassfish v3)
• The version 5.1 introduces some new innovative features:
  • Deployment Plans: XML files that describe a succession of resources (local or remote) that must be deployed in the given order. Support of three repository types: URL, Maven2 and OBR (OSGi Bundle Repository). Resources will downloaded if needed.
  • Services on demand: New mechanism allowing applications (aka Java EE archives) to describe which plan they need in order to run.
  • Versioning: Permits to deploy several versions of one application (V1,V2) in the same JOnAS node. Application upgrade is performed without interruption of service and without user session loss.

JBOSS AS 5

• Market leader for FOSS J2EE appservers

• JBoss is now a division of RedHat

• Admin UI makes use of Java applets, seems less accessible than Geronimo's one

Building JBOSS AS :

• JBOSS is currently being packaged for Debian. See http://packages.qa.debian.org/j/jbossas4.html.

• A working JPackage (still universe-style) exists for JBOSS. See http://www.jpackage.org/browser/rpm.php?jppversion=5.0&id=2457. A JPackage team is currently removing all non-free dependencies.

• "Source" package includes many pre-built jars. See build/build-thirdparty.xml in the source tarball for a complete list of SCM access/version details of thirdparty source code.
• In its current stable/beta versions JBoss contains many references to non-free packages or libraries not yet packaged on Debian/Ubuntu.
• JBOSS AS sources build OK without modification with Ant 1.6.5.
• JBOSS AS sources build OK with our current Ant (1.7) after patching tools/etc/buildmagic/buildmagic.ent to consider 1.7 a compatible version.

Jetty 5.1

• More an integration component than a full-featured application server
• No admin UI

Jetty 6.1

• More an integration component than a full-featured application server
• No admin UI

Building 6.1 from source :

• Does not build with gcj
• Uses maven + a cvs task at one point to pull even more
• Compilation fails with OpenJDK-6, complaining about Sun proprietary API and [that] may be removed in a future release

Resin 3.1 Open Source version

• Enterprise-ready version is "Resin Professional", not open source
• Difficulty to find anything on their website
• Need partnership with Caucho if we choose that option

CategorySpec