StarData GmbH

TLGen - Ejb3 Code-Generator

Authors:
Titus Livius Rosu (tituslivius.rosu@stardata.eu)
Titus Rosu (titus.rosu@stardata.eu)

 

1. General information

TLGen is a Java Code Generator based on EJB3 to generate the entire backend of an application.

The generated Code-Structure is described in chapter two which designs the architecture project. This layout of the folder structure is possible via the configuration file.

The use of the configuration file will be explained on the basis of examples of possible Code-Generation-Variation in chapter three.

The installation and use of TLGen in projects is described in the last chapter. There is also a detailed explanation of the provided example.

1.1 Objectives

TLGen is a Java Code Generator based on EJB3. The target of our work was to reduce costs for the back-end software development. Only a database and a configuration file (in XML) are necessary for the complete code generation via the help of TLGen. The latter takes over control of the code-generation.

At least the database model should be available in the 3rd normal form, if possible. (see also Wiki:Database_normalization)

The normalization is an important support to guarantee the consistency of the data. This facilitates the maintenance and upgrade options for future requirements of the application, without changing the datasets. Thus the generation of the back end will be possible because every line from a table of the database is displayed as a Java-Bean-Object in the generated code - whether as a Join/Mapping of multiple tables or a single line from a table, plays no role.

The back end-generated code corresponds to the software architecture concept which is described in Figure 1.

1.2 Download Content

The file "tlrgen3_v1001.zip" folder contains files with the following files:

  • project-TLGen3: Eclipse project files
  • build: Apache Ant files
  • doc: documentation, license files and in folder db the sql files for the test database
  • source: Source files
  • generator: TLGen.jar
  • resource
  • config

 

1.3 Example

The config file is a fully flexible XML and is easy configurable for your database model (the Tags are explained in the documentation)

A call from an object-generated data may look in Java like this:

[path-factory].FormularBci factoryBci = [path-factory].FormularBciFactory.getFormularBci();
[path-data-Interface].CoFormularDataIf formular = new [path-data].CoFormularData();
long formularId = factoryBci.createFormular(formular);

Read a data object:

[path-data-Interface].CoFormularDataIf formular =
         factoryBci.findByPrimaryKeyFormular(id);

All classes are generated by TLGen and can be used directly without modification. The so saved work reduces development and maintenance costs.

Furthermore TLGen is suited for the development of services such as SOA (Service Oriented Architecture).

 

2. Generated Code Structure

TLGen generates the entire code from Business-/Data-Objects, Session- and Entity-Beans to the Test-Classes (for JUnit).

(Note: All references for names of classes or names of packages are used in the example datas.)

 

2.1 Package- (Folder)-Structure of generated Code

The Package-Structure can be divided into three groups (see Figure 2):

  • Client-Package: required classes for the EJB3 access to the server (e.g. core) and the test classes (test).
  • Daten-Package: (Value-) Objects with 3 sub-packages: doc, doclist and form
  • Server-Package: also doc, doclist and form

 

3. Code Generation

The EJB3 compatible Java code will be only controlled with the help of the configuration file written in XML (for a more detailed explanation please refer to chapter 4 under Project-TLGen3\config\config_gen_db3i.xml)

 

3.1 What will be generated?

The following Java files are generated:

  • The server access classes of the client with the corresponding test classes
  • Data classes and their Interfaces
  • Session-, Entity-Beans and Manager Classes (which control the access of the entity beans to the session beans). Parts of the server classes in each case with their Interfaces (for Session-Beans and Manager classes) and the control file persistence.xml file.

 

3.2 Rules for Data Description

The configuration file controls the entire generation of the back end. It is individuable adjustable to their own needs, for example what the manager can/have to do or rather which methods should be generated for the (e.g.) SQL-Access. In the following chapters all possibilities and tags will be explained.

3.2.1 Wildcards for the Names

Within the configuration file there are wildcards for the names of the generic generated classes (for example, in the string "eu.stardata.core.form.data.Co%classname%Value"), so it can be set dynamically by the Generator. On this basis several classes can be written:

  • "eu.stardata.core.form.data.CoFormularValue"
  • "eu.stardata.core.form.data.CoDocumentValue", etc.

