International Journal of Computer Applications (0975 – 8887)

Volume 70– No.24, May 2013

Automated EJB2 to EJB3 Migration

Isha Mittal, J.S. Sodhi, PhD
AMITY University AMITY University
Noida, India Noida, India

Abstract o In case of composite primary key, entity should

have an instance variable of the primary key class with
Conversion from some old technology to new technology is “@EmbeddedId” annotation.
requirement for today’s world, our IT industry was started
growing up in late 90’s. At that time there were lots of  DAO Interface
development comes in different industry, banking system had o Should extend CLBaseDao<EJB3.0-Entity, PK
changed drastically, it’s come online with online solutions, Type>
ATM takes place for withdrawing money from the bank,
similarly manufacturing industry grows with IT etc. o Should have declarations of all finder methods.
We had used advance technology of that time for providing o Should have “TODO” comment that list all the
solution to the respective industry. As the time changes there custom methods (not including getters/setters of entity fields
are some advancement in each field so IT has also comes with and “getData()” methods) with parameters.
lots of new technology & configurations, so that we can solve
 DAO Implementation Class
the real world problem more accurately with cheap prize.
o Should extend CLBaseDaoImpl< EJB3.0-Entity, PK
We are providing a automate migration tool that will migrate
Type> and implement <EJB3.0-Entity>Dao
EJB2.1 (old) to EJB3.0 (new)[1], EJB2.1 have several
disadvantages like it’s do not have annotation where o Should have implementations of all finder methods.
annotations are server independent configurations.
o Should have “TODO” comment that list all the
Keywords custom methods (not include getters/setters of entity fields
and “getData()” methods) with parameters
EJB2, EJB3, migration, business layer, Ejb2 to Ejb3
migration, time saving, 2.1 Analysis
1 INTRODUCTION 2.1.1 Identification of Data
Develop a tool to automate the generation of EJJB3.0 entity In this analysis all the data that would represent an entity
(with JPA) and corresponding DAO objects using available attributes was recognized. The following is the list of such
EJB2.1 artifacts such as XDoclet bean and the code (EJB2.1 attributes.
files, Weblogic AS specific deployment descriptors, Data
Transfer Objects (DTOs)) generated using it.[2]  Entity name and fields

The artifacts generated by the tool should follow the listed  Table name and columns
standards.
 Finder methods and queries
 EJB3.0 Entity
 Entity relationships
o Should list the files that were used to generate the
entity in class level comments. 2.1.2 Identification of Artefacts
o Should contain standard JPA annotations like In this analysis all the artifacts that would be used to
“@Entity”, “@Table”, “@NamedQueries”, aggregate entity attributes was recognized. The following is
“@TransactionAttribute”, “@Column”, “@Id”, the list of such artifacts.
“@SequenceGenerator”, “@GeneratedValue”, and “@Lob”  ejb-jar.xml
wherever applicable.
 weblogic-cmp-rdbms-jar.xml
o Should list the EJB2.1 deployment descriptor
annotations that are not processed by the tool as “TODO” in  weblogic-ejb-jar.xml
class level comments
 Local interface corresponding to each entity bean
o Should extend CLBaseEntity<PK Type> and
implement “getCompareables()” and “getPrimaryKey()”  Data Transfer Objects corresponding to each entity
methods. bean
o In case of composite primary key, a separate
primary key class should be generated annotated with
“@Embeddable” annotation.

49
 International Journal of Computer Applications (0975 – 8887)
Volume 70– No.24, May 2013

 Patterns recognized  Pattern used to filter jar file that contains DTOs and
local interfaces – “\\D.*-SNAPSHOT.jar$”
o In-case of deployment descriptors each module
contains these xml files in <path>\target\classes\META-INF\
o The corresponding jar file contain the DTOs and The file crawler generates two files after scanning the depths
local interfaces of the entity beans are accessible from of the required directory.
<path>\target\
 An xml file (filteredDDPaths.xml) that contains the
2.1.3 Identification of Development absolute paths of the deployment descriptor files for each
Methodologies module.

In this analysis development methodologies were identified

