You already have an application developed using stored procedures and the requirement is to port the application to JBoss Seam, RichFaces, GWT, Swing EJB, Spring, WEB Beans, or any other Java technology without modifying the existing data model and reusing the existing stored procedures to read and write data.

With POJO-SP, the developers can focus on the business rules implementation without the overhead of building the JDBC stored procedure calls. The database access and stored procedures implementation is now transparent to the developers. JSPA handles all the database access, stored procedures, SQL statements, open and close of statements, and releasing the JDBC connections after they are used. It also converts all the database types to the corresponding Java types, and ResultSets returned by the stored procedure are converted to a simple List of POJO entities already detached.

2. Migration of legacy applications to a new data model

The second scenario is migration of large enterprise projects to a new data model. Let’s assume you have an existing legacy database implementing complex business logic in stored procedures. The original data model no longer represents the real data model of your business. A full redesign and migration is not feasible but is perhaps planned in future releases.

JSPA assists you out with building an enterprise application with a clean data model without changing the exiting database model.

A few simple steps will streamline your development. JSPA is not just a new way to access stored procedures but it is intended to be a simple, easy, and flexible programming model that allows Java developers to build an application using the best practice design patterns without refactoring the underlying legacy applications.

With Java Stored Procedures API, everything is transparent, making the Java data model clean. The DAOManager will convert the SQL errors and stored procedure application errors to Java Errors. All this conversion is transparent done without any line of code to be written by Java developers using the API.

Benefits

· Removes the complexity of the stored procedure life cycle implemented by each database application resulting in improved developer productivity

· Improved system stability as all database operations are consistent.

· Eliminates points of failure by transforming the stored procedure into a simple POJO.

· Handles the database actions transparently, similar to Java Entity Manager.

· Full integration of Stored Procedures POJO with EJB 2.0, Seam and other J2EE frameworks.

· The stored procedures have a simple Bean representation similar to Enterprise Entities.

· The POJO does not have to implement any database specific code.

· Simplicity for EJB 3.0 developers.

· The API provides simple injection of the DAOManager in EJB Bean components as @PersistenceContext does for PJA.

What is a Data Access Object (DAO)?

A DAO provides an abstract interface to the database persistence mechanism. It provides record operations (load, save, delete, update) without exposing details of the JDBC call and the stored procedure implementation. The design and implementation of the DAO interface is a tradeoff between simplicity and flexibility.

The DAO is just a collection of the IN, OUT parameters of the stored procedure. In JSPA, each stored procedure parameter is a DAO field. A DAOManager component provided by JSPA handles the database call. If you are using an EJB 3.0 container, the DAOManager can be very simple injected using the DAOManagerInjector:

@PersistenceDAO

protected DAOManager daoManager;

Step by step guide to a simple JSPA request in EJB 3.0

1. Create a Java Bean that contains a field for each IN, OUT parameters of the stored procedure.

2. Set the IN parameters.

3. Inject a DAOManager.

4. Pass the bean to the DAOManager execute method. (or calling one of the operations: load, store, delete and update).

5. Read the OUT parameters from your Bean properties.

Note: If you are using advanced DAO operations (find, select, create, delete and update) the DAOManager will convert the stored procedure application errors to Java errors.

The JSPA life cycle (or what is happening with my Bean?)

The API does an atomic call to the database using the bean fields and IN OUT Stored procedure parameters. Unlike the Entity Manager, any Create or Update operations will be executed in one transaction and it is not possible to roll back. The rollback operation logic must be implemented in a separate stored procedure.

The DAOManager:

· creates a CallableStatement

· sets the IN and INOUT properties

· opens a database connection

· executes the SQL statement

· receives the response from the stored procedure database call

· decodes the values of the stored procedure OUT parameters returned by the CallableStatement

· sets the values of the OUT fields in your Java Bean with the corresponding values

· closes the database connection

The API supports stored procedures IN, INOUT, OUT, and function return parameters.

The DAOManager provided by the API is responsible for updating the Bean fields’ values with the values returned by the stored procedure.

Supported Java Data types as IN OUT Stored procedure parameters

All Java primitive types with the exception of Boolean type for Oracle are supported by SP DAO API:

Data Type	Default Value (for fields)
Byte	0
Short	0
Int	0
Long	0L
Float	0.0f
Double	0.0d
Char	'\u0000'
String (or any object)	Null

