J2EESupport
Launchpad Entry: j2ee
Created:
Contributors:
Packages affected:
Summary
To further meet enterprise users needs, Ubuntu server needs to provide a Java application server stack that could scale up to a full J2EE ("Java EE") stack. This spec evaluates the different implementation options.
Release Note
Ubuntu server now features a complete, performant 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 MadeUpCorp, a company developing Java components that are used as middleware in Java application server. He wants to provide an easy way for customers to demo and evaluate MadeUpCorp 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, performant, supported and Java-EE-certified stack. After careful testing, she picks up Ubuntu Server as the best tool for the job.
Assumptions
Design
You can have subsections that better describe specific parts of the issue.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
UI Changes
Code Changes
Migration
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release.
This need not be added or completed until the specification is nearing beta.
Outstanding Issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Several implementation options were discussed and evaluated:
Tomcat 5.5
Type : |
Servlet container |
License : |
Apache License v 2.0 |
Builds from source : |
Yes |
Packaged : |
Yes (5.5.25 in Universe) |
Maintainability : |
Good |
Compatibility : |
Servlet/JSP 2.4/2.0 |
Current version : |
5.5.26 |
Link : |
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
Type : |
Servlet container |
License : |
Apache License v 2.0 |
Builds from source : |
Yes, with openjdk (not with gcj -- missing J2SE 1.5 Socket.setPerformancePreferences methods) |
Packaged : |
No (but not too complicated) |
Maintainability : |
Good |
Compatibility : |
Servlet/JSP : 2.5/2.1 |
Current version : |
6.0.16 |
Link : |
- 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
Type : |
Modular (Servlet container or J2EE application server, uses Tomcat or Jetty) |
License : |
Apache License v 2.0 |
Builds from source : |
Yes (with OpenJDK + patch from Geronimo), but pulls lots of deps that might not |
Packaged : |
No. See below for options |
Maintainability : |
Good, reactive upstream |
Compatibility : |
J2EE v5 since Geronimo 2.0.1 |
Current version : |
2.1.1 |
Link : |
- "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
Type : |
J2EE application server |
License : |
CDDLv1 + GPLv2 with exceptions (see [http://wiki.java.net/bin/view/Projects/GlassFishCodeDependencies here]) |
Builds from source : |
No (being worked on) |
Packaged : |
in Multiverse (V2 UR1) - builds from binaries |
Maintainability : |
Good support from Sun |
Compatibility : |
J2EE v5 |
Current version : |
V2 UR2 |
Link : |
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
Type : |
Modular (Servlet container or J2EE application server) |
License : |
CDDLv1 + GPLv2 with exceptions (see [https://glassfish.dev.java.net/downloads/v3/tp2-third-party-readme.txt here]) |
Builds from source : |
No |
Packaged : |
No (uses Maven) |
Maintainability : |
Good support from Sun |
Compatibility : |
J2EE v5 |
Current version : |
V3TP2 (incomplete : see http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3TP2Content ) |
Link : |
- 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 [http://people.ubuntu.com/~koon/gf3_external_deps.ods list])
- Using Maven pulls 82 more JARs (+34 slightly different versions) of which 17 are already packaged
JOnAS 4
Type : |
J2EE application server (uses Tomcat or Jetty) |
License : |
LGPL 2.1 |
Builds from source : |
see below |
Packaged : |
No |
Maintainability : |
Questionable |
Compatibility : |
J2EE v1.4 |
Current version : |
4.9.2 (released May 23, 2008) |
Link : |
- Twice a year, a new JOnAS release is delivered
- Can make use of pristine Tomcat 5.5 or Jetty 5.1
Looks less finished than Geronimo, more a research testbed than an enterprise-ready solution
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
Type : |
J2EE application server |
License : |
LGPL 2.1 |
Builds from source : |
? |
Packaged : |
No |
Maintainability : |
Questionable |
Compatibility : |
Release version 5.1 (Nov 08) targets J2EEv5 compliance |
Current version : |
5.0.3RC (no stable release yet) |
Link : |
- New architecture, OSGi based (like Glassfish v3)
- Can't make it start
NoClassDefFoundError: org/ow2/jonas/commands/admin/ClientAdmin
JBOSS AS 5
Type : |
J2EE application server |
License : |
LGPL |
Builds from source : |
see below |
Packaged : |
No (only JBoss Common in Universe) |
Maintainability : |
Questionable |
Compatibility : |
J2EE v1.5 |
Current version : |
5.0.0Beta4 |
Link : |
- Market leader for FOSS J2EE appservers
JBoss is now a dividison 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.
- "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
Type : |
Servlet container |
License : |
Apache 2.0 |
Builds from source : |
Yes |
Packaged : |
Yes, in Universe (5.1.14) |
Maintainability : |
Good upstream |
Compatibility : |
Servlet/JSP 2.4/2.0 |
Current version : |
5.1.14 |
Link : |
- More an integration component than a full-featured application server
- No admin UI
Jetty 6.1
Type : |
Servlet container |
License : |
Apache 2.0 |
Builds from source : |
See below |
Packaged : |
No. Maven pulls 94 jars, most of them are already packaged. |
Maintainability : |
Good upstream |
Compatibility : |
Servlet/JSP 2.5/2.1 |
Current version : |
6.1.10 |
Link : |
- 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
Type : |
Java/PHP application server |
License : |
GPL |
Builds from source : |
Where's the source ? |
Packaged : |
No |
Maintainability : |
Questionable |
Compatibility : |
No certification, but J2EEv5 features (Servlet 2.5 / JSP 2.1 / EJB 3.0) |
Current version : |
3.1.6 |
Link : |
- 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