3.2.2 Generated Names of Tables

The generic name can be written from the database tables via the following rules: “Formular” will be generated from “CORE_FORMULAR” and “Document” from “CORE_DOCUMENT”.

 

3.3 Beschreibung der Konfigurationsdatei zur Steuerung der Generierung

Description of the Configuration File to control the Generation Multiple tags are used for the “config-file”. The main tag is <Generator>. Within <Generator> there can exist several <Command>-tags and in <Command> there can exist several <Design>-tags. Each of these tags with its sub-tags is described below.

3.3.1 <Generator>

Element: Generator
Parameter: name, datasource, reference
Content Model: (Command ?)

This is the main tag which can be used only once in a configuration file. It serves only for the management of information. Its parameters are:

  • name = project name
  • datasource = "java:/tlgenPool" is the database pool in the application server, a name which is used in the generated code.
  • reference = false or true. For this version of TLGen it should always be false. True will be important for new versions. With it the generator will be informed to take further generated code (from the Generator) into account which ex post was extended or changed by “hand”/manual (see Chapter 5)

3.3.2 <Command>

Element: Command
Parameter: name, type, initialcontext, initialcontextfactory, initialcontextpkgprefix, methods, sequencegen, earname
Content Model: (Design ?)

Command tag will be used to define the type of generation define and to set the access parameters for the Application Server (necessary only for the test classes):

  • name = name of the generated code
  • initialcontext = "[Host]: [Port]" -Application Server Initial Context (only for tests)
  • initialcontextfactory = "org.jnp.interface.NamingContextFactory" (only for tests)
  • initialcontextpkgprefix = "org.jboss.naming:org.jnp.interfaces" (only for tests)
  • type = "gdb" (at present only this type is possible) for the code generation on the basis of an existing database and a configuration file.
  • methods = "public"
  • sequencegen = "SEQ_STORE" is used in conjunction with the -seqstrategy
  • earname = "efp_test" is the ear name; if with help of ANT the classes are generated.

3.3.3 <Design>

Element: Generator
Parameter: name, methodtype, reference
Content Model: (Commentar ?, Class?, Entity?, Manager?, Session?, Test?, Dbtable?)

This tag is used to define a session bean with its managers and entity beans. Usually the session beans define remote access to the server. Simultaneously with the session bean the access classes for the client will be generated with the help of this tag. The client can access the session bean with the so-called BCI-layer (Business Common Interface).

  • name = generic name for this session bean
  • methodtype = "public"
  • reference = false or true. Overwrites the settings of generator tag (chapter 3.3.1). True will be important for new versions. With it the generator will be informed to take further generated code (from the Generator) into account which ex post was extended or changed by “hand”/manual (see Chapter 5)

3.3.3.1 <Commentar>

Element: Commentar
Parameter: name
Content Model: none

  • name = Commentary

3.3.3.2 <Class>

Element: Class
Parameter: name, type, extends, extendsif, constant
Content Model: none

This tag is for the generation of business classes and interfaces. For each database table is a data class and an interface generated. Explanation of parameters:

  • name = "eu.stardata.core.form.data.Co%classname%% Value eu. stardata.core.form.data.Co%% classname ValueIf" will be used for the data classes and name generation of the interface. The wildcard "%classname%" will be replaced by the right and own name (see also chapter 3.2.1 and chapter 3.2.2).
  • type = "public", i.e. that the classes and interfaces should be public.
  • extends = is used for the inheritance of the classes extends (e.g. "de.stardata.base.business.data.BaseData")
  • extendsif = is used for the inheritance of interface extends (eg "de.stardata.base.business.data.BaseDataIf")
  • tostring = Name of the string method for the generation of the business classes. There can be more names seperated with comma.

3.3.3.3 <Entity>

Entity:
Parameter: name, type, seqstrategy, implements
Content Model: (Annotation ?)

