[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Java EE 5 models design overview

Hi Kaloyan,

>>May be a common package for annotation processing that is placed down in org.eclipse.jst will be of great benefit for many WTP components.

This is something that we and others have been interested in for quite some time.  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.  Starting at the beginning, take a look at bug 79112*.  This bug requests basic support for annotations in the Java model.  This is really where support for annotations should begin.  What we have created in our util.jdt package was necessary to dig into the AST and JDT to support annotation configuration.  As you have seen, even at the AST level, annotations are not represented as a first class element, as noted in bug 106108**.  As you can see from these entries, it is fairly difficult to manage annotations given the underlying model support.  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.  As a side note, please CC yourself/vote for these bugs.  The more organizations and projects that are pushing for annotation support, the better chance we have that something will get done.  Also, as you mentioned, JEM support would be extremely helpful, but I don't know how likely this is until the above issues are resolved.

You may want to look at what the APT team is doing as well for a more comprehensive view of what is happening regarding annotation support in the JDT core.  Enhancement 154110*** describes some of their future work.

>>Can you provide some overview what is covered by the Dali tools for annotations and xml descriptors processing?

Sure.  In our 0.5 stream, we have the ability to read and write a large number of JPA annotations with some configuration limitations. The focal point of our annotation management support consists of a collection of utility classes that generalize the effort of reading and writing annotations.  These utilities try to cover the reading and writing of all of the various forms that annotations may appear in (at least for JPA), isolating and hiding this complexity from our model.  Beyond this we have to manage annotation change from the editor and change from our UI.  We listen for changes and update our model based on changes to JPA annotations in the java source.  We also push changes to the source from our model by editing the AST via the utilities.

This general annotation support is currently being refactored to fill in some of the holes in our previous support, in addition to simplifying the code and the general process of working with the Java source. 

Our XML Descriptor processing is specific to the JPA XML Descriptor (orm.xml) and is fairly basic at this point.  We can read and write a small number of properties to the orm.xml but have been struggling with the complexities of the EMF to XML translation process.  We are using the EMF to XML Translator framework and have had some success with it, but have also had numerous setbacks.  It is a major learning process, and I can agree that it is not for the faint of heart, but it still would seem to provide many advantages over starting from scratch.  We are probably spending most of our time trying to make the Translator framework do what we need it to do at this point. 

I think a lot of this complexity has to do with the fact our project requirements involve a rich UI for editing these artifacts.  This is a new thing, since the artifacts for J2EE 1.4 support were all XML based, and were configured by the user via the generic WTP XML editor.  As a result, the existing WTP code doesn't solve a lot of the problems we are running into. 

Given our requirements, there are no easy answers when it comes to modeling and persisting JPA meta data.  The model for JPA annotations isn't the same as the model for the XML Descriptor.  Both artifacts are persisted via different mechanisms/frameworks.  The mechanisms being used for this purpose are both under development, and may not have been previously exposed to the demands of our requirements.

I think that the general process you describe for supporting the Java EE 5 models (option 2) is a good enough place to start.  You may find out (like we did for EJB3 - JPA) that the properties in the annotations aren't necessarily a copy of the properties from the XML Descriptor, so this is something that could cause problems and is good to be aware of.  Beyond that, as more requirements come in it will become more clear if the models you describe will be able to meet those requirements. 


* - https://bugs.eclipse.org/bugs/show_bug.cgi?id=79112
** - https://bugs.eclipse.org/bugs/show_bug.cgi?id=106108
***- https://bugs.eclipse.org/bugs/show_bug.cgi?id=154110

Raev, Kaloyan wrote:
Java EE 5 models design overview
Hi Shaun,
The Dali project was the place where I looked how annotation processing is done. After reviewing the tools in the org.eclipse.dali.core.util.jdt package I came to the idea to use the AST API.
May be a common package for annotation processing that is placed down in org.eclipse.jst will be of great benefit for many WTP components.
Can you provide some overview what is covered by the Dali tools for annotations and xml descriptors processing?
Thanks and greetings

From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Shaun Smith
Sent: Tuesday, November 14, 2006 9:16 PM
To: General discussion of project-wide or architectural issues.
Cc: General Dali EJB ORM developer discussion.
Subject: Re: [wtp-dev] Java EE 5 models design overview

I just want to point out that the Dali team has been dealing with the Java Annotation/XML Descriptor combination issue for some time, as this is how object-relational mappings are defined in JPA, and has a fair amount of expertize in this area.  Dali 0.5 has annotation support with XML support under development for 1.0.  Neil Hauge has previously solicited feedback on dealing with this issue.  Nothing much came of that effort so we've been patiently waiting for other teams to "hit the wall" on this so that we could start building the community of projects requiring Java 5 annotations that would be large enough to push for better annotation support from the platform projects we all rely on.

Raev, Kaloyan wrote:


This is a follow up of the WTP 2.0 Requirements meeting held on 26 Oct:

I want to present an overview of my vision how Java EE 5 models should be implemented in WTP.

Currently, there are J2EE 1.4 models implemented in WTP. These are EMF models generated from the deployment descriptors' XML Schemas of the J2EE 1.4 specification. Overview of the J2EE 1.4 models is presented in the following page:


Java EE 5 models should be implemented in a similar way. The EMF models should utilize the new deployment descriptors' XML Schemas from the Java EE 5 specification. Additional complexity to the models is added by the fact that the Java EE 5 specification uses Java Annotations in addition to the deployment descriptors. Therefore, the problematic shifts on how to integrate these annotations to the EMF model.

It was a natural approach that I had a look to the JEM (Java EMF Model) project. JEM contains functions for modeling Java classes in EMF. Unfortunately, JEM does not cover Java Annotations at the moment and there is no plan for the future yet:


There are to approaches to model Java Annotations:
1. Extend JEM with new features to cover Java Annotations and integrate both EMF models (the other one is the one generated from the XML Schemas).

2. Implement custom utility to parse and index Java Annotation from the source files and make the EMF model (made from XML Schemas) to use it.

Due to the lack of any documentation in the JEM project, approach 1. is feasible only long-term. This is why I want to concentrate on approach 2.

Now, the Java EE 5 models problem can be split in the following tasks:
1. Build an EMF model based on the deployment descriptors' XML Schemas.
2. Parse Java Annotations from the Java files.
3. Index the parsed annotations in a way they can be easily retrieved.
4. Make the EMF model to be influenced by the available annotations.
5. Update Java Annotation with changes on the EMF model.

Task 1. Build an EMF model based on the deployment descriptors'' XML Schemas.
This can be done easily with the available toolset provided by the EMF project. The EMF model is generated by the XML Schemas for the Java EE 5 deployment descriptors. A problem appears if we want to split the generated classes in separate packages for better structure:


However, this problem is solvable at least with manual refactoring of the generated classes.

Task 2. Parse Java Annotations from the Java files.
Here Java files can be:
  - Java Class files in JAR library in the classpath;
  - Java source files in the Eclipse project.

Java Annotations from the Java Class files can be easily parsed using the Sun's Java Reflect API.
Java Annotations from the Java source files can be parsed using the Java DOM/AST API provided by the Eclipse JDT Core project. The latter API models the Java source code as a structured document. There, annotations are treated as member modifiers (like public, private, static, final, etc.). There is a function that checks if a modifier is an annotation.

The parser utility will listen to events to trigger the parsing process:
  - ResourceChangeListener/Event - notifies for resource changes in the workspace: project open/close, files added/deleted, etc;

  - ElementChangedListener/Event - notifies for changes in the Java Editor. The parser will be notified that the user has changed a java file in the editor and it has to be reparsed for changes in the annotations.

Task 3. Index the parsed annotations in a way they can be easily retrieved.
The parser will update an appropriate structure with the added or removed annotations. The structure should allow quick and flexible way to retrieve the indexed annotation. For beginning even an ArrayList that holds references to the org.eclipse.jdt.core.dom.Annotation objects is enough. Annotation objects hold references to the parent Java members and parent workspace resources and that should be all the information we need. Of course, the ArrayList is far away from the optimal solution and it should be optimized later with a better structure.

Task 4. Make the EMF model to be influenced by the available annotations.
The generated EMF model from the deployment descriptors' XML Schemas will be modified in a way that it not only looks into the XML data, but also looks up the Annotation Model utility for the corresponding annotation. If there are such annotations indexed, the EMF model will update it state appropriately. The Annotation Model utility also has to provide notification framework, so the EMF model to register a listener and be notified with events on changes in the annotation model.

5. Update Java Annotation with changes on the EMF model.
Properties in the EMF model now declared in two sources: XML files and Java Annotations. When this property is changes it has to be updated in the same source. If the property is declared in XML then its new value has to be updated again in the XML file. If the property is declared as a Java Annotation it has to be updated again in the same Java Annotation.

To achieve the above, the EMF model has to be changed in a way that it remembers the source type of each property.
Updating Java Annotation will be done again using the Java DOM/AST API.

This is the overview for the moment. I want to here your comments. Especially, I want to hear your opinion about the "Extending JEM" <--> "Custom Annotation Model utility" dilemma. Due to the lack of documentation, my knowledge to JEM is not enough and I cannot estimate the effort to extend it with Java Annotation support. This is why I prefer the latter approach that I have described in more details.

There are no comments about the UI from my side for the moment. Here your comments would be also interesting. Do we stick to the Deployment Descriptor node in the Project Navigator? What features would be needed there for future enhancements?

Kaloyan Raev
Senior Developer
SAP Labs Bulgaria
T +359/2/9157-416

_______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev

_______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev