JEE 5 Support
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 . 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.
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, bu we intend to limit the discussion to this group. We keep the [minutes of these meetings] here.
JEE 5 Support
This is not a plan for WTP but a restatemnt 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: 
- JSR-224 JAX-WS 2.0 JAXB 2 SAAJ 1.3
- JAX-RPC 1.1
- JSR 181 Web Services Metadata - Annotated Java classes for easy definition of web services
- Web Applications
- Servlet 2.5 (JSR 154)
- JSP 2.1 (JSR 245)
- JSTL (JSR 52)
- JSF 1.2
- Enterprise Applications
- JPA (JSR 220)
- JCA 1.5 (JSR 112)
- Management (Related to servers)
- J2EE Application Deployment (JSR 88)
- J2EE Management (JSR 77) Manage Web/Enterprise Applications on JEE 5 Servers
Notes from Chris Brealey about JEE 5 support for web services in WTP: 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  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  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  and CeltiXFire or CXF  (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  and CeltiXFire (CXF)  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. Once again, apologies for today's call. I'll make a point of dialing in next week.
JEE 5 Models
We will create a separate package for these JEE 5 models. However, these packages must extend the existing J2EE models  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. . 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, . 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.
More feedback is needed here
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.