JSPAPI supports the following Java Objects for stored procedures IN, OUT parameters:

	Java Objects
	java.lang.String
	java.lang.Character
	java.lang.Byte
	java.lang.Integer
	java.lang.Long
	java.lang.Double
	java.lang.Float
	java.lang.Short
	java.math.BigDecimal
	java.sql.Clob
	java.math.Number
	java.sql.BLOB
	java.sql.Date
	java.sql.Timestamp
	java.sql.Time
	java.io.Reader
	char
	Array of Objects and primitives

Java type mapping to JDBC types

JDBC Type	Java Type
VARCHAR	java.lang.String
NUMERIC	java.math.BigDecimal
DECIMAL	java.math.BigDecimal
BIT	boolean
TINYINT	byte
SMALLINT	short
INTEGER	int
BIGINT	long
REAL	float
FLOAT	double
DOUBLE	double
LONGVARBINARY	byte[]
DATE	java.sql.Date
TIME	java.sql.Time
TIMESTAMP	java.sql.Timestamp
CLOB	java.sql.Clob
BLOB	java.sql.Blob
ARRAY	java.sql.Array
STRUCT	java.sql.Struct
REF	java.sql.Ref
JAVA_OBJECT	Underlying Java Class

Version 1 limitations

The API is only tested with Oracle databases.

For Oracle, the Boolean type is not supported due an Oracle JDBC driver limitation.

If the bean has a boolean field, then it will be converted to VARCHAR2 with a value of “true” or “false”.

Oracle Struct types are not tested. However, Oracle Arrays with simple types as IN OUT parameters are fully supported.

Features

· All SQL types are converted to Java types.

· Oracle Array as IN/OUT parameters are supported. Single dimensional arrays are automatic converted to a Java Collection.

· Oracle CURSOR (ResultSet) is fully supported. Any cursors returned by stored procedures or functions will be automatically converted to a Java List. The List members type can be as simple as a Java Bean or an existing EJB 3.0 Entity that can be managed by Entity Manager.

· Primary key (embeddable class) is supported for SP DAO objects similar to EJB 3.0 Persistence API. It defines a class whose instances are used as stored procedure (IN/OUT/INOUT) properties. Each field of the embedded object is mapped to a stored procedure IN/INOUT or OUT parameter. The fields of the embedded object have to be annotated using the SP DAO field annotations.

DAOManager functions

There are two types of operations supported by DAOManager.

1. Generic mode

· The generic operational mode provides two operations: Generic stored procedures and generic functions.

· In this mode you can use DAOManager to call a database stored procedure or database function using a generic DAO.

· In this mode you have to create the DAO (POJO) and pass it to the DAO Manager responsible for executing the database transaction and handling the conversation.

· This mode is useful to call legacy stored procedures when you have no access or limited access to modify and normalize the existing stored procedures signature.

2. DAO mode

· This operational mode is covered by a set of 5 distinct operations that can be executed by DAOManager for a POJO DAO:

Ø create

Ø delete

Ø update

Ø select

Ø find

· The Stored Procedures used for this functionality should follow a specific signature.

· However, Java Bean (POJO) has no restrictions or limitation and do not have to implement any specific interface. It can even be an existing standard Entity Bean associated with a table or view. It can be retrieved using Entity Manager from one database and can be persisted using DAOManager in the same database or a different database.

· For DAO Mode, all application errors thrown by the stored procedures are caught by DAOManager and automatically converted to Java Exceptions, so your POJO does not contain properties representing error codes or error messages. The POJO is simply representing the IN/OUT data values.

· In DAO Mode the DAOManager is using the primary key/defined using the EJB @Id annotation for Update, Delete and Find operations. For primary key we are supporting Embeddable ID too. You can define the Primary key in a separate Java class.

Java DAO Annotations

There are some annotations you have to become familiar with when using DAOManager. The good news is all of the annotation will take just a few minutes to master. The annotation names should make sense and many of the parameters of the field annotations are optional.

Basic functions annotations
@DAO	- define a Java class representing a stored procedure. Any POJO process by DAOManager should have this annotation
@IN	- map the annotated field to a database stored procedure IN parameter
@OUT	- map the annotated field to a database stored procedure OUT parameter
@INOUT	- map the annotated field to a database stored procedure INOUT parameter.
@FuntionReturn	- map the annotated field to a database function return parameter. This annotation is the same with OUT parameter index 1.

JSPA defines many other useful annotations beyond the simple IN/OUT stored procedures parameters mappings.

