|RE: [wtp-dev] Java EE 5 models design overview|
I'm working together with Kaloyan on jee5 model issues. Could you please cast some light over the kind of problems that you had with EMF based models and their solutions. As far as I understood simply synchronizing access to the model is not what's necessary. Is it only because of performance or there are also usages of the model that are not covered by the "synchronize" keyword?
We need somohow a more general understanding of the problems that the models in WTP face.
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik
Sent: Tuesday, November 14, 2006 6:51 PM
To: General discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] Java EE 5 models design overview
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.
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Raev, Kaloyan
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
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:
Task 1. Build an EMF model based on
the deployment descriptors'' XML Schemas.
However, this problem is solvable at least with manual refactoring of the generated classes.
Task 2. Parse Java Annotations from
the Java files.
Java Annotations from the Java Class
files can be easily parsed using the Sun's Java Reflect API.
parser utility will listen to events to trigger the parsing process:
- 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.
Task 4. Make the EMF model to be
influenced by the available annotations.
Update Java Annotation with changes on the EMF model.
achieve the above, the EMF model has to be changed in a way that it remembers
the source type of each property.
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?
_______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.