Entity tag will be used to generate the entity classes. Explanation of parameters:

  • name = "eu.stardata.server.core.formular.entity.%classname%entity” used to generate the entity names. The wildcard %classname% will be replaced by the right manager name, the name of the tables.
  • type = e.g. "public"
  • seqstartegy = "SEQUENCE","TABLE","IDENTITY" or "AUTO", are generating opportunities for the Primary Key. This apply to every entity bean which are located in the <Deasin> tag but which can be changed for one entity in the tag <Dbtable>.
  • implements = "java.io.Serializable" are the "implements" Interfaces for the entity bean.
The entity bean generation is described in tag <Dbtable>. There is also described the generation of relations.
If the Primary contains more columns, a pk class will be generated.

3.3.3.3.1 <Annotation>

Element: Annotation
Parameter: name
Content Model: none

Defines the annotations for the entity beans, it may be two or more. Explanation of the parameters, e.g.:

  • name = "javax.persistence.Entity"
    • and / or
  • name = -Name = "javax.persistence.Table", the tabname will be read from the database during generation.
    • and / or
  • name = javax.persistence.SequenceGenerator", will be completed in the time of generation by the database with name, sequenceName, intintialValue and allocationSize

3.3.3.4 <Manager>

Element: Manager
Parameter: name, type, extends, implements
Content Model: (Annotation ?, Variables?, Variablespri?, Method?)

The manager classes are generated via help from the manager-tag and its parameters. The accesses of the entity beans are controlled by these classes, the in the so-called "Local"mode. These classes are also used as classes between session-bean and entity-bean. In this version of TLGen a manager class will be generated for each entity-bean. In addition, possible SQL-accesses will be generated for each Entity Bean. At the same time with the manager classes are also the interface classes for access to the manager classes generated. Explanation of parameters:

  • name = "eu.stardata.server.core.formular.manager.%classname%Manager" is used to generate the manager name. The wildcard %classname% will be replaced with the right manager name of the table’s name
  • type = z.B. "public"
  • extends = "de.stardata.server.common.ejb.manager.BaseManager"
  • implements = "de.stardata.server.core.formular.bci.%Classname%BciIf", with this parameter the interface class will be generated for the manager.

3.3.3.4.1 <Annotation>

Element: Annotation
Parameter: name
Content Model: none

Defines the annotations for the manager classes. There can be any amount of classes. Explanation of the parameters, e.g.:

  • name = "javax.ejb.Stateless (name = de.stardata.server.core.formular.bci.%classname%BciIf.%membervariable4%)," the wildcard %classname% will be replaced with the correct class-names and %membervariable4% with the variable-name e.g. JNDI_NAME, which is defined in the Manager interface
    • and / or
  • name = "javax.ejb.Local (name = de.stardata.server.core.formular.bci.%classname%BciIf.class)", the wildcard %classname% will be replaced with the correct class-name.

3.3.3.4.2 <Variables>

Element: Variables
Parameter: name
Content Model: (Variable?)

This tag defines the groups of variables which are generated in the manager interface class.

3.3.3.4.2.1 <Variable>

Element: Variable
Parameter: name, type, content, manager
Content Model: none

Defines the variables which will be generated in an interface or a class.

  • name = "%membervariable4%" is used to define the variable name. In this TLGen version, the manager and TLGen’s interface classes are defined as following names of variables:
    public static String VARIABLE1 = "m_Manager";
    public static String VARIABLE2 = "SQL_FIND_ALL";
    public static String VARIABLE3 = "EAR_NAME";
    public static String VARIABLE4 = "JNDI_NAME";
    public static String VARIABLE5 = "MANAGER_NAME";
    public static String VARIABLE6 = "SQL_FIND_BYNAME";
    public static String VARIABLE7 = "PARAM_NAME";
  • type = "public static final java.lang.String"
  • content = %earname% will be replaced with the EAR name, e.g. for Parameters for a
SQL Query:
  • name = "%membervariable6%" will be replaced with the content "SQL_FIND_BYNAME"
  • type = "public static final java.lang.String"
  • content = "select o from %classname%entity o where o.formular =: formular"
  • manager = "Formular" means that this SQL Query's will be only generated in the manager-class "Formular".