Advanced functions annotations
@ParametersMapping	- complex property index mappings; - the same bean field (IN, INOUT, or OUT) may have a different parameter index for different stored procedures.
@DAOConstructor	- used to convert a ResultSet property to a Java List
@Secret	- used to mask sensitive values in log4j

In most cases, the simplest format of this annotation requires just one parameter, the index of the parameter in the stored procedure signature.

To improve performance of DAOManager, you can specify the database type of each field.

Java DAO restrictions

There are no restrictions for the stored procedures signatures when using the DAOManager with generic stored procedures or generic functions. However, you cannot map the same POJO to more than one generic stored procedure or more than one generic function.

When using DAO mode, by default the index ONE and TWO are reserved for application error code and error message.

If the store procedure returns a non zero error code, DAOManager will throw a Java Exception.

The index default values for error code and messages can be overwritten or disabled. However, this functionality is experimental at the moment, it was not fully tested and it is not recommended for a production system.

DAO Mode API - operations stored procedures - default signatures

Guide to using POJO SP

· Create a new data model in your Java layer using simple POJO objects and ignoring the existing data model.

· Create primary keys, unique ids, and constraints using annotations in your new POJO objects.

· The new constraints do not have to exist in the database, but unlike the Entity Manager that rely on database constraint validations the JSPA takes care of them in Java side and they will be enforced by DAOManager during the persistence or select operations.

· Developers are going to use the clean data model representing the new business application.

· You can reuse any existing legacy stored procedure creating wrappers that follows the DAO API signatures.This way your old legacy code lives on!

Note: Just ignoring the existing data model implemented of the database and not spending time to refactor the database and legacy stored procedures will cut the cost and the release time. The developers do not have to spend much time on the database integration.

Your POJO-SP implementation will pay off when you are ready to fully deprecate the legacy application. Just replace the DAO with real EJB Entities and deploy the new data model in the database and the project is finished! Well…you might want to test it. Migrating from POJO-SP to a new database schema requires no coding but just adding the proper JPA annotations to existing POJOs used by POJO SPs.

The DAO operations provided in DAO Mode are powerful tools that allow you to build a new clean data mode in the Java layer of the application when using data mapped to a legacy database that do not represent 100% your current application business data model. In this case, most of the operations are executed using stored procedures and the legacy applications may implement complex logic in stored procedures. Using a direct POJO mapping to tables, using Entity Manager and re-implementing the existing stored procedures logic in Java may not be the best option.

As a simple alternative to reuse the existing Stored Procedures but preserving the integrity of the new data model (not enforced by the DB) is to use JSPA in DAO mode that will provide the basic DAO operations and also will provide unique features like unique identifiers (as Primary keys) for each entity you store or retrieve from the database. The PKs do not exist in the database layer but they will be enforced by the POJO SP API.

There are five SP signatures that will be expected by the Java layer. All signatures are record operation oriented.

The stored procedures implement one of the following standard data persistence operations:

- CREATE

- UPDATE

- DELETE

- FIND

- SELECT

Most of the operations require using Unique IDs. A SP DAO Unique ID specifies the primary key of the entity stored or retrieved using stored procedures.

The following signatures assume the stored procedures contains N parameters used as primary keys (IN or OUT) and other M parameters that can be IN/OUT/INOUT.

CREATE - Stored procedure signature

PROCEDURE_NAME

(

ErrorCode OUT NUMBER,

ErrorText OUT VARCHAR2,

arg1 IN/OUT TYPE, (PK)

…..

arg N IN or OUT TYPE (PK)

argN+1 IN TYPE,

…..

argN+M IN TYPE

);

Note:

The PK for create SP may be sent by caller or may be returned by database, base on the type of the parameter. (IN or OUT)

UPDATE - Stored procedure signature

PROCEDURE_NAME

(

ErrorCode OUT NUMBER,

ErrorText OUT VARCHAR2,

arg1 IN/OUT TYPE, (PK)

…..

arg N IN or OUT TYPE, (PK)

argN+1 IN TYPE,

…..

argN+M IN TYPE

);

DELETE - Stored procedure signature

PROCEDURE_NAME

(

ErrorCode OUT NUMBER,

ErrorText OUT VARCHAR2,

arg1 IN TYPE, (PK)

arg 2 IN TYPE, (PK)

...

arg N IN TYPE (PK)

);

FIND - Stored procedure signature

PROCEDURE_NAME

(

ErrorCode OUT NUMBER,

ErrorText OUT VARCHAR2,

arg1 IN TYPE, (PK)

…..

argN IN TYPE, (PK)

argN+1 OUT TYPE,

…..

argN+M OUT TYPE

);

