Kaloyan,
I just want to make sure that you are
aware that the EMF models tend to be extremely unsafe in multi threaded use. We’ve
been flushing out and fixing bugs for a long time now and there are still more
being found every day. Posting the contents of relevant annotations into the
EMF model would drastically increase the number of writers and make the problem
much worse. That’s not to say that this isn’t a valid approach, but
it would be wise to make the relevant EMF models provably thread-safe as part
of this effort.
- Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Raev, Kaloyan
Sent: Tuesday, November 14, 2006
5:55 AM
To: wtp-dev@xxxxxxxxxxx
Subject: [wtp-dev] Java EE 5
models design overview
Hello,
This
is a follow up of the WTP 2.0 Requirements meeting held on 26 Oct:
http://wiki.eclipse.org/index.php/2006-10-26_wtp-requiremements-minutes
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:
http://www.eclipse.org/webtools/jst/components/j2ee/api/j2ee_models_overview.html
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:
http://dev.eclipse.org/newslists/news.eclipse.tools.ve/msg05989.html
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:
http://www.eclipse.org/newsportal/article.php?id=20770&group=eclipse.tools.emf#20770
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?
Greetings,
Kaloyan Raev
Senior Developer
NW AS JS TOOLS JEE (BG)
SAP Labs Bulgaria
T +359/2/9157-416
mailto:kaloyan.raev@xxxxxxx
www.sap.com