Contents

Introduction

This page contains information about implementing JEE 5 support in WTP. JEE 5 support is one of the primary tasks in WTP 2.0 release see [1]. If you are interested in JEE 5 support and have questions, comments, etc., about implementation, send a note to the WTP Dev List or contact me, Naci Dai.

The following summary is provided by Chuck Bridgham, Neil Hauge and other in wtp-dev list and describes our current understanding of how we will approach the implementation.

Meetings

Java EE 5 working groups meets regularly. The working group is a gathering of the WTP committers and contributors who work on the support for JEE 5. Occasionally we expect to have other guests, but we intend to limit the discussion to this group. We keep the minutes of these meetings here.

Use Cases

TheWTP JEE5 Test Scenarios are created to test the basic functionality that we would expect from WTP 2.0 to support JEE5. Please note that NO wizards are used other than the ones needed to create the servers, projects and add the necessary facets to these projects. The idea is if we are provided with valid JEE5 module and components (such as EJBs, JPA, Servlets, JSPs, etc), WTP 2.0 should support it. This includes Web, EJB, and EAR and Run As> Run on Server support. Of course this involves basic models for deployment descriptors (sans Annotation injections). Annotation support will only include that provided by JDT.

JEE 5 Support

This is not a plan for WTP but a restatement of what complete JEE 5 support means for WTP. Java EE 5 focuses on making development easier. JEE5 includes all JEE 1.4 features and improves them. This is accomplished by improvements in Web Services, Web Application, Enterprise Application and Management areas. Specifically:

Web Services API Based on JSR 109. Axis2 is being integrated into WTP. It is expected to provide some of the following items. For Axis2 integration notes see: [2]

Folks could misconstrue this as a claim that WTP 2.0 will support these JSRs.
At current course & speed, it won't (except for JAX-RPC 1.1 which we support already).
When Arthur wrote that Axis2 supports "many new Web services standards", this is a
reference primarily to XML / WS-* standards, not Java standards (JSRs). This is one of
the key architectural differences between Axis2 and Axis 1.x. Unlike Axis 1.x which was
designed with JAX-RPC support in mind, Axis2 [2] was architected to have its own Java API for
clients and services. At least in part, this was done to avoid giving preferential treatment
to any one particular standard Web service API, such as JAX-RPC (JSR 101),
Java WS Metadata (JSR-181), or JAX-WS (JSR 224 + JSR-181 + JSR 222). Axis2 has been further
architected to allow extenders to plug "modules" into Axis' pipeline to provide new qualities
of service and/or Java API. There is a proposal in the works [3] to provide a module that
supports the JAX-WS, Java Metadata and JAX-B (JSR-222) standards, however, this has not blossomed
into an Apache project yet, and is not in scope for our first kick at Axis2 in Eclipse WTP 2.0.
As for JSR-109, Axis2 mentions it as an area of interest, but I'm not aware of any proposal or
project to deliver a JSR-109 module.
On a related note, Axis2 isn't the only Web service runtime that could be integrated
into WTP. Glassfish [4] and CeltiXFire or CXF [5] (incubating) both target JAX-WS and are also
compelling candidates for the development of WTP Web service tools. I haven't even attempted to
size the effort to support either of those critters.
As a bit of a summary, Apache Axis2 is not expected to provide support for the JSRs above.
Associated Apache projects - hopefully at least one resulting from the Axis2 JAX-WS proposal -
will handle that sort of thing. For WTP 2.0, our intended tools for Axis2 are exactly that - for Axis2
- not for the JSRs. Any meaningful support for JAX-WS in WTP must be backed by at least one JAX-WS savvy
Web service runtime, and the Axis2 family of projects isn't there yet. Glassfish [5] and CeltiXFire (CXF)
[5] both target JAX-WS and are therefore deserving of further investigation. I haven't even attempted
to size any kind of development effort around those puppies yet.
Sorry if I'm rambled a bit here... Just wanted to get some thoughts out there.
1 JEE 5 Support
2 Axis2 [3]
3 JAX-WS Proposal [4]
4 Glassfish [5]
5 CeltiXfireProposal [6]

Notes from Tim deBoer for Server Support (JEE 5)