3.3.3.4.3 <Variablespri>

Element: Variablespri
Parameter: name, type, content
Content Model: (Variable?)

This tag defines the groups of variables which will be generated in the manager classes.

3.3.3.4.3.1 <Variable>

Element: Variable
Parameter: name, type, content
Content Model: (Variable?)

Siehe auch Kap. 3.3.3.4.2.1

3.3.3.4.4 <Method>

Element: Method
Parameter: name, type, parameter, return, exception, manager, parameterSqlSingel, parameterSqlList, parameterType
Content Model: none

This tag generates the manager-methods. If the parameter manager is missing, the methods will be generated in all manager classes. If it exists, it will be only generated in this manager class. Using the parameters „parameterSqlSingel”, “parameterSqlList” and „parameterType“ your own SQL-Queries will be used in the generation.

  • name = "find ByPrimaryKey"
  • type = "public"
  • parameter = "long"
  • return = "%classdataif%” wildcard %classdataif% will be replaced with the data interface classes.
  • exception = "eu.stardata.server.common.exception.PersistenceException"
  • parameterSqlList = "SELECT u FROM User u WHERE u.username=:name AND u.pwd=:pass" is a SQL-Query, which returns a list of data objects.
  • parameterSqlSingel = "SELECT u FROM User u WHERE u.username=:name AND u.pwd=:pass" " is a SQL-Query, which returns one data objects.
  • parameterType = “java.lang.String, java.lang.Integer”. In this example are two parameter types, one a string object, the other a integer object.

3.3.3.5 <Session>

Element: Session
Parameter: name, type, managername, extends, transactiontype
Content Model: (Annotation ?, Method?, Factory?)

The session for the day will generate a session beans.

  • name = "de.stardata.server.core.formular.FormularSessionBean"
  • type = "public"
  • managerName = "manager form this name, according to EJB3 also in the file" persistent-tence.xml "under the day <persistence-unit> parameter name.
  • extends = "eu.stardata.server.common.ejb.session.BaseSessionBean"
  • transactiontype = "JTA"
Note: For the session bean (for the current version of TLGen) the following variables are defined:
public static String VARIABLE1 = "MANAGER_NAME";
public static String VARIABLE2 = "EAR_NAME";
public static String VARIABLE3 = "JNDI_NAME";

3.3.3.5.1 <Annotation>

Element: Annotation
Parameter: name
Content Model: none

Defines the annotations for the session bean class. There can be any amount of classes, e.g.

  • name = "javax.ejb.Stateless (name ="%factoryname%.%Membervariable3%), "the wildcard %factoryname% will be replaced by the correct class-name and %membervariable3% by the variable name, e.g. as JNDI_NAME which is defined in the manager interface classes.
    • and / or
  • name = "javax.ejb.Remote (name =%factoryname%.class)", the wildcard %factoryname% will be replaced with the correct factory class name.

3.3.3.5.2 <Factory>

Element: Factory
Parameter: name, extends, type
Content Model: (Annotation?, Variables?)

The factory tag generates two classes which are needed for the access by the client to the server; in each case a access class and a factory class. An example of a client’s access class:
eu.stardata.client.core.formular.bci.FormularBci factoryBci = eu.stardata.client.core.formular.bci.FormularBciFactory.getFormularBci();
eu.stardata.core.form.dataif.CoFormularValueIf var1 = factoryBci.findByPrimaryKeyFormular(1);

  • name = "de.stardata.server.core.formular.bci.FormularBci"
  • extends = "de.stardata.server.common.bci.BciFactory"
  • type = z.B. "public"

3.3.3.5.2.1 <Annotation>

Element: Annotation
Parameter: name
Content Model: none

Is the annotation for the factory class:

  • name = "javax.ejb.Remote"

3.3.3.5.2.2 <Variables>

Element: Variables
Parameter: name
Content Model: (Variable?)

Groups the variables for access classes.

3.3.3.5.2.2.1 <Variable>

Element: Variable
Parameter: name, type, content
Content Model: none

