Tooling framework for detection of Java annotations overides by deployment desciptor in Java EE domain.

IP.com Prior Art Database Disclosure
IP.com Disclosure Number: IPCOM000171726D
 Publication Date: 17-Jun-2008
More Like This Download

Publishing Venue

The IP.com Prior Art Database

Abstract

Java EE artifacts can be defined through the Java annotations or deployment descriptors. The precedence rules for Deployment descriptor vs. annotations are normally defined as part of the specifications for particular Java EE domain. Since Java annotations can be dispersed through multiple Java classes in Java EE project and since relationship between data in Java annotations and deployment descriptor is not always clear , it is often hard to determine which annotation information is overridden by information in the deployment descriptor or vice versa. Existing solution to this problem is to look at the particular annotation, review the domain specifications to determine how similar information is normally represented in the deployment descriptor, look at the deployment descriptor to see if such override exists. The main goal of this article is to describe a configurable tooling framework that would allow Java EE developers to easily detect what Java annotations information is overridden by Java EE Deployment descriptor. This framework can also serve as a valuable learning tool for new developers to pick up knowledge about Java EE specifications that define relationship between Java annotations and Deployment descriptor.

Language

English (United States)

Document File

5 pages / 42.3 KB

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 38% of the total text.

Page 1 of 5

Tooling framework for detection of Java annotations overides by deployment desciptor in Java EE domain.

Visual representation of the tooling system is following

As can be seen from the visual representation, overrides detection module (ODM) obtains information from the deployment descriptor and Java annotations and uses mapping file to determine if some data defined in the Java annotations is also defined in the deployment descriptor. If such data overlap exists, that means that corresponding information in Java annotation in overridden. This override detection can further be presented through the UI (for example warning sign in the Java editor) or through the non-ui reports.

     We assume that information present in the deployment descriptor can be obtained in a form of EMF model. In turn, mapping file represents the relationships between specific Java annotations AND corresponding EMF model objects specific to certain domain.

Mapping file structure
Mapping file contains one or more AnnotationMapping elements that define the mapping between Java Annotations and corresponding EObjects in the EMF model.

1

[This page contains 1 picture or other non-text object]

Page 2 of 5

This element defines the actual mapping between given annotation and certain objects in EMF model. This element has one required and one optional attribute. The required attribute is "name" and it corresponds to the name of the annotation. Optional attribute is "eFeatureName" which corresponds to the feature name of the EMF object that maps to given annotation.

element contains one or

elements that define more granular mapping of Java annotation information to EMF information

This is a required element that defines mapping specific to the given Java annotation (there can be multiple mappings that are specific to the certain Java annotation). This element must contain one

element, which roughly represents the EObject in the EMF side of mapping. Each

can have an optional attribute "eFeatureName" which, if present would signify the EObject instance corresponding to EStructural feature with this name. If this attribute is not specified, it is assumed that mapping is defined to EObject defined in the parent AnnotationMapping element.

element can have a child

(which represent child/container relationship in the EMF model) and unlimited number of

elements that roughly represent EAttribute elements in the EMF model AND define the actual mapping rules.

In general there can be 3 different types of mapping:

Java annotation attribute to EAttribute
JavaElement name (type, field, method - depending were annotation is specified) to EAttribute
Predefined hard coded value to EAttribute
The type of the mapping is defined by targetType of the

element.

Lets consider the following example which specifies the mappings for @Stateless Java annotation from
EJB 3.0 domain

< mappi...

First page image
You are not signed in. If you have an IP.com account, your download price may be lower or waived. Click here if you want to sign-in now.
Loading PayPal...
The full document comprises 5 pages and is available as a PDF document as well as a ZIP archive. The cost is $40.00 USD (depending on your billing address, sales tax may apply); payment may be made directly using your credit card or your PayPal account.

If you've already purchased this document, and wish to download it now you may enter the download access code you received in your original email receipt.