Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Approach for repository based incremental annotation processing

IP.com Disclosure Number: IPCOM000234675D
Publication Date: 2014-Jan-28
Document File: 7 page(s) / 276K

Publishing Venue

The IP.com Prior Art Database


This disclosure deals with speeding up annotation processing in a J2EE application server during application deployment and startup. Prior knowledge about annotations in an application as well as sharing of information obtained from annotation processing across installations of the application are used to speed up this time consuming activity and to minimize resource usage and power consumption.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 7

Approach for repository based incremental annotation processing

As the J2EE spec is evolving, the applications built on J2EE specification are bloating both in terms of size and components. So is the time to deploy the application. The recent spec version introduced a new feature called "Annotations", where the configuration can be programmatically marked using annotation(s). It is during the deployment time that the deployment process processes these annotations and creates necessary bindings and metadata and persist them in the application. This process consumes significant amount of time as the Application deployer should scan through the entire application (.ear) for the annotations and then process them.

The recent numbers on deployment time indicates that a marginally sized J2EE application would take anywhere between 20-30mins to deploy. This significant increase in the deployment times would have major impact on the project schedule because of the repeated application deployment that takes place in various cycles as mentioned above. Unless, this problem is addressed, it would impede the overall project schedule. Thus poses the risk of IT layer becoming a bottleneck in meeting the business goals and objectives.

Consider a scenario, where modular development of application is followed and multiple developers develop discreet functions as single modules. Each modules can have own set of annotations and also annotations being added to modules at different point of time.


Page 02 of 7

Current approach and its disadvantages:

1) Every new deployment of the application will have all the annotations processed as part of deployment.


Page 03 of 7

2) If the development team of consists of multiple developers, then any deployment from any of these developers will have all annotations processed, even in the module where there was no updates done.

3) Every installation of final version of the application on Production Environment also processes all annotations.

4) All the jars in the application are scanned for annotations, including third party jars , which have no annotations.

The approach proposed is to process annotations and store artifacts only once across all deployments of the J2EE applications and utilize the same in subsequent deployments while processing the deltas. The system will also have enterprise repository at Organization and Business Unit level to make the versioned artifacts available for deployment.


During deployment, newly added annotations for a module are processed and xml file containing results is stored in an annotation repository with a version. The application server or IDE is updated with a link address to the repository and during deployment will lookup the preprocessed annotation metadata corresponding to each module in the repository. A hash will be used to differentiate between different versions of the module and their annotation met...