Definiert die Variable für eine Factory-Klasse.

  • name = "%membervariabe1%"
  • type = "public static final java.lang.String"
  • content = %earname% will be replaced by the EAR name.

3.3.3.5.3 <Method>

Element: Method
Parameter: name, type, parameter, return, exception, manager, parameterSqlList, parameterSqlSingel, parameterType
Content Model: none

This tag is used to generate the session bean methods. Using the parameters „parameterSqlSingel”, “parameterSqlList” and „parameterType“ your own SQL-Queries will be used in the generation.

  • name = "find ByPrimaryKey"
  • type = "public"
  • parameter = "long"
  • return = "%classdataif%” wildcard %classdataif% will be replaced by the data interface class.
  • exception = "eu.stardata.server.common.exception.PersistenceException"
  • manager = e.g. "Form" this method generated in the form Manager classes.
  • parameterSqlList = "SELECT u FROM User u WHERE u.username=:name AND u.pwd=:pass" is a SQL-Query, which returns a list of data objects.
  • parameterSqlSingel = "SELECT u FROM User u WHERE u.username=:name AND u.pwd=:pass" " is a SQL-Query, which returns one data objects.
  • parameterType = “java.lang.String, java.lang.Integer”. In this example are two parameter types, one a string object, the other a integer object.

3.3.3.6 <Test>

Element: Test
Parameter: name, type, extends
Content Model: (Import?, Method?)

That tag defines the data that are necessary for the generation of test classes. The aim of these generated classes is to define the accesses to the session beans and to accomplish a simplification of the test operation. These classes can be developed by hand.

  • name = "eu.stardata.client.test.core.formular.Formular3RwlTest", test-class-name
  • type = z.B. "public"
  • extends = "junit.framework.TestCase"

3.3.3.6.1 <Import>

Element: Import
Parameter: name
Content Model: none

Can be used for possible import classes.

  • name = "de.stardata.base.common.Trace"

3.3.3.6.2 <Method>

Element: Method
Parameter: name, type, parameter, return, exception, manager, readwritedel
Content Model: none

This tag is used to generate the test methods.

  • name = "create" methods name
  • type = e.g. "public"
  • parameter = "Form" parameter list for this method
  • return = „Form%“
  • exception = "eu.stardata.server.common.exception.PersistenceException"
  • manager = "Form"
  • Readwritedel = "0", "1", "2" or "3" -"0" = create type, "1" = find type, "2" = for update and 3" = Object delete.

3.3.3.7 <Dbtable>

Element: Dbtable
Parameter: name, type
Content Model: (Relation? Dbfreemethod?)

The engine control for the code-generation operates via the database tables. For each table (in this version of TLGen) a data class and its interface class will be generated as well as a entity bean and a manager class with his interface. For this reason the tag is an important part for the code generation in TLGen.

  • name = "CORE_FORMULAR" is the table name in the example script. From this name another one will be generated. In this case, the generic name is "Formular". In the next version of TLGen a name generator will be integrated.
With help of the table name all necessary information will be taken from the database which are important for the generation:
  • E.g. from the table columns (columns, which are used for generation of methods in the classes mentioned above) the name "Formular_id" will be generated by "FORMULAR_ID". At the same time the data type will be indentified which is also used for the generation.
  • Information about the Primary-Key
  • Sequences
  • type = e.g. "public"

3.3.3.8 <Relation>

Element: Relation
Parameter: type, table, cascade, fetchType, optional, direction, mappedBy
Content Model: (JoinColumn?, JoinTable?)

With this tag information for the relations between the tables of the entity beans are generated.

  • table = "CORE_PAGE" is the aim (target)-entity-bean (table)-name which has a relation with the current entity Bean (table).
  • type = following relationships are implemented: "OneToOne", "OneToMany", "ManyToOne" and "ManyToMany.
  • fetchType = "LAZY" or "EAGER" (see EJB3 documentation).
  • cascade = The following cascade "cascade" types are allowed: "ALL", "PERSIST", "MERGE", "REMOVE", "REFRESH".
  • optional = "true" or "false". Does not apply to type "ManyToMany"
  • direction = "true" or "false", applies only to Type "ManyToMany"
  • mappedBy = "form" (used for the entity bean, where direction = false), describes the attributes of the real relationship is defined.