JMX is independent from JEE5. For JMX we've had a few people interested in creating a generic
JMX utility, but no one was entirely sure it would be reusable for different servers nor
interested enough to contribute resource. It remains on the back-burner since there has
been little interest.
For EE5, I've identified the core changes that I need to make for server tools.
These are minimal, and I'll include them whenever other teams start moving up to EE5.
The next most obvious thing is server adapters that support EE5. AFAIK, none
of the existing servers we support will be adding EE5 support in a fixpack, so that
means we'll have to add new server adapters, or convince external server adopters to
step up. I don't know if Gorkem can handle additional server adapters, but Tomcat v6
is a definite possibility if we can find some concrete release plans (although if I
can't find them now, they may not be releasing early enough in our schedule). Either
way, I think we'll be able to find some external adopters (e.g. Geronimo) who are
anxious to add support.
Recent update: All EE5 changes to server tools complete; new server adapter for Tomcat v6 integrated.

JEE 5 Models

We will create a separate package for these JEE 5 models. However, these packages must extend the existing J2EE models [7] for a few reasons:

EE5 namespace includes legacy J2EE elements. The new EE5 namespace includes the existing 1.4 elements, we can take advantage of the existing models/EMF-DOM XML translators.

Extending the existing J2EE model will help migration scenarios.

With the introduction of annotations, the new extended model classes can be adapted using a "new" mapping framework between a annotated JDT AST model (Not JEM).

XML Translator Framework

The existing J2EE models were originally modeled from the J2EE 1.2 version of the spec (DTD's) using the Rose2Ecore transformation tools. These models were evolved as new spec versions were published, being careful that they were backward compatible, and using the XML translators to "select" the attributes used by each spec version. The XML translator framework has its limitations, and isn't well documented, but it provides a bridge between EMF and different XML models/parsing technologies. Another short coming is that it will built to handle annotation mapping.

The Translator model allows the EMF models to be updated during the editing of in the XML documents (i.e. SSE XML editor). This is critical for implementing high quality tools and editors as the model is always in sync.

JEM and JEE 5 Annotations

Dali has implemented support for relevant portions of the JEE 5 spec using the above techniques. Therefore it provides a prototype for the JEE 5 support. Adapting their EMF model with the JDT AST model, and refactoring out a mapping layer similar to the translator framework, adopters could then publish their own annotation processing layer. WTP could create a reference implementation of this. The XML and annotation models don't match in all cases, and separate mappings will be required
to keep a common EMF model in synch.

There is general agreement that JEM is not the direction we want to take for modeling annotations. JEM project has not committed for making these enhancements. JEM support would be extremely helpful.

The Java EE annotation classes provide a model, and JEE 5 models in WTP should make an effort to use them not replicate when its possible.

Creating a model around the JDT AST makes the most sense. We also need to do more research regrading the APT api's. There is a general lack of model support for annotations in Eclipse. There are some basic issues in the JDT core that have been around for a long time that make things difficult with regard to annotation support. [8]. This bug requests basic support for annotations in the Java model. This is really where support for annotations should begin. In Dali there is a "util.jdt" with AST and JDT to support annotation configuration. Even at the AST level, annotations are not represented as a first class element, [9]. The JDT team is now actively looking at these issues. Once (and if) they are resolved, it would seem reasonable to take the next step to including specific API's for managing annotations and their complexity.

APT APIs

More feedback is needed here

Facets

Most existing WTP tools such as EJBs, Web Services can be extended for JEE 5 support. Th proper mechanism to enable such extensions is likely to be addition of new project facets. Tools will have to introspect projects for JEE5 facets and needs to take proper actions (i.e. add proper deployment descriptors, annotations, etc.). It makes sense to define a standard set of JEE 5 facets and hierarchy so that such tools can be implemented.

JEE 5 Focus Workgroup

A focus group will be setup to oversee the implementation of JEE 5 support. Here is suggested list of participants.

Chuck Bridgham - As the Component and Tech Lead for the EE5 Models

Neil Hauge - Mapping Annotations

Kaloyan Raev - Adopter/Contributor

And other interested parties.....

We will discus the contents of this page as the agenda of the first meeting.