that would be used to generate EJB3.0 and DAO code. The <project>
following is the list of such artifacts.
<module>
 XML Transformation using JAXP
 Saxon Processor (XSLT 2.0 compatible) <ejb-dd-path>../work/../classes/META-INF/ejb-
 Logging using log4j jar.xml</ejb-dd-path>

 Directory scanning based on pattern <web-rdbms-dd-path>../work/../classes/META-

INF/weblogic-cmp-rdbms-jar.xml</web-rdbms-dd-
2.2 Design
path>
The tool consists of 2 mains components as depicted in
Figure1 <web-ejb-dd-path>../work/../classes/META-
INF/weblogic-ejb-jar.xml</web-ejb-dd-path>

</module>

<module>
 A file (jarPaths.txt) that lists the absolute paths of
<ejb-dd-path>……
the jar files that contain DTOs and local interfaces for each
module. This list would be used to set Java “classpath” and is
a pre-requisite for “Data Transformation”
</project>

2.2.1 Data Artefacts Aggregation

This component searches a particular directory for certain set
of files by making use of Regular Expression and generates 2
files. Figure 2 depicts this process.
The file patterns used to scan the required directory are
Figure 2–Data Artifacts Aggregation
 Pattern used to filter 3 types of files – “(^weblogic-
cmp-rdbms-jar.xml)|(^ejb-jar.xml)|(^ weblogic-ejb-jar.xm)”
 Pattern used to make sure that files come from
certain type of directory only – “.*classes\\\\META-INF.*”

50
 International Journal of Computer Applications (0975 – 8887)
Volume 70– No.24, May 2013

2.2.2 Data Transform 3.1.2 Common

The data transformation component provides the functionality 3.1.2.1 Utilities
of meta-data generation and finally EJB3.0/DAO code
generation. The following Figure 3 depicts this process.  ConfigReader.java – This class is used to load
base configuration file.
 ToolResourceBundle.java – This class maintains
resource bundle for given file.
 Constants.java – This interface holds application
constants values.
 ClassAnalyzer.java – This component loads a class
dynamically and retrieves its properties.
 DataInterpreter.java – This class is to analyse the
data for blank or empty values.
 FileUtility.java – This class provides various file
I/O functionality.

3.1.2.2 Resources
 ejb2-to-ejb3-config.properties – Tool
configuration file
 log4j.properties – Tool log4j configuration file
 CatalogManager.properties – This file tells the
Figure 3–Data Transformation resolver where to look for catalog files and sets configuration
options.
2.3.1 Meta-data Generation
 Xml-catalog.xml – A catalog in XML provides a
This component gathers all the information segregated in mapping from generic addresses to specific local directories
different files for each entity and place it one xml file (entity- on a given machine. A catalog can be used to locate the DTD,
data.xml). XSL transformation would be incorporated to work system entity files, and stylesheet files during processing.
with different xml files and access DTOs present in jar files to
aggregate the data. For each “module” element in  ejb-jar_2_0.dtd – DTD used by “ejb-jar.xml”
“filteredDDPaths.xml”, a separate “entity-data.xml” file
would be generated.  gcode-constants.xml – This XML file holds
constants that used by XSLT files.
2.3.2 EJB3.0/DAO Code Generation 3.1.3 EJB2 to EJB3
This component uses the meta-data file “entity-data.xml” and
performs an XSL transformation to generate the Java code. 3.1.3.1 Data Artefacts Aggregation
The XSL transformation will generate EJB3.0 entity and it
 FileCrawler.java – This component searches a
corresponding DAO objects referencing the generic DAO.
particular directory for certain set of files by making use of
3 IMPLEMENTATION Regular Expression and generates 2 files. The first is an XML
file that contains the absolute paths of the deployment
3.1 Development Modules descriptor files for each module. The second is a text file that
lists the absolute paths of the jar files that contain DTOs and
Eclipse IDE is used for tool development. local interfaces for each module.
3.1.1 3rdParty 3.1.3.2 Data Transformation
 Apache  Meta-data Generator
o log4j-1.2.16.jar – Application logging o MetadataGenerator.java – This class gathers all
the information segregated in different files for each entity
 Saxon-9.1B