3.3.3.8.1 <JoinTable>

Element: JoinTable
Parameter: name, catalog, schema
Content Model: (JoinColumns?)

This tag (annotation) is only required when the relations between two entity beans are displayed via an extra table and not via its own columns. This tag will be mostly used for the "ManyToMany relations.

  • name = "DOCUMENT_FORMULAR" is the name of the join-table on which the relationships work.
  • catalog = is the table catalog (optional)
  • schema = is the table schema (optional).

3.3.3.8.2 <JoinColumns>, <InverseJoinColumns>

Element: JoinColumn
Parameter: name, referencedColumnName, insertable, nullable, updatable, unique
Content Model: none

Via this tag (annotation) the name of the database column is defined which provides as a foreign key.

  • name = "FORMULAR_ID" is the column name for the relationship.
  • referencedColumnName = "DOCUMENT_LIST_ID" column is the other name for the relationship
  • inserable = boolean
  • nullable = boolean
  • updatable = boolean
  • unique = boolean

3.3.3.9 <Relation>

With help of this tag, the methods of the business classes are described which don’t have equivalents in the data banks. This means that for these methods there are no columns in the tables.

3.3.3.10 <Strategy>

Element: Strategy
Parameter: name, table, column, value
Content Model: none

  • name = for the strategy type („SEQUENCE“, „TABLE“, „IDENTITY“ oder „AUTO“)
  • table = Table-name for the strategy „Table“, in Annotation it is the parameter table
  • column = Column Name for the strategy „Table“ for parameter pkColumnName
  • value = Wert from Index for parameter valueColumnName

3.4 Beschreibung der Build-Datei für TLGen

Description of the build file for TLGen For the code generation the file "build_generator.xml" is used. This file will be called by an Apache-ANT-file (e.g. build.xml) with the following tags:

<target name="generator" depends="prepare" description="--> generate idl,bci,beans">
<ant antfile="${project}/build/build_generator.xml" inheritAll="true" inheritRefs="true" dir="${build.dir}" target="all"/>
</target>

The tag in the "build_generator.xml" for example for an Oracle database looks like:
<target name="generator" depends="generator-init" description="--> generate helper file">
<tlgen configFile = "[Path]/config_gen_db3i.xml"
databaseConnect = "jdbc:oracle:thin:@[host]:[port]:[SID]"
databaseDriver = "oracle.jdbc.driver.OracleDriver"
userPwd = "[username]:[password]"
database = "Oracle"
pathToGenerate = "C:/Project-TLGen3/source/generated">
<fileset dir="${src.server}"> <include name="**/${subsystem.dir}/**/*SessionBean.java"/> </fileset> </tlgen> </target>

with the fallowing content model <tlgen>, parameters:

  • databaseConnect = the path where the configuration file can be found
  • databaseDriver = database JDBC driver
  • userPwd = database user and his password
  • database = "Oracle" database name (for this version only the Oracle-DB is possible)
Note: The generated code is database and application server-independent!
  • PathToGenerate accepts <fileset> as a content model for the path where the generated code will be stored.

 

4. Installation of TLGen

TLGen was tested with the application server by JBoss (version 4.2 + GA) and by BEA WebLogic 10. The included sample installation and test generation are equipped for JBoss and Oracle. The file "tlgen3_vXX.zip" should be unpacked in any folder.

 

4.1 Used Tools and External Programs

The folder lib should contain following jars (the folders are important for the file ProjectTLGen3\ build\build_generator.xml; can anytime be extended or changed, see Chapter 4.3):

  • lib/: junit.jar (JUnit)
  • lib/apache/: ant.jar (Apache Ant Vers. 1.7+)
  • lib/jboss/: JBoss Version 4.2+ GA:
    • ejb3-persistence.jar
    • hibernate-annotations.jar
    • jbossall-client.jar
    • jboss-ejb3x.jar
    • mail.jar
  • lib/oracle/:
    • nls_charset12.jar
    • ojdbc14.jar

 