SELECT - Database Function signature

FUNCTION_NAME

(

ErrorCode OUT NUMBER,

ErrorText OUT VARCHAR2,

arg1 IN TYPE,

arg2 IN TYPE,

...

argM IN TYPE

)

RETURN REF_CURSOR;

JSPA will convert the REF_CURSOR to a list of Java Entities. The Java developers do not have to parse and take care of the lifecycle of the REF_CURSOR.

Important info about Error Codes

· Application Errors returned by ErrorCode parameter are automatic converted to Oracle Stored Procedure Exception types.

· Successful operations should always return 0 “ZERO”

· The default indexes for error code and error message parameters are:

· 1 and 2 for INSERT, CREATE, DELETE, UPDATE and FIND; using stored procedures;

· 2 and 3 for SELECT; this operation is using an Oracle Function and parameter 1 is the result.

DAOManager

Performance and Usage hints:

1. Defining the SQL parameter type for each OUT and INOUT parameter will definitively improve the performance because the DAOManager does not have to guess the database type, the type lookup can be an expensive operation. For Strings the performance will not be significant. The VARCHAR type is the first one the DAOManager will try.

For example, the following two definitions of the field “outParameter” are equivalent:

SQL Type not specified:

SQL Type specified:

@OUT(index = 3)

private String outParameter;

@OUT(index = 3, sqlType = Types.VARCHAR)

private String outParameter;

However, we always recommend the second option for a better performance.

2. @FunctionReturn vs @OUT

Internally the FunctionReturn is converted to OUT parameter. So using @ OUT, should provide a better performance but may not be significant. On the other hand, the FunctionReturn is much clear for developers and support.

3. Associating IN or OUT annotation with more than one operation:

a. If the same IN/OUT definition applies to more than one stored procedure, you do not have to duplicate the annotation for each operation. Just enumerate all operations associated with it.

For example, the following definition applies to DELETE and FIND stored procedures.

@Id

@IN(index = 3, operation = {Operation.DELETE, Operation.FIND})

private String outParameter;

4. Specifying the operation is optional and it does not improve the performance if you use just one operation. Not specifying an operation type (GENERIC, INSERT, CREATE, SELECT) for a field will make by default this definitions to apply to all operations. Therefore, in most of the use cases where your POJO is associated with just one stored procedure or function, you do not have to specify the operation type.

For example, the following three definitions are equivalent in this case:

@OUT(index = 3)

@OUT(index = 3, sqlType = Types.VARCHAR)

@OUT(index = 3, sqlType = Types.VARCHAR, operation=Operation.GENERIC_STORED_PROCEDURE)

Advanced operations:

1. You can overwrite the error code and error message index for each operation.

2. You can take advantage of the automatic application error conversion even for generic stored procedures or generic functions.

a. If your legacy Stored procedure used a parameter as a numeric error code, than you can set this index for the Generic operation definition.

b. 0 (zero) = no error,

c. Any other value different than zero will be interpreted as application errors.

Integrating JSPA with EJB containers

Configuring DAOManager Interceptor

To take advantage of @PersistenceDAO you first have to configure the DAOManager Interceptor.

There is a single configuration step for your container to apply to JSPA Interceptor.

This interceptor handles the injection and takes care of database connection resources during the activation and passivation process for Stateful beans. The easy way to apply the interceptor across an entire application is to add the following JSPA interceptor configuration in ejb-jar.xml:

<interceptor-class>com.hrx.rasp.util.dao.ejb.injection.DAOManagerInjector</interceptor-class>

<resource-ref>

<res-ref-name>jdbc/pojo-sp</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<mapped-name>java:/jdbc/jspa</mapped-name>

</resource-ref>

</interceptor>

</interceptors>

<assembly-descriptor>

<interceptor-binding>

<ejb-name>*</ejb-name>

<interceptor-class>com.hrx.rasp.util.dao.ejb.injection.DAOManagerInjector</interceptor-class>

</interceptor-binding>

</assembly-descriptor>

The configuration sets the default data source, used by Injector if no other data source name has been set in the code.

JSPI Injector needs to know where to find the default data source if the data source name is not specified at the injection type.

Using DAOManager Interceptor

EJB 3.0 is a pure dependency injection container. JSPI takes advantage of this functionality and it provides out of the box a standard implementation for DAOManager interceptor. The functionality is supported by @PersistenceDAO field annotation.

Example of DAOManager injection in EJB environment