and place it one xml file (entity-data-i.xml). XSL
o saxon9-dom.jar – XML document parsing transformation would be incorporated to work with different
xml files and access DTOs present in jar files to aggregate the
o saxon9.jar – XSLT processor data. For each “module” element in “filteredDDPaths.xml”, a
 J2EE separate “entity-data-i.xml” file would be generated.

o j2ee-1.4.jar – Required because the tool loads o meta-data-builder.xsl – XSLT file used for meta-
EJB2.1 files (local interfaces) using reflection for scanning data generation
 EJB3.0/DAO Code Generator
o CodeGenerator.java – This class uses the meta-
data file “entity-data-i.xml” and performs an XSL

51
 International Journal of Computer Applications (0975 – 8887)
Volume 70– No.24, May 2013

transformation to generate the Java code. The XSL

transformation will generate EJB3.0 entity and it
corresponding DAO objects referencing the Generic DAO.
o code-generator.xsl – XSLT file used for
EJB3.0/DAO generation.

3.1.4 Build
3.1.4.1 Ant Build Process
The build process will package the common and EJB2 to Directory/File Description
EJB3 java code in separate jar files. The resources would not
be packaged within the jar file. This would provide flexibility formatter Contains Eclipse IDE
to the user to modify configuration settings without worrying code formatting
about executing the build again. \
preferences file.
 ejb2-to-ejb3-tool-build.xml
Tool Base folder for
 ejb2-to-ejb3-tool-build.properties
migration tool.
3.2 Execution Process
Lib Contains 3rd party and
The EJB2 to EJB3 migration tool would be executed using a
batch process (ejb2_to_ejb3_tool.bat). The following would
common project jar
be the various stages. files.
 Data artefacts aggregation resources Contains
 Set java classpath using the jar file paths set in configuration files.
"jarPaths.txt
xslt-files Contains XSL
 Data transformation
transformation file.
4 THINGS TO REMEMBER ejb2_to_ejb3_tool.bat Batch file to execute
The following should be considered while integrating the the tool.
generated code.
1. I has been noticed that in the EJB2.1 code, named ejb2-to-ejb3-tool.jar Migration tool jar.
queries use reference to the entity attribute name that do not
match the actual declared variable. Wherever such instances 4.3 Configuration
are encountered, rectify the named query. The tool can be configured by using
2. If a "TODO" related to "The following table column “ejb2_to_ejb3\Utility\resources\ejb2-to-ejb3-
is mapped to an entity field as well as to an entity relationship config.properties” file. It lists different keys that can be set as
attribute" exists; however the related attributes are defined in per project requirements.
separate classes (e.g. Entity and PK class), ignore and remove
this TODO. S. Key Purpose
No
3. After applying fixes for a TODO, it should be
removed from the code. .
4. If an entity exists more than once in the EJB jar, it data.lookup.dir Directory path for
should be distinguished by custom entity name by setting the .path searching the
“name” attribute of “@Entity” annotation.
artifacts.
4.1 Tool 1.
e.g.
4.2 Structure “//ip.address/c$/work
The tool deliverable is in form of a zip archive file “ejb2-to- /flood”
ejb3-migration.zip”. Its structure is as follows.
data.artifacts.di Directory for listing
r.name the filtered artifacts.
2. e.g.
“//ip.address/c$/ejb2_
to_ejb3/artifacts-list-

52
 International Journal of Computer Applications (0975 – 8887)
Volume 70– No.24, May 2013

files” filtered.file.ele Artifacts “weblogic-

