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

Raev, Kaloyan wrote:
Hi Jesper,

We have taken a look at the J2EE 1.4 models implementation. It did make
impression that there are lots of hand made tweaks there.


I'm a bit confused. You've seen/commented on bug 157185 covering most of the XML side of J2EE, excluding annotations, so you must know quite a bit about the progress on this. I'll offer my findings anyway:
We decided to make the initial Java EE 5 models generated from the XML
schemas. There is also a lot of hand made work to be done to integrate
Java Annotations in these models.
I can imagine. The Java EE annotation classes make up a model in itself, and it would be a pity to have to hand code all that model translation.
Can you outline in more details the tweaks that were done to the J2EE
1.4 models, so we have them in mind for the Java EE 5 ones? Do you think
better approach is to extend the existing J2EE 1.4 models with Java EE 5
specification instead of implementing separate Java EE 5 models?
[First a disclaimer: My knowledge of this is based in part on *Daniel Rohes *excellent article on Persisting EMF models with WTP [1], and in part by reading source and experimenting. I do hope the WTP veterans will confirm my findings. WTP hacking is not my day job.]

As I understand the idea behind the current J2EE 1.4 EMF models, they are modeled after the semantic contents and then the XML translation is added "on top", bypassing the EMF XMLSave/XMLLoad, but using EMF2DOM, EMF2SAX and EMF2DOMSSE instead. This translation is done by hand, see e.g. org.eclipse.jst.j2ee.internal.model.translator.webapplication.WebAppTranslator (note how this handles all supported versions of the spec)

By "semantic contents", I mean that while the XSD support in EMF is good at de-XML'izing the EMF model generated from the XML, it cannot guess what the schema means. It you import the XSD for web application, you get (among other things) a "ServletMapping" type, with a servletName (string) attribute. This corresponds to the XSD model and binds cleanly to XML using the EMF model annotations.
If you look at WTP's corresponding model (webapplication.ecore), you see that the ServletMapping type actually references the real Servlet type, with the name of the servlet being factored out (normalized into the Servlet). You even get the link back to WebApplication as a getter. It makes a lot of coding tasks easier, such as when writing custom validators, specialized GUI code and whatnot. Not to mention that if you want to build a graphical editor on top of this, you really really need the semantics to be represented in the model.


Another key benefits of the Translator model is that the EMF models are updated "as you type" in the XML documents when using the structured XML editor (SSE). This is how e.g. the common navigator updates is updated if you type "<servlet name="myServlet" ...> into a web.xml file. Typing updates the SSE DOM, which in turn notifies the EMF2DOMSSEAdapters, which then updates the EMF model (which the common navigator listens to). This wouldn't be possible using the EMF XMLSave/XMLLoad where you'd have to wait for a save/load before you could pick up model changes. And you can still use the EMF based editing scheme, or even GMF.

(I haven't found a reference document for this or a discussion, etc. but I'm possibly not looking in the right places)

The translation layer, while neat, comes at a cost as described above: You have to wire up the EMF to XML translations yourself. Documentation is pretty scarce, and the framework does not allow all combinations of modifiers are allowed (see bug 160569 [2] and 164246 [3]). I'm also looking into other enhancements.

For the annotation model, I'll refer you to Neil's reply, I had something similar in mind, but instead of coding the Annotation <-> EMF mapping, I'd suggest mapping it in a fashion similar to the EMF-XML Translators, using adapters on the EMF model, referring back to the AST model.

-Jesper

[1] http://www.eclipse.org/articles/Article-WTP-Persisting-EMF/persisting.html
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=160569
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=164246