Example of DAOManager using default data source

@PersistenceDAO

DAOManager daoManager;

…..

{

UserDAO dao = new UserDAO();

dao.set

this.daoManager.execute(dao);

}

…..

Example of DAOManager using custom data source

@PersistenceDAO(dataSourceMappedName="jdbc/oracle2")

DAOManager daoManager;

…..

{

UserDAO dao = new UserDAO();

dao.set

this.daoManager.execute(dao);

}

…..

DAO Message Logger and Security

To log messages at runtime, the JSPA is using the Log4J library. This logger can raise a security concern in a highly secure application where we don't want confidential information to be written unencrypted to log files when the DEBUG or TRICE level is enabled in a production system. To resolve this problem we provide a simple and efficient solution using the @Secret annotation.

Using @Secret for a field will mask the value of this field in the log files wherever a message about this field is recorded. Field type and name are still recorded but the values of this field will be replaced with “*****”;

One immediate usage is for password fields.

Example:

public class User

{

@OUT(index = 0)

String userID;

@IN(index = 1)

String userName;

@Secret

@IN(index=2)

String password;

.....

}

In TRACE or DEBUG mode the JSPA will produce a logging message like:

… found IN parameter, name: 'password' value: '****' for index 2; …

Integrating JSPA with standalone Java applications

JSPA was designed to be used in enterprise applications running in java application servers. However, JSPA provides a simple DAOManger that handles all database operations that can be easily initialized and used in a standalone application.

To use it in a standalone application you simply create a database Connection or a DataSource and pass any of them to the DAOManager constructors.

public DAOManagerImpl(Connection conn);

public DAOManagerImpl(DataSource conn);

Important note about database connections in a Standalone application.

At the end of the execution, the DAOManager is closing the connections. If you application requires to keep the connection open and reuse the same connection for multiple stored procedures calls you have to wrap the Connection delegating most of the methods and overwrite the close method so that it does not close the connection.

Examples

Example available for download

Please note that a full set of running examples using Oracle stored procedures, including the examples stored procedures code are available for download. The examples available for download include the DAO operations create, delete, update, find and select and also a generic stored procedure and a generic function example using properties with simple types.

The Oracle Arrays as IN/OUT parameters are presented by two of the following examples:

Generic Stored Procedures Examples

Note: The SQL Functions follows the same pattern as a stored procedure.

For SQL Function Return parameter you can use ether @ParameterType.OUT or @ParameterType.FunctionReturn

POJO Stored Procedure with one IN and one OUT String (VARCHAR) parameters Example

// POJO Definition

package org.domain.reqseam.session;

import com.hrx.rasp.util.dao.annotations.DAO;

import com.hrx.rasp.util.dao.annotations.Parameter;