ment.web.rdbm cmp-rdbms-jar.xml”
data.artifacts.d Name of the file that
s.dd.path xml file module child
d.paths lists the path to 11. node name
filtered files.
3. e.g. “web-rdbms-dd-
e.g.
path”
“filteredDDPaths.xml
” filtered.file.ele Artifacts “weblogic-
ment.web.ejb.d ejb-jar.xml” xml file
data.artifacts.ja Name of the file that
d.path module child node
r.paths lists the jar file names 12. name
that are to be set in
Java classpath. These e.g. “web-ejb-dd-
jar files contain path”
4. DTO's and Local data.generated. Flag to switch
interfaces that would code.dir.option between custom
be interpreted for output directory
EJB3 entity
13. location. Valid values
properties. are “CUSTOM” and
e.g. “jarPaths.txt” “LOOK_UP_DIR”
data.meta.dir.n Directory path of the e.g. “CUSTOM”
ame generated meta-data data.generated. Directory location
files
code.custom.di where the code is
5. e.g. r.name generated. Applicable
“//ip.address/c$/ejb2_ if the directory option
to_ejb3/meta-data- 14. is "CUSTOM"
files” e.g.
meta.data.file.n Name of the meta- “//ip.address/c$/ejb2_
6. ame data file to_ejb3/output”
e.g. “entity-data-” data.generated. Sub-directory name
code.sub.src.m where the EJB3 code
meta.data.file.e File extension of
15. ain generated by the tool
7. xtension meta-data file
would be placed
e.g. “.xml”
e.g. “src/main/java/”
filtered.data.fil Artifacts xml file root
data.generated. Sub-directory name
8. e.root node name
code.sub.src.te where the EJB3 test
e.g. “project” 16. st code generated by the
filtered.data.fil Artifacts xml file tool would be placed
9. e.element.mod module node name e.g. “src/test/java/”
ule e.g. “module” dd.file.name.pa Pattern of the files to
filtered.file.ele Artifacts "ejb- ttern be filtered by the file
ment.ejb.dd.pat jar.xml" xml file crawler
16.
10. h module child node e.g. “(^weblogic-
name cmp-rdbms-
e.g. “ejb-dd-path” jar.xml)|(^ejb-
jar.xml)|(^weblogic-

53
 International Journal of Computer Applications (0975 – 8887)
Volume 70– No.24, May 2013

ejb-jar.xml)” code generation

dd.file.absolute Filtered deployment e.g.
.path.pattern descriptor files “//ip.address/c$/ejb2-
absolute path pattern to-ejb3-
17. migration/tool/resour
e.g.
ces/xsl-
“.*classes\\\\META-
constants.xml”
INF.*”
xml.transform.f XML Transform
jar.file.path.filt Filter for jar file
actory Factory
18. er location
24. e.g.
e.g. “classes”
“javax.xml.transform.
src.dir.filter Filter for source TransformerFactory”
directory location
saxon.xml.tran XML Transform
path
sform.factory Factory
e.g. “target/classes” Implementation
25.
entity.dao.pack Filter for establishing e.g.
age.filter.val the package for “net.sf.saxon.Transfo
19. entities and daos rmerFactoryImpl”
e.g. “interfaces.” 4.4 Execution
jar.file.name.pa Pattern of the jar file The tool can the executed by running the
“ejb2_to_ejb3_tool.bat”. This batch process involves 5
ttern to be filtered different stages that are listed below.
20.
e.g. “\\D.*- S.No. Section
SNAPSHOT.jar$” 1. Data artifacts aggregation
meta.data.build Location of the 2. Set Java classpath
er transformation file 3. Meta-data generation
for entity meta-data 4. Code generation
builder 5. Generated code indentation using
21. e.g. Eclipse IDE.
“//ip.address/c$/ejb2_ Note: The user would need to modify
to_ejb3/utility/xslt- the script for section 5 of the batch file
files/meta-data- as per the local machine.
builder.xsl”
code.generator Location of the 6 CONCLUSION
transformation file This paper gives an intelligent solution for migration of old
for entity code ejb version ejb 2.1 to new ejb version 3.0. It can be used in the
generator IT industry, especially for those companies which are working
on migration domain. Ejb contains the business logic of our
22. e.g. code that needs more security & flexibility from other code;
hence we can say it’s a useful tool for migration your code to
“//ip.address/c$/ejb2_ new code.
to_ejb3/utility/xslt-
files/code- 7 REFERENCES
generator.xsl” [1] Oracle Ejb Migration 2005

code.constants. Location of the xml [2] EJB components Migration Service and Automatic
Deployment – HA
23. file file that holds
constants used in

54
IJCATM : www.ijcaonline.org