4.2 Example

The zip contains a complete example (see chapter 4.3). The example configuration file can be found in Project TLGen3\config\config_gen_db3i.xml. The example SQL-script can be found in Project TLGen3\doc\db\sql.

4.3 Installation

The following explains a sample installation and a code generation. In the supplied configuration file

  • Project-TLGen3\config\config_gen_db3i.xml

the server-URL has to be adjusted:

  • initialcontext = "jnp://[IP/HOST]:[PORT]"

With the right address and application server port (e.g. jnp://127.0.0.1/1099) in the config_gen_db3i.xml the right data source must be set in the tag generator (see chapter 3.3.1) -for example "ja-va:/tlgenPool".

For the compilation with Apache ANT the variables in their respective folders have to be changed: In…

  • Project-TLGen3\build\build_generator.xml

… below the database connection has to be set correctly (see chapter 3.4) and the…

  • Project-TLGen3\build\build.properties

…the variables for the

  • Project-TLGen3\build\build.xml

…have to be changed. E.g. ANT_HOME=[Pfad]\ant-1.7.0, JBOSS_HOME=C:/jboss-4.2.2.GA, PROJECT_PATH=C:/Project-TLGen, CONNECT_POOL=tlgenPool

4.3.1 Database

After the installation a test database of Oracle should be set. The SQL scripts can be found in the following folders: Project-TLGen3\doc\db\sql. All major SQL scripts must be declared via CreateCore3DB.sql whereat you have to set the absolute path in the file. In addition, you either need to set up the Tablespace CODATA, COINDEX in the file CreateTLGenOraTest.sql in the database or to change the file for other tablespaces. The test database model is shown in Figure 3. (http://www.oracle.com/technology/ software/products/database/index.html)

4.3.2 Setup JBoss Application Server

In JBoss a new server with the name "TLGen" should be set up by copying the folders jboss/server/all/ and renaming as "TLGen". Then copy the two library files ojdbc14.jar and nls_charset12.jar from Oracle in the folder lib from TLGen-server, then copy the file jboss4.2.2.GA\docs\examples\jca\oracle-ds.xml in the folder deploy from the TLGen-server and set up these for your Oracle database. Check whether your system path JA-VA_HOME is set up correctly. Then start the server with \bin\run.bat-c TLGen or \bin\run_debug.bat-c TLGen. (See also JBoss documentation http://www.jboss.org/docs/index).

4.3.3 Import Program in Eclipse

The project can be simply imported in the editor Eclipse (http://www.eclipse.org). The Eclipse configuration files are stored in the root directory structure. You can also import it in other editors, please refer to the manual respective producers. With help of Apache Ant (http://ant.apache.org/, please check whether your system path ANT_HOME is set up correctly) the code can be generated in the folder, whereas you can find the build.xml for ANT in the folder build. Use just the command line input call (cmd.exe) and type ant in the build-folder. Via the generation also the ear and jar files will be copied into the new server (see chapter 4.3, 4.3.2). If necessary you have to restart the JBoss server.

4.3.4 Test TLGen

E.g. by simply calling via Eclipse the generated test classes "Formular3RwlTest.java" and "ManyToMa-ny3RwlTest.java" with JUnit (http://www.junit.org/) and test the generated code. Enjoy!

 

5. Plans for subsequent versions

In TLGen v1 the important features of EJB3 are implemented. In this version it is not possible that the generator recognizes generated code and does not overwrite when regenerating, which subsequently has been extended "by hand". This will be implemented in a later version. At that moment it is advisable to save manual changed code from regenerating.

For the following versions these new features are planned:

  • Support for multiple databases (MySql, SqlServer, DB2)
  • Several ways to design the generating more dynamic
  • The possibility to generate Interfaces for other applications
  • Connecting the current generation with code generation of UML.
  • Involving the manual modified or extended code for a new generation.

 

6. Appendix: References

 

... please visit StarData GmbH for more Information