/**

* @author dan.stoica

@DAO(

@Operation( type = OperationType.GENERIC_STORED_PROCEDURE,

name = "VERSION500.DAO_TEST_PK.DAO_TEST")

)

public class SimpleGenericStoredProcTestDAO

{

@IN(index = 1)

private String inParam;

@OUT(index = 2)

private String ouParameter;

public String getInParam()

{

return inParam;

}

public void setInParam(String inParam)

{

this.inParam = inParam;

}

public String getOuParameter()

{

return ouParameter;

}

public void setOuParameter(String ouParameter)

{

this.ouParameter = ouParameter;

}

….

// DAO POJO USAGE

Connection conn = DriverManager.getConnection("....");

DAOManager dm = new DAOManagerImpl(conn);

GenericStoredProcTestDAO dao = new GenericStoredProcTestDAO();

dao.setInParam("any text");

dm.execute(dao);

String out = dao.getOuParameter();

POJO Stored Procedure with IN Oracle ARRAY Example

package org.domain.reqseam.session;

import java.sql.Types;

import java.util.List;

import oracle.jdbc.OracleTypes;

import com.hrx.rasp.util.dao.annotations.DAO;

import com.hrx.rasp.util.dao.annotations.Parameter;

import com.hrx.rasp.util.dao.annotations.ParameterType;

import com.hrx.rasp.util.dao.operation.Operation;

/**

* @author dan.stoica

@DAO(

@Operation(type = OperationType.GENERIC_STORED_PROCEDURE,

name = "VERSION500.DAO_TEST_PK.DAO_TEST_ARRAY_IN")

)

public class GenericArrayInDAO

{

@IN(index = 1, sqlArrayName="VERSION500.DAO_COLLECTION")

private List<String> inArray;

public List<String> getInArray()

{

return inArray;

}

public void setInArray(List<String> inArray)

{

this.inArray = inArray;

}

// DAO POJO USAGE

// get a connection

Connection conn = DriverManager.getConnection("...”);

DAOManager md = new DAOManagerImpl(conn);

GenericArrayInDAO arrDaoTest = new GenericArrayInDAO();

// create a list of String values

List<String> arrVals = new ArrayList<String>();

arrVals.add("val1");

arrVals.add("val2");

arrVals.add("val3");

arrDaoTest.setInArray(arrVals);

// execute the stored procedure

md.execute(arrDaoTest);

POJO Stored Procedure with OUT Oracle ARRAY Example

package org.domain.reqseam.session;

import java.sql.Types;

import com.hrx.rasp.util.dao.annotations.DAO;

import com.hrx.rasp.util.dao.annotations.Parameter;

import com.hrx.rasp.util.dao.annotations.ParameterType;

import com.hrx.rasp.util.dao.operation.Operation;

/**

* @author dan.stoica

@DAO(

@Operation(type = OperationType.GENERIC_STORED_PROCEDURE,

name = â€œVERSION500.DAO_TEST_PK.DAO_TEST_ARRAY_OUT")

)

public class GenericArrayOutDAO

{

@OUT(index = 1, sqlArrayName = "VERSION500.DAO_ARRAY")

private String[] outArray;

/**

* @return the outArray

public String[] getOutArray()

{

return outArray;

}

/**

* @param outArray

* the outArray to set

public void setOutArray(String[] outArray)

{

this.outArray = outArray;

}

// DAO POJO USAGE

//create a JDBC connection

Connection conn = DriverManager.getConnection(â€¦.);

// initialize DAO manager

DAOManager dm = new DAOManagerImpl(conn);

// create a DAO instance

GenericArrayOutDAO arrDaoTest = new GenericArrayOutDAO();

// execute the stored procedure

dm.execute(arrDaoTest);

// read the stored procedure OUT parameter

String[] ret = arrDaoTest.getOutArray();

POJO Stored Procedure with one ResultSet (Oracle CURSOR) OUT parameter

The ResultSet returns a list of Users that is automatic converted by DAOManager in a Java List or Users

import java.sql.Types;

import java.util.List;

import oracle.jdbc.OracleTypes;

import com.hrx.rasp.util.dao.annotations.DAO;

import com.hrx.rasp.util.dao.annotations.Parameter;

import com.hrx.rasp.util.dao.annotations.ParameterType;

import com.hrx.rasp.util.dao.operation.Operation;

@DAO(

@Operation(type = OperationType.GENERIC_STORED_PROCEDURE,

name = “SCHEMA_NAME.DAO_TEST_PK.DAO_GET_USERS_CURSOR")

)

public class GenericCursorOutDAO

{

@OUT(index = 1, sqlType = OracleTypes.CURSOR,

cursorResultClass = Users.class)

private List<ContainerFolders> outCursor;

public List<ContainerFolders> getOutCursor() {

return outCursor;

}

public void setOutCursor(List<ContainerFolders> outCursor) {

this.outCursor = outCursor;

}

….

// the Object returned by the cursor

import java.util.Date;

import javax.persistence.Column;

import javax.persistence.Entity;

@Entity

public class User implements Serializable

{

@Column(name = "USER_ID")

private long userId;

@Column(name = "USER_NAME")

private String name;

@Column(name = "CREATE_DATE")

private Date createdDate;

public User(){

super();

}

public long getUserId(){

return userId;

}

public void setUserId(long userId){

this.userId = userId;

}

public String getName(){

return name;

}

public void setName(String name){

this.name = name;

}

public Date getCreatedDate(){

return createdDate;

}

public void setCreatedDate(Date createdDate){

this.createdDate = createdDate;

}

// DAO POJO USAGE

//create a JDBC connection

Connection conn = DriverManager.getConnection(â€¦.);

// initialize DAO manager

DAOManager dm = new DAOManagerImpl(conn);

// create a DAO instance

GenericArrayOutDAO arrDaoTest = new GenericArrayOutDAO();

// execute the stored procedure

dm.execute(arrDaoTest);

// read the stored procedure OUT parameter

String[] ret = arrDaoTest.getOutArray();

Product Roadmap

1. Automate rollback support in DAOManager using a second POJO for roll back.

2. Test and support for other databases than Oracle database.

3. A simple solution for Oracle Boolean type conversion to Java Boolean type.