The Java EE 6 web profile is a specified minimal configuration targeted for small footprint servers that support "typical" web applications. The Web profile is a minimal specification, so an implementation is free to add additional services or allow applications to provision additional services. The required elements of the web profile are:
Details on the current state of each of these is traced below. Geronimo is already at the current level for some of these components, for others we'll need to located updated versions. Hopefully, this will be just new releases of components we already use, but this might also require developing some elements directly as part of Geronimo.
In addition, the Geronimo spec tree contains versions of the API classes for these different interfaces, so we will probably need to develop new versions of the API classes.
As a first step in developing these, we might want to create a plugin group that is an embodiment of the web profile using the Java EE 5 components currently in Geronimo. This will give use a platform for experimenting with how to configure the server for the smaller footprint and how to allow additional services to be added to the mimimal profile configuration. Also, as Java EE 6 compatible implementations become available, we can create additional plugins that allow the newer versions to be swapped in to the configurations.
The current known state for each of these components in Geronimo is detailed here. Feel free to update this information as new details emerge.
New "java:global", "java:app", and "java:module" namespaces will be required for all profiles of Java EE 6. As well @Resource and @EJB have been updated to have a new "lookup" attribute.
Names definable via annotation or in deployment descriptor (application, application-client, web, ejb-jar)
Proposed Final Draft
Can also be done via xml in deployment descriptor (application, application-client, web, ejb-jar)
See related section under EJB 3.1
Servlet 3.0 - geronimo-servlet_3.0_spec-1.0-EA-SNAPSHOT
The servlet container can be either Tomcat 7 or Jetty 8? The Tomcat artifact Geronimo uses contains patches applied on top of the Tomcat version.
According to the summary presented here:
The Tomcat plan is for a 7.0.x release that supports the Servlet 3.0 specification to be available as soon as the Servlet 3.0 spec finalizes. This chart has an interesting note that this will support JSP 2.1 because there is no JSP 2.2.
For Jetty, there is a similar project plan for an 8.0.x version also planned at the time Servlet 3.0 goes final.
Unknown. In the Tomcat community, this appears to have been discussed, but is not really under active development. The Jetty community seems to be tracking the Servlet 3.0 activity a little more closely, but I've not found any projections for availability.
Geronimo trunk is currently building with snapshot versions of both projects, but there are some issues that are being worked.
JSP 2.1 - geronimo-jsp_2.1-MR2_spec-1.0-SNAPSHOT
Geronimo is currently relying on Jasper for the JSP implementation on Tomcat. I'm not sure I understand what the Jetty story is on this.
I've not been able to locate many signs of activity on this.
There's something bizarre going on with this spec and the Expression Language one. The Tomcat release plan indicates there is no JSP 2.2 version. There don't appear to be any JSP 2.2 specifications that can be located, and there are no JSRs at the Sun Java web site related to a JSP 2.2 release. The only references I've managed to find have been a couple of indicators that Glassfish is supporting JSP 2.2, but there don't appear to be any details on what this actually is.
New information has emerged on this spec. There is no JSP 2.2 or EL 2.2 specification. This is, however, a maintenance release of the JSR 245 Specification that contains some minor enhancements to both the JSR 2.1 spec and the EL Information about the proposed changes can be found here.
EL 1.0 - geronimo-el_1.0_spec-1.0.1
There don't appear to be any spec changes required for JEE6.
This is provided by the JSP provider, so they're fairly tightly coupled.
This tends to be tightly coupled with the JSP providers, do it's difficult to say what the story is.
The spec version appears to be a bit of a muddle. The spec jar is getting built claiming it is 1.0, but the latest version defined in the Web Profile appears to be in lock-step with the JSP version numbers. It's not clear what version we are actually at currently, but it is possible that there have not been any API changes in this area since the 1.0 version.
It appears that the Web Profile specification has an error in the version number. There is no Expression Language 2.2 specification. However, the JSR 245 Maintenance Release includes some minor updates to the EL specification. These updates are not broken out into a separate spec, but are included under the umbrella of the updated JSP 2.1 spec.
No spec apis needed.
This is really JSP debugging support, and is implemented by the JSP provider. We're currently getting this from Jasper.
Nothing new for Java EE 6 in this area.
None - We use Sun RI (jstl-1.2.jar)
Sun RI at the 1.2 level
Essentially complete because the RI is getting used.
None. We use org.apache.myfaces.core.myfaces-api-2.0.0-SNAPSHOT.jar.
MyFaces 2.0.2, which is at a JSF 2.0 level.
JSF 2.0 is being worked on by the MyFaces community. An initial 2.0.0-SNAPSHOT release is available - http://myfaces.apache.org/download.html, which the version currently used by the Geronimo trunk.
A 1.1 version of the annotations is available, but not currently being used within the Geronimo trunk build.
This is really just a set of annotations classes that can be shared across different Java EE components.
Like the web profile itself, this appears to describe a minimal feature set, but an implementation can provide more than the minimum, if desired. This appears fairly easy to meet, once the 3.1 feature set is implemented. Portions of the 3.1 features have already been implemented in OpenEJB.
The major EJB 3.1 features yet to be completed in OpenEJB are async interfaces, schedule based timers and the no-interface view. Of the three, only the no-interface view is required for EJB Lite. Several updates are required for changes to the EJB 3.1 spec in the last few months mostly around deployment descriptor, additional annotations, Singleton bean lifecycle tweaks and support of the official javax.ejb.embedded.EJBContainer API based on the existing OpenEJB InitialContext/embedded API. Rough estimate of the time required to complete the no-interface view and updates required for the EJB Lite profile are 2-3 weeks and 4-6 weeks respectively. Rough estimate on async invocations/interfaces is 3-5 weeks and schedule based timer support 4-?. The schedule based timer support is the largest undertaking, based on de facto standards like Cron and Quartz, but different enough that it is not possible to use any existing library as-is. Actual completion dates depend on time spent in other priorities.
A major new Java EE 6/EJB/Servlet feature to be completed in Geronimo is the ability to include EJBs in .war files which required as part of the Java EE 6 Web Profile. Any EJBs in the webapp share the classloader of the webapp and the java:comp/env namespace of the webapp. The Geronimo deployment process will also need to be updated to treat all webapps as potential sources for EJBs to support this feature. Rough estimate is 3-4 weeks of likely both David Blevins' and David Jencks' time.
The embedded version of OpenEJB is capable of handling a dynamic provisioning of the different subsystems from the Lite profile version up to the full capability (minus the CORBA integration, which is handled by Geronimo). It appears there will be some work required on the part of Geronimo to create profiles/plugins that will selectively start the GBeans that integrate different portions of the OpenEJB stack with the configuration. Currently, the Geronimo EJB configuration is an all-or-nothing proposition.
EJB 3.1 API libraries currently being developed in asf/openejb/trunk/openejb3/api/ejb31-api-experimental/ with plans to move it to asf/geronimo/specs/trunk/geronimo-ejb_3.1_spec once the specification closes. Current close date is slated for some time in September 2009.
Implemented by Geronimo directly.
No revisions required for Java EE 6,
The 2.0 version is actively being developed by the OpenJPA community and the current version has already been integrated into Geronimo.
This is a new JEE 6 component, so there is no current provider.
JSR 330 is a proper subset of the JSR 299 spec definition, so no additional provider work is required beyond what is already being done to implement JSR 299 and to provide the spec jar file.
The spec version for this is available as geronimo-cdi_1.0_spec-1.0-SNAPSHOT
This is a new JEE 6 component, so there is no current provider.
The openwebbeans project is working on implementing this component and is already working with the Geronimo and OpenEJB communties to work on the integration issues. There's no defined completion target here.
A potential fallback might be to use the RI version, which has an ASL license. However, there would still be sigificant integration work required for using this alternate version. The amount has not be investigated yet, but it is assumed to be similar in extent to the openwebbeans effort + the additonal effort required to research how the integration needs to be accomplished.
New component in JEE6, so there is no existing component.
There have been numerous discussions about creating an Apache project for implementing a Bean Validation component, but none of these proposals have managed to get off the ground as yet. Currently, using the reference implementation (which carries an ASL2 license) is looking like the most viable alternative.
This work effort is completely contained within the OpenEJB project.