Tutorial on Linux + Asterisk +MySQL + Java – part 3

This part of the tutorial begin the explanation of how to interact with Asterisk using Java.

After the introduction about Asterisk and MySQL, I think is right time to get our hands really dirty and begin talk of Java.
I will talk mostly of the use of the WONDERFUL Asterisk-java library. These guys are doing a great job and they keep going to support newer release of Asterisk.

There are basically three way to use Java with Asterisk:

  1. with CRUD operations on the Realtime database (as explained in the previous part);
  2. using AGI (Asterisk Gateway Interface) script, called from asterisk-java
  3. directly from asterisk-java.

In the previous post I have talked only of “realtime” management of the dialplan, but it may be used also for users, peers, and other configurations, with really slight modifications. So, for example, adding or removing records from “extensions” table will modify your current dialplan. But that’s basically just a mix of basic Java (CRUD operations) and Asterisk dialplan knowledge, so I won’t talk of it anymore.

“The Asterisk Gateway Interface is an interface for adding functionality to Asterisk with many different programming languages.” (quoted). Here you may find a tutorial about it – I could not do anything more than just copying thing from there.

Asterisk-java offers other two set of API, the Manager API and the Live API.
The “Manager API” provide and indirect way to send AMI commands to Asterisk, just like you would do with telnet login.
First, you have to enable it on Asterisk editing the “manager.conf” file; the following configuration allow access to “admin” user only from localhost on port 5038:

[general]
enabled = yes
port = 5038
bindaddr = 127.0.0.1
[admin]
secret = secret5
deny = 0.0.0.0/0.0.0.0
permit = 127.0.0.1/255.255.255.255
read = all,system,call,log,verbose,command,agent,user,config
write = all,system,call,log,verbose,command,agent,user,config

Test it with a telnet session (look here for the details – *really* a pain in the back, uh!?).
Now, let’s begin our work of developer.
First, let’s create an *asterisk-java* project. I am slowly moving to Maven, so I will use it to manage the dependencies.
This the asterisk-java artifact (actually, the only one needed for this tutorial):

<dependency>
	<groupId>org.asteriskjava</groupId>
	<artifactId>asterisk-java</artifactId>
	<version>1.0.0.M3</version>
</dependency>

and that’s the pom of my Maven project, automatically generated by Eclipse and with some modifications done by me:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>net.cardosi.asterisktutorial</groupId>
	<artifactId>AsteriskTutorial</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<build>
		<sourceDirectory>src</sourceDirectory>
		<plugins>
			<plugin>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>3.0</version>
				<configuration>
					<source />
					<target />
				</configuration>
			</plugin>
		</plugins>
	</build>
	<dependencies>
		<dependency>
			<groupId>org.asteriskjava</groupId>
			<artifactId>asterisk-java</artifactId>
			<version>1.0.0.M3</version>
			<exclusions>
				<exclusion>
					<groupId>javax.jms</groupId>
					<artifactId>jms</artifactId>
				</exclusion>
				<exclusion>
					<groupId>com.sun.jdmk</groupId>
					<artifactId>jmxtools</artifactId>
				</exclusion>
				<exclusion>
					<groupId>com.sun.jmx</groupId>
					<artifactId>jmxri</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>org.apache.geronimo.specs</groupId>
			<artifactId>geronimo-jms_1.1_spec</artifactId>
			<version>1.1</version>
		</dependency>
	</dependencies>
</project>

Take note of the exclusions. I think Maven is great *when* it works just out of the box but, alas, it is not always so 😦 . In the original asterisk-java dependencies there are some SUN artifacts unavailable from public repositories, so I have excluded them, and that’s fine, at least for our tutorial.
Now, let’s begin actual coding. First of all, you need a *connection* to Asterisk, and the following two lines:

  1. Instantiate a *factory* with connection parameters (the ones defined in the “manager.conf” file);
  2. Create a *connection* from the factory.
     ManagerConnectionFactory factory = new ManagerConnectionFactory(
				"localhost", "admin", "secret5");
     ManagerConnection managerConnection = factory.createManagerConnection();
     try {
	managerConnection.login();
     } catch (Exception e) {
     // Manage exception
     }

The above snippet is equivalent to the login inside a *telnet* connection.
In the following example we will tell Asterisk to call a sip client (with a callerId of “4000”, whose channel is “SIP/4000”) and then, if he accept the call, connect it to a given extension (the extension “600” in the “demo” context, at priority “1”).
First we build the required OriginateAction:

        OriginateAction originateAction = new OriginateAction();
	originateAction.setChannel("SIP/4000");
	originateAction.setCallerId("4000");
	originateAction.setTimeout(30000L); //the default timeout of 30 secs
	originateAction.setContext("demo");
	originateAction.setExten("600");
	originateAction.setPriority(1);

then we send this action through the opened connection, retrieving a *response* at the same time:

        try {
	   ManagerResponse originateResponse = managerConnection.sendAction(
					originateAction, 30000);
        } catch (Exception e) {
           // Manage exception
        }

The value set with

originateAction.setTimeout();

is the time that OriginateAction will wait for the channel to answer before throwing a TimeoutException, while the last parameter of the call

managerConnection.sendAction(originateAction, 30000);

is the time that ManagerConnection will wait for an answer from Asterisk before interrupting the action and throw a TimeoutException. Both times are in milliseconds.
If the command successfully complete before the two timeouts (and without any other errors), ManagerResponse.getResponse() will return “Success”, otherwise if one of the timeouts expire, a TimeoutException will be thrown.
OriginateAction is just one of the possible Actions that may be used with the Manager AMI. All the available ones are in the org.asteriskjava.manager.action package.

Here’s the full test class:

package net.cardosi.asterisk.ami;

import java.io.IOException;
import org.asteriskjava.manager.ManagerConnection;
import org.asteriskjava.manager.ManagerConnectionFactory;
import org.asteriskjava.manager.TimeoutException;
import org.asteriskjava.manager.action.OriginateAction;
import org.asteriskjava.manager.response.ManagerResponse;

public class AMITest {

	public static void main(String[] args) {
		// Retrieve the factory with connection parameters
		ManagerConnectionFactory factory = new ManagerConnectionFactory(
				"localhost", "admin", "secret5");
		// Retrieve the connection from the factory
		ManagerConnection managerConnection = factory.createManagerConnection();
		// Build the action to send
		OriginateAction originateAction = new OriginateAction();
		originateAction.setChannel("SIP/4000");
		originateAction.setCallerId("4000");
		originateAction.setTimeout(30000L); // this is also the default timeout
		originateAction.setContext("demo");
		originateAction.setExten("600");
		originateAction.setPriority(1);
		try {
			// login to Asterisk
			managerConnection.login();
			// sending the action and printing out the result;
			ManagerResponse originateResponse = managerConnection.sendAction(
					originateAction, 30000);
			System.out.println(originateResponse.getResponse());
		} catch (IOException e) {
			// Manage exception
		} catch (TimeoutException e) {
			// Manage exception
		} catch (Exception e) {
			// Manage exception
		}
	}
}

To successfully test all of that, please verify:

  1. you have a sip client correctly connected to your asterisk server;
  2. you can successfully connect to asterisk using the AMI;
  3. you need an extension you are redirecting your sip client to is “visible” for that peer.

And, well, that’s all for now. In the next part we will talk of the Live API: stay tuned!!!

Advertisements

Tutorial on Linux + Asterisk +MySQL + Java – part 2

This part of the tutorial explain how to implement Asterisk’ Realtime functionality with MySQL.

After the brief introduction about LAMJ and the Linux + Asterisk + MySQL + Java, let’s begin to do some configuration.
I’ll not explain the general rules for Asterisk setup on a Linux box, here’s some good starting point:
Asterisk Documentation
Quick Start Guide (pdf)

With the file-based configuration (i.e. all the modifications done to the *.conf files) you setup a static configuration of your PBX – it may be right for you, if you don’t need to change something frequently, mostly in the dialplan.
BUT there is also the chance that you have to do it or, even more funny, you have to write a software that does this for you following the request of an end user.
So, REALTIME to the rescue.
The Realtime function (to be used inside your extensions.conf) allows you to configure your dialplan with data coming from a “RealTime repository” (that is, for me, a database); more interesting is that the modification you are doing in your database are instantly taken by Asterisk (after all, there must be a reason for the “Realtime” term).
One thing to clarify, anyway, is that you may also obtain “realtime” configuration only using Java (we will see that in later post) but the configuration will not persist (unless, after a very heavy dinner, a lot of drinks, and a sleepless night full of nightmares, you decided to programmatically edit the .conf files!!!).

Now, since the LAMJ imply the MySQL support, I will explain only this part of the configuration.
To cut a long story short, you have to:

  1. Have the res_config_mysql.so (it is part of the “asterisk add-ons” – don’t ask me why; explaining how to get or build it is part of a lot of other tutorials);
  2. Create the database and grant privileges to a given userΒ (in this tutorial “asterisk” will be used as database name, user name, and user password: exceptionally secure, uh?! πŸ™‚ )
  3. Create the dialplan table (“extensions” in this tutorial):

    CREATE TABLE `extensions` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `context` varchar(20) NOT NULL DEFAULT '',
    `exten` varchar(20) NOT NULL DEFAULT '',
    `priority` varchar(10) NOT NULL,
    `app` varchar(20) NOT NULL DEFAULT '',
    `appdata` varchar(128) NOT NULL DEFAULT '',
    PRIMARY KEY (`context`,`exten`,`priority`),
    KEY `id` (`id`)
    );
  4. Edit the “res_config_mysql.conf” file with the connection parameters to the database, beside a specific [section-name] (“asterisk-section” in this tutorial)

    [asterisk-section]
    dbhost = 127.0.0.1
    dbname = asterisk
    dbuser = asterisk
    dbpass = asterisk
    dbport = 3306
    dbsock = /var/run/mysqld/mysqld.sock
    dbcharset = latin1
    requirements=warn
  5. Add to the “extconfig.conf” file a line with the format
    <family> => <realtime driver>,<[section-name]>[,<table>]
    to specify that for a given configuration the given repository will be used; in our tutorial we will focus on dialplan configuration (whose family is “extensions”) with MySQL (whose realtime driver is “mysql”), like this:
    extensions => mysql,asterisk-section,extensions
    WARN: this is different from old versions of asterisk, where instead of the [section-name] you have to put the database name (that would have been “asterisk” in this tutorial); I can’t tell exactly when this has changed, but in 1.6 it was different;
  6. Add a “switch” directive in “extensions.conf” (the dialplan configuration file):

    switch => Realtime/conference@extensions

    please note that “conference” in the above line is the “context” to be loaded, and it must match the value you put in the “context” column inside the “extensions” table; you may have more than one switch, one for each “context” you want to be managed in realtime;
  7. Be sure to load the “res_config_mysql” module, and the others required for realtime to work; this can be done inside “modules.conf” file with this simple directive:

    autoload=yes

If everything is correct, when you reload or restart asterisk you should see in the console a line containing “Registered Config Engine mysql”; if not, check everything from beginning.
Using “dialplan show” in the asterisk CLI you should also have the entry:

Alt. Switch => 'Realtime/conference@extensions'
Check your “extensions.conf” if you don’t see it.
Now, as far as I can tell there is no direct way to see the “realtime” extensions from the CLI: you have to test it with a sip client. The following .sql snippet define an “echo” extension at 6878@conference:

INSERT INTO extensions (context, exten, priority, app, appdata) VALUES ("conference", "6878", "1", "Playback", "demo-echotest");
INSERT INTO extensions (context, exten, priority, app, appdata) VALUES ("conference", "6878", "2", "Echo", "");
INSERT INTO extensions (context, exten, priority, app, appdata) VALUES ("conference", "6878", "3", "Playback", "demo-echodone");
INSERT INTO extensions (context, exten, priority, app, appdata) VALUES ("conference", "6878", "4", "Hangup", "");

After inserted this records in the database (no need to reload – that’s realtime magic!) dialing “6878” from your sip client should enter you in echo test. A couple of things to keep in mind:

  1. “demo-echotest” and “demo-echodone” are audio files that you should have in your “sound” directory
  2. the sip peer should be registered with the context containing the “switch” directive, otherwise he won’t be able to access the realtime-configured context.

Well, I hope everything is clear enough for you to go on. Again, I am not diving too much in asterisk basics because the main focus of this tutorial will be hit in the following parts regarding java. Anyway, you are more than welcome to post your questions or to point me to the silly mistakes I may have done.
In the next part we will begin with actual Java coding: don’t miss it!!!

Tutorial on Java code generation with CodeModel – Inheritance

This part of the tutorial is about Inheritance management with CodeModel.

Now that we have covered basics, javadoc, jexpressions and generics, let’s take a look at how to manage inheritance with CodeModel.

First things first, let’s build an Interface. Actually, is not very different from building a normal Class: we simply have to pass a specific parameter ClassType.INTERFACE to the usual method. As a plus, let’s add some methods and javadocs:

  
        String interfaceName = "net.cardosi.MyNewInterface";
        JDefinedClass definedInterface = codeModel._class(interfaceName,             ClassType.INTERFACE);
        JDocComment javadoc = definedInterface.javadoc();
        String commentString = "My wonderful Interface";
        javadoc.append(commentString);
        String methodName = "toBeImplemented";
	JMethod method = definedInterface.method(JMod.PUBLIC, void.class, methodName);
	javadoc = method.javadoc();
	commentString = "Method to be implemented";
	javadoc.append(commentString);
	codeModel.build(new File("."));

And here’s the result:

package net.cardosi;

/**
 * My wonderful Interface
 * 
 */
public interface MyNewInterface {

    /**
     * Method to be implemented
     * 
     */
    public void toBeImplemented();

}

Now, we want to create an Abstract class that implements the interface just created. In this case, though, we have to use another different form of the usual method:

     codeModel._class(int mods, String name, ClassType classTypeVal)

“Where this ‘mods’ come from?” the most curios of you will surely asks themselves. Well, they are defined inside com.sun.codemodel.JMod and the value actually given must be the sum of all the JMods you want to define. So, if you want to generate an Abstract Protected class, you should use

      int mods = JMod.Abstract + JMod.PROTECTED;

.

Back to our example, we use only the JMod.Abstract modifier, because we want the default access level:

        String abstractName = "net.cardosi.MyNewAbstract";
	int mods = JMod.ABSTRACT;
	JDefinedClass abstractClass = codeModel._class(mods, abstractName,
					ClassType.CLASS)._implements(definedInterface);
	JDocComment comment = abstractClass.javadoc();
	commentString = "The <code>" + abstractName + "</code> implementing the "  + interfaceName + "interface";
	comment.append(commentString);
        codeModel.build(new File("."));

And here’s the generated Abstract class

package net.cardosi;

/**
 * The <code>net.cardosi.MyNewAbstract</code> implementing the <code>net.cardosi.MyNewInterface</code> interface
 * 
 */
abstract class MyNewAbstract implements MyNewInterface {


}

Now, last but not least, we want to build a new Class that extends the Abstract one just created and, since we are getting greedy, also implements another Interface, like Iterator<T>. Remember that we have to implement all the methods from MyNewInterface and Iterator<T> and that we have to work with Generic as in the previous part:

        String concreteName = "net.cardosi.MyNewConcrete";
	String genericTypeName = "T";
	JClass genericT = codeModel.ref(genericTypeName);
	JClass rawInterface = codeModel.ref(Iterator.class);
	JClass genericInterface = rawInterface.narrow(genericT);
	JDefinedClass concreteClass = codeModel._class(concreteName)
				._implements(genericInterface)._extends(abstractClass);
	concreteClass.generify(genericTypeName);
	javadoc = concreteClass.javadoc();
	commentString = "My concrete implementation";
	javadoc.append(commentString);
	method = concreteClass.method(JMod.PUBLIC, void.class, methodName);
	javadoc = method.javadoc();
	commentString = "Method implementation";
	javadoc.append(commentString);
	method.body().directStatement("System.out.println("Hello World!");");
	method = concreteClass.method(JMod.PUBLIC, boolean.class, "hasNext");
	method.body().directStatement("// TODO To be implemented");
	method.body()._return(JExpr.TRUE);
	javadoc = method.javadoc();
	commentString = "Method implementation";
	javadoc.append(commentString);
	method = concreteClass.method(JMod.PUBLIC, genericT, "next");
	method.body().directStatement("// TODO To be implemented");
	method.body()._return(JExpr._null());
	javadoc = method.javadoc();
	commentString = "Method implementation";
	javadoc.append(commentString);
	method = concreteClass.method(JMod.PUBLIC, void.class, "remove");
	method.body().directStatement("// TODO To be implemented");
	javadoc = method.javadoc();
	commentString = "Method implementation";
	javadoc.append(commentString);
        codeModel.build(new File("."));

And here’s the final result:

package net.cardosi;

import java.util.Iterator;

/**
 * My concrete implementation
 * 
 */
public class MyNewConcrete extends MyNewAbstract implements Iterator {

	/**
	 * Method implementation
	 * 
	 */
	public void toBeImplemented() {
		System.out.println("Hello World!");
	}

	/**
	 * Method implementation
	 * 
	 */
	public boolean hasNext() {
		// TODO To be implemented
		return true;
	}

	/**
	 * Method implementation
	 * 
	 */
	public T next() {
		// TODO To be implemented
		return null;
	}

	/**
	 * Method implementation
	 * 
	 */
	public void remove() {
		// TODO To be implemented
	}
}

And that’s all for now. See you soon!!!

Tutorial on Java code generation with CodeModel – Generics

This part of the tutorial is about Generics management with CodeModel.

Now that we have covered basics, javadoc and jexpressions, let’s take a look at how to manage Generics with CodeModel.

First of all, to make a class Generic you have to call the following method to the JDefinedClass created to build it:

 
     JDefinedClass.generify(String name); 

Let’s see actual code and result:

 
        String concreteName = "net.cardosi.MyNewGenericClass";
        String genericTypeName = "T";
	JClass genericT = codeModel.ref(genericTypeName);
        JDefinedClass concreteClass = codeModel._class(concreteName);
	concreteClass.generify(genericTypeName);
 
package net.cardosi;

public class MyNewGenericClass<T> {

}

Now, let’s add a “generic” field to it.. let’s see… maybe a List? For this we need a reference to:

  • A JClass representing the type parameter (“T” in our example);
  • A JClass representing the raw interface (“List” in our example);
  • A JClass representing the interface’ generic type (“List<T>” in our example);
  • A JClass representing the raw implementation of the interface (“ArrayList” in our example);
  • A JClass representing the implementation’ generic type of the interface (“ArrayList<T>” in our example);

With all that, we can define and instantiate a Generic field

 
        JClass genericT = codeModel.ref(genericTypeName);
	JClass rawLLclazz = codeModel.ref(List.class);
	JClass fieldClazz = rawLLclazz.narrow(genericT);
	JClass rawArrayListClass = codeModel.ref(ArrayList.class);
	JClass arrayListFieldClazz = rawArrayListClass.narrow(genericT);
	JExpression newInstance = JExpr._new(arrayListFieldClazz).arg(JExpr.lit(0));
	String listFieldString = "genericList";
	JFieldVar listFieldVar = concreteClass.field(JMod.PRIVATE, fieldClazz, listFieldString);
	listFieldVar.init(newInstance);

Here’s what we get (note that the imports are automatically generated by CodeModel:

 
package net.cardosi;

import java.util.ArrayList;
import java.util.List;

public class MyNewGenericClass<T>{

    private List<T> genericList = new ArrayList<T>(0);

}

Last thing to do, now, is to provide a method to insert something in our List. It is not different from what we saw in Basics, but we have to use the JClass representing the type parameter. More over, we have to “literally” invoke the method “add” on the reference to the list field:

 
	String adderParameterString = "toAddParam";
	JVar adderParam = method.param(genericT, adderParameterString);
	method.body().invoke(JExpr.ref(listFieldString), "add")
					.arg(adderParam);

Generated method:

 
	public void addGeneric(T toAddParam) {
             genericList.add(toAddParam);
        }

Here’s all the relevant code (javadoc generation included) and the generated class:

 
	String concreteName = "net.cardosi.MyNewGenericClass";
	String genericTypeName = "T";
	JClass genericT = codeModel.ref(genericTypeName);
	JDefinedClass concreteClass = codeModel._class(concreteName);
	concreteClass.generify(genericTypeName);
	JDocComment javadoc = concreteClass.javadoc();
	String commentString = "My wonderful Generic class";
	javadoc.append(commentString);
	JClass rawLLclazz = codeModel.ref(List.class);
	JClass fieldClazz = rawLLclazz.narrow(genericT);
	JClass rawArrayListClass = codeModel.ref(ArrayList.class);
	JClass arrayListFieldClazz = rawArrayListClass.narrow(genericT);
	JExpression newInstance = JExpr._new(arrayListFieldClazz).arg(JExpr.lit(0));
	String listFieldString = "genericList";
	JFieldVar listFieldVar = concreteClass.field(JMod.PRIVATE, fieldClazz, listFieldString);
	listFieldVar.init(newInstance);
	javadoc = listFieldVar.javadoc();
	commentString = "My Generic List<T>";
	javadoc.append(commentString);
	String methodName = "addGeneric";
	JMethod method = concreteClass.method(JMod.PUBLIC, void.class, methodName);
	javadoc = method.javadoc();
	commentString = "Method to add a Generic T to our List<T>";
	javadoc.append(commentString);
	String adderParameterString = "toAddParam";
	JCommentPart commentPart = javadoc.addParam(adderParameterString);
	JVar adderParam = method.param(genericT, adderParameterString);
	commentString = "The T to add.";
	commentPart.append(commentString);
	method.body().invoke(JExpr.ref(listFieldString), "add").arg(adderParam);
	codeModel.build(new File("."));
package net.cardosi;

import java.util.ArrayList;
import java.util.List;

/**
 * My wonderful Generic class
 * 
 */
public class MyNewGenericClass{

    /**
     * My Generic List<T>
     * 
     */
    private List genericList = new ArrayList(0);

    /**
     * Method to add a Generic T to our List<T>
     * 
     * @param toAddParam
     *     The T to add.
     */
    public void addGeneric(T toAddParam) {
        genericList.add(toAddParam);
    }

}

Don’t miss the next part about
Inheritance. C YA!!!

SVN to GIT with Eclipse

Hi all,

after a lot of hesitation I finally decided to move my VCS from dear old Subversion to GIT, and so the repository of my projects. I still am a “noob” about GIT, but my latest experience with SVN in a team (the “merge” nightmare: sounds familiar?) definitely persuaded me.
I won’t dive in the GIT philosophy and functionality (here’s a really well written and free book: Pro Git by Scott Chacon). The only thing I would underline, though, is that GIT is conceptually really different from Subversion; so, you have to get used to that and to keep in mind that in this two VCS the same terms and operations (may) mean and works in different way.

Now, back to topic, after reading some basics, I thought I was ready for the big jump, so my very first step was to move my repositories from SVN to GIT. I have my own server with both Subversion and GIT servers, so as prerequisite you should set up your own Central repository (well, of course you may also use GitHub).
The “committer” (ie, the developer that commit its work on the central repository) should have an ssh access to the server that hosts the repository.
Then, inside Eclipse, the EGit plugin is required.

Here’s a quick step-by-step guide

1) From the “Package Explorer” view remove SVN usage (Team -> Disconnect) from your project, checking “Also delete SVN meta information from file system”svntogit_1

2) Share project with GIT (Team -> Share Project…); click “Create” button to create a new repository (for example /(USER_HOME)/git/(PROJECT_NAME)) – keep in mind that the working directory (i.e. where the sources are stored) will be moved INSIDE this one, so you will have a Target location like /(USER_HOME)/git/(PROJECT_NAME)/(PROJECT_NAME) – your original “working directory” (for example, the one inside the Eclipse workspace) will be deleted; be sure to UNCHECK “create repository inside parent folder”
3) All the files will be shown with a question mark because they are all untracked; moreover, beside the name of the project “NO-HEAD” will be shown
svntogit_6
4) Switching to “Git Repositories” view, the newly created repository will appear; take note that for the moment being “Branches” folders (“Local” and “Remote Tracking”) and “Remotes” are emptysvntogit_7

5) on SERVER, create a new bare repository; for convention bare repositories names end with “.git”, so a good name could be (PROJECT_NAME).git

  • git init –bare (REPO_NAME)

6) check permissions: repository’ directory should be owned by the server’s “git” user, and belong to a group of which the “committer” user is part; moreover, the repository must be “shared” (the following commands are related to Linux machines)

  • sudo chmod -R g+ws (REPO_NAME)
  • sudo chown -R (git_user):(git_group) (REPO_NAME)
  • cd (REPO_NAME)
  • git config core.sharedRepository true

7) Done with the server and back to Eclipse; now we have to link our local repository to the Central one just created, and to allow secure access, we will use the “ssh” protocol; from “Git Repositories” view right click on your repository “Remotes” and select “CreateRemote..:”; let’s keep default settings (“Remote name”: origin and “Configure push” checked)

svntogit_8
8) In the following screen, click “Change” to insert the connection URI:

svntogit_9
9) In the next screen, insert the URI of the Central repository in the following format ssh://(username)@(server_address)(:port)/FULL_PATH_TO_REPO_NAME (the one created at point 6) and then click “Finish”
svntogit_10
10) Now that we are back to the previous screen with the correct URI, click “Save” and close it
svntogit_1111) Back to “Package Explorer” view, Right click on the project (it should still have the question marks, meaning it has something to commit”) and select “Team -> Commit”

svntogit_12
12) From here, click on “Commit and Push”: an authentication window will eventually appear if you did not save your password at point 9 or if your ssh is configured with preshared keys; after successful “login” a “Results” window will show

svntogit_1313) Well, we have almost done; now we have to configure “Fetch”; from “Git Repositories” expand your project repository, under Remotes right click on “origin” and click on “Configure Fetch…”

svntogit_14
14) Click on “Advanced” and as “Source ref” select “refs/heads/master”, while for “Destination ref” set “refs/remotes/origin/master”

svntogit_1515) Click on the button “Add Spec” to insert the mapping just created:

svntogit_1616) Click on “Finish” to save the mapping and close the window; now the “Configure Fetch” window of point 13 will show the mapping just created:

svntogit_1717) Click on “Save”; WE HAVE DONE!!!!!!

 

After all, it is not *that* hard. There a lot of details I have not covered. The book I have pointed to in the preface (Pro Git) it is all about command line, so maybe it would be a good starting point to first learn at least the basic of GIT using the command line; then the operations we have done would be much clearer.
I have found a lot of forum and posts of people getting litterally crazy with GIT, or EGit, to the point to leave it be. I can not criticize them because it is what happened (and still happen) to me too. In my humble opinion, GIT require a significant change in the way we deal with VCS, but I think it is worth the effort (hey, after all Linus Torvalds made it, and the Linux kernel is managed by it: there must be a good reason!).

Finally, here’s the link to full guide to Egit.
I hope you enjoyed the tutorial. See you soon!

 

Tutorial on Java code generation with CodeModel – JExpression

This part of the tutorial is about JExpr and JExpression in CodeModel.

In the previous post I have used the JExpr class to write assignment code inside the body of some methods. Well, I must confess that I found JExpr and JExpression really hard to understand (let’s say this plainly: documentation did not help a bit, in this case).
From official documentation we could see that

“JExpression defines a series of composer methods, which returns a complicated expression (by often taking other JExpressions as parameters. For example, you can build “5+2″ by JExpr.lit(5).add(JExpr.lit(2))”
and, about JExpr:
“Factory methods that generate various JExpressions.”

Some example of JExpr (static) methods are:

  • _null();
  • _super(): Returns a reference to “super”, an implicit reference to the super class.
  • _this(): Returns a reference to “this”, an implicit reference to the current object.

So, easy enough, when you need a reference to one of this, you have to use the JExpr method that, in turn, return a JExpression that represent it.

The following snippet creates a constructor method that accept an int as parameter, and we assign this parameter to a private field:

        
        String className = "net.cardosi.MyNewClassD";
	JDefinedClass definedClass = codeModel._class(className);
	String fieldName = "intVar";
	JFieldVar field = definedClass.field(JMod.PRIVATE, int.class, fieldName);
	JMethod constructorMethod = definedClass.constructor(JMod.PUBLIC);
	String intVarParameter = "intVarParam";
	constructorMethod.param(int.class, intVarParameter);
	JBlock block = constructorMethod.body();
	block.assign(JExpr._this().ref(fieldName), JExpr.ref(intVarParameter));

Here’s the resultant code:

package net.cardosi;

public class MyNewClassD {

    private int intVar;

    public MyNewClassD(int intVarParam) {
        this.intVar = intVarParam;
    }
}

I know I could have avoided the this reference, in this case, but anyway…
Another interesting detail is the use of JExpr.ref(), that’s needed to retrieve a reference to a given field (more exactly, it returns a JFieldRef reference for a field with a given name). So, the line:
block.assign(JExpr._this().ref(fieldName), JExpr.ref(intVarParameter));
assign the value of the field referenced by intVarParameter (in this case, a method’ parameter) to the field referenced by fieldName of the this object.

Another use of JExpr could be the creation of a JExpression representing a literal (boolean, double, float, char, int, long, and String):

        
        String className = "net.cardosi.MyNewClassD";
	JDefinedClass definedClass = codeModel._class(className);
	String stringName = "stringVar";
	JFieldVar stringField = definedClass.field(JMod.PRIVATE, String.class, stringName);
	JMethod constructorMethod = definedClass.constructor(JMod.PUBLIC);
	JBlock block = constructorMethod.body();
	block.assign(JExpr._this().ref(stringName), JExpr.lit("DEFAULT VALUE"));

Here’s the newly generated class, where the “stringVar” is initialized with “DEFAULT VALUE” inside the constructor:

package net.cardosi;

public class MyNewClassD {

    private String stringVar;

    public MyNewClassD() {
        this.stringVar = "DEFAULT VALUE";
    }
}

Now, it’s time to look at JExpression a little bit closer. Like JExpr has static methods to retrieve some specific JExpressions, JExpression has instance methods to retrieve specific JExpressions.
Let’s start with one of the simplest:
JExpression.not(); that returns a “!” (Who may have guessed it ?)
In the following modification of the same beloved code, we create a boolean field and inside the constructor we assign to it the negation of a boolean parameter:

        String className = "net.cardosi.MyNewClassE";
	JDefinedClass definedClass = codeModel._class(className);
	String booleanName = "booleanVar";
	JFieldVar booleanField = definedClass.field(JMod.PRIVATE, boolean.class, booleanName);
	JMethod constructorMethod = definedClass.constructor(JMod.PUBLIC);
	String booleanVarParameter = "booleanVarParameter";
	constructorMethod.param(boolean.class, booleanVarParameter);
	JBlock block = constructorMethod.body();
	block.assign(JExpr._this().ref(booleanName), JExpr.ref(booleanVarParameter).not());
	codeModel.build(new File("."));

Here the result:

package net.cardosi;

public class MyNewClassE {

    private boolean booleanVar;

    public MyNewClassE(boolean booleanVarParameter) {
        this.booleanVar = (!booleanVarParameter);
    }
}

The line:
block.assign(JExpr._this().ref(booleanName), JExpr.ref(booleanVarParameter).not());

  1. retrieve a JExpression referencing the booleanVarParameter
  2. apply a “negation” to that reference
  3. assign the resulting value to the field referenced by booleanName.

Ah! Now we are cooking! And, what about creating an integer variable with a default value, and then give to it the sum of another value and a number ?

        String className = "net.cardosi.MyNewClassF";
	JDefinedClass definedClass = codeModel._class(className);
	String intName = "intVar";
	JFieldVar intField = (JFieldVar) definedClass.field(JMod.PRIVATE, int.class, intName).init(JExpr.lit(14));
	JMethod constructorMethod = definedClass.constructor(JMod.PUBLIC);
	String intVarParameter = "intVarParameter";
        constructorMethod.param(int.class, intVarParameter);
	JBlock block = constructorMethod.body();
	block.assign(JExpr._this().ref(intName), JExpr.ref(intVarParameter).plus(JExpr.lit(35)));
	codeModel.build(new File("."));

Here it is

package net.cardosi;


public class MyNewClassF {

    private int intVar = 14;

    public MyNewClassF(int intVarParameter) {
        this.intVar = (intVarParameter + 35);
    }
}

As a plus I have included the initialization of the variable in its declaration:
JFieldVar intField = (JFieldVar) definedClass.field(JMod.PRIVATE, int.class, intName).init(JExpr.lit(14));
Since JExpr.lit() is overloaded for different kind of literals (boolean, double, float, char, int, long, and String), the corresponding type of variables can be initialized that way.

Maybe I was a little bit pedantic in this section of the tutorial, but in the same time I have the impression to have just scratched the surface of JExpr and JExpression.
Anyway, I hope it will be enough for you as starting point.
Next part will deal with Generics: don’t miss it!!!

Tutorial on Linux + Asterisk +MySQL + Java – part 1

This part of the tutorial is an introduction about the combined use of Asterisk, Java and MySQL on a Linux box.

In the internet era Linux has a very important role for the famous LAMP stack: Linux + Apache + MySQL + PHP.

But I am not a web-type; I had some of the greatest fun working with VoIP/PBX, more specifically with Asterisk, so I decided to share my experience, and I named the environment I have worked with LAMJ, which stands for Linux + Asterisk + MySQL + Java.
I won’t talk about Linux and MySQL, but I will give a very brief introduction about PBX.

PBX is the acronym of Private Branch Exchange. It could refer to a hardware device or to a software running on a computer. Asterisk is one of the most diffused software PBX, but there are also others, like Callweaver and FreeSWITCH (well, FreeSWITCH is not exactly a PBX, it’s author describe it as a soft switch in his comparison with Asterisk).
VoIP stands for Voice Over IP.
Technically VoIP and PBX are not dependent one to the other. A PBX could be connected only to a PSTN or only to a VoIP network. The third option, the one that I found most interesting, is that a PBX could be connected to both a PSTN and a VoIP network, acting as a sort of bridge between the twos.
This is not to be confused with PSTN/VoIP Gateway, where the communication is forwarded from PSTN to VoIP (and the other way around).
A software PBX could be connected to communication channel(s) in one or more of the following ways:

  1. with the computer’s internet connection
  2. with an internal card (Digium, Sangoma, Rhino, etc)
  3. with a Channel bank
  4. with a Gateway (internal or from an external provider) to which it is connected via ethernet/internet.

Currently there are different VoIP protocols, the most known being SIP, IAX, and H.323.
Probably SIP protocol is the most widely used, at least for connection between end-user device/software and PBX, even if it may require some tweaking to overcome NAT issues, while IAX maybe has better performance, but it is used mostly for inter-PBX communication.
Please keep in mind that I am a developer, not a network/VoIP engineer, so feel free to correct me if I wrote something wrong in the above introduction.

In the next part we will cover the Realtime configuration. C YA!!!

Tutorial on Java code generation with CodeModel – Javadoc

This part of the tutorial is about Javadoc generation with CodeModel.

What is Java code without Javadoc? Surely none of you will ever think to write a class or a method without a properly formatted and meaningful documentation… or not ?

Well, of course CodeModel does not leave you alone in this task; let’s see how.
Here’s the source of JDocCommentable interface:

package com.sun.codemodel;

/**
 * Program elements that can have Javadoc
 * 
 * @author Jonas von Malottki
 */
public interface JDocCommentable {
    /**
     * @return the JavaDoc of the Element
     */
    JDocComment javadoc();
}

As the smartest of you may have already guessed, JDocComment returned by javadoc() method is the class to use to create javadocs. Note that this interface is implemented by all the classes that generate *javadoc-able* elements (classes, enums, variables, methods, packages).
To write something in the created comment we use the method JDocComment.append(Object).
So, the code needed to comment a class declaration is something like this:

String className = "net.cardosi.MyNewClass";
JDefinedClass definedClass = codeModel._class(className);
JDocComment comment = definedClass.javadoc();
String commentString = "My wonderful class";
comment.append(commentString);

and here’s the generated code, in all its splendor:

package net.cardosi;

/**
 * My wonderful class
 * 
 */
public class MyNewClass {
   ...
}

The same goes for variables:

String fieldName = "intVar";
String fieldNameWithFirstLetterToUpperCase = "IntVar";
JFieldVar field = definedClass.field(JMod.PRIVATE, int.class, fieldName);
JDocComment comment = field.javadoc();
String commentString = "My int variable";
comment.append(commentString);

But, ehy! What about parameters, returned values and stuff like that?
No worry, guys. JDocComment has different methods to retrieve a JCommentPart specifically suited for each one.
For example, this is to write a simple setter method documentation, with a single parameter description:

JMethod setterMethod = definedClass.method(JMod.PUBLIC, Void.TYPE, setterMethodName);
JDocComment comment = setterMethod.javadoc();
String commentString = "Method to set " + fieldName + "";
comment.append(commentString);
String setterParameter = "intVarParam";
JCommentPart commentPart = javadoc.addParam(setterParameter);
commentString = "The " + fieldName + " to set.";
commentPart.append(commentString);

For return descriptions we have just to retrieve JCommentPart with JDocComment.addReturn():

JMethod getterMethod = definedClass.method(JMod.PUBLIC, int.class, getterMethodName);
JDocComment comment = getterMethod.javadoc();
String commentString = "Method to get " + fieldName + "";
comment.append(commentString);
JCommentPart commentPart = javadoc.addReturn();
commentString = "The " + fieldName + ".";
commentPart.append(commentString);

JDocComment has also methods to retrieve JCommentPart to generate Deprecated, Throws, and XDoclet parts, but they works the same way, so I won’t describe them here.

Now, if you followed the tutorial from the beginning, you should have something like this (well, I know it’s getting ugly…)

JCodeModel codeModel = new JCodeModel();
		try {
			String className = "net.cardosi.MyNewClass";
			JDefinedClass definedClass = codeModel._class(className);
			JDocComment comment = definedClass.javadoc();
			String commentString = "My wonderful class";
			comment.append(commentString);
			String fieldName = "intVar";
			String fieldNameWithFirstLetterToUpperCase = "IntVar";
			JFieldVar field = definedClass.field(JMod.PRIVATE, int.class,
					fieldName);
			comment = field.javadoc();
			commentString = "My int variable";
			comment.append(commentString);
			String getterMethodName = "get"
					+ fieldNameWithFirstLetterToUpperCase;
			JMethod getterMethod = definedClass.method(JMod.PUBLIC, int.class,
					getterMethodName);
			comment = getterMethod.javadoc();
			commentString = "Method to get " + fieldName + "";
			comment.append(commentString);
			JCommentPart commentPart = javadoc.addReturn();
			commentString = "The " + fieldName + ".";
			commentPart.append(commentString);
			JBlock block = getterMethod.body();
			block._return(field);
			String setterMethodName = "set"
					+ fieldNameWithFirstLetterToUpperCase;
			JMethod setterMethod = definedClass.method(JMod.PUBLIC, Void.TYPE,
					setterMethodName);
			comment = setterMethod.javadoc();
			commentString = "Method to set " + fieldName + "";
			comment.append(commentString);
			String setterParameter = "intVarParam";
			commentPart = javadoc.addParam(setterParameter);
			commentString = "The " + fieldName + " to set.";
			commentPart.append(commentString);
			setterMethod.param(int.class, setterParameter);
			setterMethod.body().assign(JExpr._this().ref(fieldName),
					JExpr.ref(setterParameter));
			codeModel.build(new File("."));
		} catch (JClassAlreadyExistsException e) {
			// ...
		} catch (IOException e) {
			// ...
		}

and here’s the commented class:

package net.cardosi;

/**
 * My wonderful class
 * 
 */
public class MyNewClass {

    /**
     * My int variable
     * 
     */
    private int intVar;

    /**
     * Method to get intVar
     * 
     * @return
     *     The intVar.
     */
    public int getIntVar() {
        return intVar;
    }

    /**
     * Method to set intVar
     * 
     * @param intVarParam
     *     The intVar to set.
     */
    public void setIntVar(int intVarParam) {
        this.intVar = intVarParam;
    }

}

Don't miss the next part about JExpression!

Tutorial on Java code generation with CodeModel – Basics

This part of the tutorial is about basic Java code generation using CodeModel.

My current job is all about ETL – i.e. I have to transform flat formatted data to xml and back again… exciting, uh?

Anyway, my first step was to write classes to reflect the different type of “records” that could be part of the flat file, but the “specification” for the structure keep changing (sounds familiar ?). Being absolutely lazy I realized that I needed something to generate that code for me!
Surely there are many other frameworks I am not aware of, maybe even better, but I found out CodeModel and decided to give it a try, also because it is used (beyond the scene) by JAXB – the library I am using to do xml-related stuff.
As for other stuff from glassfish site, I think its pretty good, but the documentation could have been more developer-friendly.
So, I write down this little tutorial for other people that want to use this nice library.

For this guide I will use codemodel-2.4.jar, that could be downloaded from here http://download.java.net/maven/2/com/sun/codemodel/codemodel/2.4/.

The very first steps are:

1) instantiate the root of the code DOM;
2) use it to create the class;

This is done in a couple of lines:

JCodeModel codeModel = new JCodeModel();
JDefinedClass definedClass = codeModel._class("ClassName");

Keep note that the name of the defined class should be the fully qualified name (i.e. with the package declaration).

The actual “java” file will be written calling the method

JCodeModel.build(File destDir);

The bare minimum code needed to generate an (absolutely empty) “java” file looks like this:

JCodeModel codeModel = new JCodeModel();
try {
        JDefinedClass definedClass = codeModel._class("net.cardosi.MyNewClass");
	codeModel.build(new File("."));
} catch (JClassAlreadyExistsException e) {
   // ...
} catch (IOException e) {
   // ...
}

and here’s the generated file that you will found in the net/cardosi/ folder:

package net.cardosi;

public class MyNewClass {

}

Surely we would like to add some field to this class, and here’s the needed method provided by JDefinedClass:

JDefinedClass.field(int mods, Class<?> type, String name)

The first parameter define the accessor modificator (Public, Private, etc.), the second one is to tell the Class of the variable to be generated, and the third one is for the field name.

Let’s add an int called “intVar” to our class:

JCodeModel codeModel = new JCodeModel();
try {
     JDefinedClass definedClass = codeModel._class("net.cardosi.MyNewClass");
     codeModel.build(new File("."));
     JFieldVar field = definedClass.field(JMod.PRIVATE, int.class, "intVar");
} catch (JClassAlreadyExistsException e) {
   // ...
} catch (IOException e) {
   // ...
}

and let’s see the result:

package net.cardosi;

public class MyNewClass {
  private int intVar;
}

of course it is possible to initialize the field with a “default” value:

JFieldVar.init(JExpression init);

and it is possible to create getter and setter for it

// Create the getter method and return the JFieldVar previously defined
JMethod getterMethod = definedClass.method(int mods, Class<?> type, String name);
JBlock block = getterMethod.body();
block._return(field);
// Create the setter method and set the JFieldVar previously defined with the given parameter
JMethod setterMethod = definedClass.method(int mods, Class<?> type, String name);
setterMethod.param(int.class, "intParam");		setterMethod.body().assign(JExpr._this().ref("intVar"), JExpr.ref("intParam"));

While I found most the code-related stuff we have seen until now pretty intuitive to understand (JDefinedClass, JFieldVar, JMethod and JBlock), I do not mind to tell you I had my problems with JExpression and JExpr, and surely we will give them more attention.
But now let’s review the code we have written until now

JCodeModel codeModel = new JCodeModel();
try {
     String className = "net.cardosi.MyNewClass";
     JDefinedClass definedClass = codeModel._class(className);
     String fieldName = "intVar";
     String fieldNameWithFirstLetterToUpperCase = "IntVar";
     JFieldVar field = definedClass.field(JMod.PRIVATE, int.class, fieldName);
     String getterMethodName = "get" + fieldNameWithFirstLetterToUpperCase;
     JMethod getterMethod = definedClass.method(JMod.PUBLIC, int.class, getterMethodName);
     JBlock block = getterMethod.body();
     block._return(field);
     String setterMethodName = "set" + fieldNameWithFirstLetterToUpperCase;
     JMethod setterMethod = definedClass.method(JMod.PUBLIC, Void.TYPE, setterMethodName);
     String setterParameter = "intVarParam";
     setterMethod.param(int.class, setterParameter);
    setterMethod.body().assign(JExpr._this().ref(fieldName), JExpr.ref(setterParameter));
     codeModel.build(new File("."));
} catch (JClassAlreadyExistsException e) {
   // ...
} catch (IOException e) {
   // ...
}

And here’s the generated class

package net.cardosi;

public class MyNewClass {

    private int intVar;

    public int getIntVar() {
        return intVar;
    }

    public void setIntVar(int intVarParam) {
        this.intVar = intVarParam;
    }

}

Don’t miss the next part about Javadoc!

Generics with Hibernate – part II

In the previous post I have shown how to couple Hibernate and Generics to write all the code needed for CRUD operations in (basically) one class.
Forgive me a little digression. Few months ago I was working on a project (written by someone else, of course); one of the admin recreated the database we where using on a different place and: BANG! the application stopped working. To cut a long (and sad) story short, the previous developer have had the brilliant idea to put a lot of triggers inside the database to store backup data during CRUD operations. But when the admin recreated the database, he used a different “user”, so all the nice triggers previously created could not be accessed by the application, and it stop working.
My opinion on this story is that we are developer, and all the database work needed for the business domain of our application should be driven by our code – otherwise who can tell what could happen?
Now, in one of my project the data versioning, I mean keeping track of all the modifications done to the stored record, was part of the application domain, so I begun to search I smart way to do that (of course, without triggers!).
You know what, that was how I begun to implement the Generic Hibernate access I have shown in the previous post.
But now, stop chit-chat, and do some real work.
Basically, we have an entity, for example a customer, with a property, let’s say his mood, that may change over time, but we want to keep track of all his moods, and when he changed it. Of course, the easiest way would be to just save all modifications in the same table, but then a couple of problem arise:
1) maybe some part of data can not change: for example our customer has always the same name, but with this solution we would copy again and again the same information – useless;
2) most time we would need to access just the current customer state, but the table would be bigger because it holds also all the previous ones, so access would be slower.
A different approach could be to have two entities, one representing the current state and one representing the previous (let’s call it “version”) state. The minimum set of properties needed are the ids and the creation/modification times:

@MappedSuperclass
public abstract class AbsCurrentDTO {

	protected long id;
	protected Date creationDate;

	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	@Column(unique = true, nullable = false)
	public long getId() {
		return id;
	}

	public void setId(long idParam) {
		id = idParam;
	}

	@Column(name = "CREATION_DATE", nullable = false)
	public Date getCreationDate() {
		return creationDate;
	}

	public void setCreationDate(Date creationDateParam) {
		creationDate = creationDateParam;
	}
}

@MappedSuperclass
public abstract class AbsVersionDTO {

	protected long id;
	protected Date modificationDate;
	protected long currentId;

        @Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	@Column(unique = true, nullable = false)
	public long getId() {
		return id;
	}

	public void setId(long idParam) {
		id = idParam;
	}

	@Column(name = "MODIFICATION_DATE", nullable = false)
	public Date getModificationDate() {
		return modificationDate;
	}

	public void setModificationDate(Date modificationDateParam) {
		modificationDate = modificationDateParam;
	}

	public long getCurrentId() {
		return currentId;
	}

	public void setCurrentId(long currentIdParam) {
		currentId = currentIdParam;
	}

Here, currentId is needed to link all the VersionsDTO belonging to the same CurrentDTO. Remember, @MappedSuperclass here means that this classes would not be mapped to any real table.
Here’s the concrete entities:

@Entity
@Table(name = "CUSTOMER_CURRENT")
public class CustomerCurrentDTO extends AbsCurrentDTO {

	protected String name;
	protected String mood;

        @Column(name = "NAME", nullable = false)
	public String getName() {
		return name;
	}

	public void setName(String nameParam) {
		name = nameParam;
	}

	@Column(name = "MOOD", nullable = true)
	public String getMood() {
		return mood;
	}

	public void setMood(String commentParam) {
		mood = commentParam;
	}
}

@Entity
@Table(name = "CUSTOMER_VERSION")
public class CustomerVersionDTO extends AbsVersionDTO {

	protected String mood;

	public CustomerVersionDTO() {
		super();
	}

	public CustomerVersionDTO(CustomerCurrentDTO customerCurrentDTO) {
		currentId = customerCurrentDTO.getId();
		mood = customerCurrentDTO.getMood();
	}

	@Column(name = "MOOD", nullable = true)
	public String getMood() {
		return mood;
	}

	public void setMood(String commentParam) {
		mood = commentParam;
	}
}

As you see, ids and dates are not here, because they are inherited from parents. Customer define a couple of properties, name and mood; name is the one that never change, and mood is the changing one. Version define only the changing one, mood. Of course, this two entities are mapped to different tables.
While implementation of Current customer does not have anything fancy in it, something is going on with the Version.
There are two constructors, the default one and the other that accept CustomerCurrentDTO as parameter. That way, we could copy variable states from the Current to the Version entity in the constructor. The default constructor is neede by Hibernate as we will see later.
All this talking of Current and Version is nice and good, but what about DAO ?
Well, we just need to add some modifications to the one I have illustrated in the other post.
First, we have to pass both type to the AbstractDAO:

public abstract class AbsDAO<T, E> {

	private Class currentType;
	private Class versionType;

	public AbsDAO() {
		currentType = (Class) ((ParameterizedType) getClass()
				.getGenericSuperclass()).getActualTypeArguments()[0];
		versionType = (Class) ((ParameterizedType) getClass()
				.getGenericSuperclass()).getActualTypeArguments()[1];

	}
}

Now we have two generics types, T and E, representing respectively the Current and the Version DTO. We also have two Class variables, currentType and versionType.
Take notice that currentType is instantiated with the .getActualTypeArguments()[0], while versionType is instantiated with the .getActualTypeArguments()[1].

Then, we have to modify the update method so that when we call it a new Version will be stored and the modificated Current will be updated

public boolean update(T myDTO) throws IllegalArgumentException,
			SecurityException, java.lang.InstantiationException,
			IllegalAccessException, InvocationTargetException,
			NoSuchMethodException {
		boolean toReturn = false;
		try {
			AbsCurrentDTO previousDTO = 
                          (AbsCurrentDTO) findById(((AbsCurrentDTO) myDTO).getId());
			AbsVersionDTO version = 
                          (AbsVersionDTO) versionType.getConstructor(currentType).newInstance(previousDTO);
			version.setModificationDate(new Date());
			Session session = sessionFactory.openSession();
			Transaction tx = session.beginTransaction();
			session.save(version);
			session.update(myDTO);
			tx.commit();
			session.close();
			toReturn = true;
		} catch (HibernateException e) {
			e.printStackTrace();
		}
		return toReturn;
	}

The update method receive the current (just modified) object. We retrieve its saved instance (not yet modified) by its id, and then with this we create the version object. Then, we save the version (a new record will be created for each modification) and we update the current (only one record will be stored in the current table). I think a little bit of magic is in that line (:
AbsVersionDTO version =
(AbsVersionDTO) versionType.getConstructor(currentType).newInstance(previousDTO);
that allows us to create a new instance of an object whose type is known only at runtime, using a constructor that require as parameter another object whose type is also known only at runtime… where were we?

Last, we want to retrieve all the versions, of course:

public List listVersions(T myDTO) {
		List toReturn = null;
		try {
			Session session = sessionFactory.openSession();
			Transaction tx = session.beginTransaction();
			long currentId = ((AbsCurrentDTO) myDTO).getId();
			toReturn = session.createCriteria(versionType)
					.add(Restrictions.eq("currentId", currentId)).list();
			tx.commit();
			session.close();
		} catch (HibernateException e) {
			e.printStackTrace();
		}
		return toReturn;
	}

This is where the default constructor is needed by Hibernate . otherwise it can not instantiate the CustomerVersionDTO to put in the return list.

Here’s the complete class

public abstract class AbsDAO<T, E> {

	protected SessionFactory sessionFactory;

	private Class currentType;
	private Class versionType;

	public AbsDAO() {
		currentType = (Class) ((ParameterizedType) getClass()
				.getGenericSuperclass()).getActualTypeArguments()[0];
		versionType = (Class) ((ParameterizedType) getClass()
				.getGenericSuperclass()).getActualTypeArguments()[1];
		sessionFactory = new AnnotationConfiguration().configure()
				.buildSessionFactory();
	}
	public T findById(long id) {
		T toReturn = null;
		try {
			Session session = sessionFactory.openSession();
			Transaction tx = session.beginTransaction();
			toReturn = (T) session.get(currentType, id);
			tx.commit();
			session.close();
		} catch (NonUniqueResultException e) {
			e.printStackTrace();
		} catch (HibernateException e) {
			e.printStackTrace();
		}
		return toReturn;
	}

	public List list() {
		List toReturn = null;
		try {
			Session session = sessionFactory.openSession();
			Transaction tx = session.beginTransaction();
			toReturn = session.createCriteria(currentType).list();
			tx.commit();
			session.close();
		} catch (HibernateException e) {
			e.printStackTrace();
		}
		return toReturn;
	}

	public List listVersions(T myDTO) {
		List toReturn = null;
		try {
			Session session = sessionFactory.openSession();
			Transaction tx = session.beginTransaction();
			long currentId = ((AbsCurrentDTO) myDTO).getId();
			toReturn = session.createCriteria(versionType)
					.add(Restrictions.eq("currentId", currentId)).list();
			tx.commit();
			session.close();
		} catch (HibernateException e) {
			e.printStackTrace();
		}
		return toReturn;
	}

	public Long save(T myDTO) {
		Long toReturn = null;
		try {
			Session session = sessionFactory.openSession();
			Transaction tx = session.beginTransaction();
			toReturn = (Long) session.save(myDTO);
			tx.commit();
			session.close();
		} catch (HibernateException e) {
			e.printStackTrace();
		}
		return toReturn;
	}

	public boolean update(T myDTO) throws IllegalArgumentException,
			SecurityException, java.lang.InstantiationException,
			IllegalAccessException, InvocationTargetException,
			NoSuchMethodException {
		boolean toReturn = false;
		try {
			AbsCurrentDTO previousDTO = (AbsCurrentDTO) findById(((AbsCurrentDTO) myDTO)
					.getId());
			AbsVersionDTO version = (AbsVersionDTO) versionType.getConstructor(
					currentType).newInstance(previousDTO);
			version.setModificationDate(new Date());
			Session session = sessionFactory.openSession();
			Transaction tx = session.beginTransaction();
			session.save(version);
			session.update(myDTO);
			tx.commit();
			session.close();
			toReturn = true;
		} catch (HibernateException e) {
			e.printStackTrace();
		}
		return toReturn;
	}

	public boolean delete(T myDTO) {
		boolean toReturn = false;
		try {
			Session session = sessionFactory.openSession();
			Transaction tx = session.beginTransaction();
			session.delete(myDTO);
			tx.commit();
			session.close();
			toReturn = true;
		} catch (HibernateException e) {
			e.printStackTrace();
		}
		return toReturn;
	}
}

This is the class to test it all:

public class Main {

	/**
	 * (Insert comments here)
	 * 
	 * @param args
	 * @throws NoSuchMethodException
	 * @throws InvocationTargetException
	 * @throws IllegalAccessException
	 * @throws InstantiationException
	 * @throws SecurityException
	 * @throws IllegalArgumentException
	 */
	public static void main(String[] args) throws IllegalArgumentException,
			SecurityException, InstantiationException, IllegalAccessException,
			InvocationTargetException, NoSuchMethodException {
		VersionedDAO dao = new VersionedDAO();
		CustomerCurrentDTO current = new CustomerCurrentDTO();
		current.setMood("I am easy");
		current.setCreationDate(new Date());
		current.setName("FOO BAR");
		System.out.println(current.toString());
		dao.save(current);
		current.setMood("Now I've changed my mind");
		System.out.println(current.toString());
		dao.update(current);
		current.setMood("And now I'm tired");
		System.out.println(current.toString());
		dao.update(current);
		List versions = dao.listVersions(current);
		for (CustomerVersionDTO version : versions) {
			System.out.println(version);
		}
	}

This is the database structure (I called it versiondb):

mysql> show tables;
+---------------------+
| Tables_in_versiondb |
+---------------------+
| CUSTOMER_CURRENT    |
| CUSTOMER_VERSION    |
+---------------------+
2 rows in set (0.00 sec)

mysql> describe CUSTOMER_CURRENT;
+---------------+--------------+------+-----+---------+----------------+
| Field         | Type         | Null | Key | Default | Extra          |
+---------------+--------------+------+-----+---------+----------------+
| id            | bigint(20)   | NO   | PRI | NULL    | auto_increment |
| CREATION_DATE | datetime     | NO   |     | NULL    |                |
| MOOD          | varchar(255) | YES  |     | NULL    |                |
| NAME          | varchar(255) | NO   |     | NULL    |                |
+---------------+--------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

mysql> describe CUSTOMER_VERSION;
+-------------------+--------------+------+-----+---------+----------------+
| Field             | Type         | Null | Key | Default | Extra          |
+-------------------+--------------+------+-----+---------+----------------+
| id                | bigint(20)   | NO   | PRI | NULL    | auto_increment |
| currentId         | bigint(20)   | NO   |     | NULL    |                |
| MODIFICATION_DATE | datetime     | NO   |     | NULL    |                |
| MOOD              | varchar(255) | YES  |     | NULL    |                |
+-------------------+--------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

And here’s the sql to generate it (actually, I used Hibernate’s hbm2ddl.auto=create feature)

CREATE TABLE `CUSTOMER_CURRENT` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `CREATION_DATE` datetime NOT NULL,
  `MOOD` varchar(255) DEFAULT NULL,
  `NAME` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`)
);

CREATE TABLE `CUSTOMER_VERSION` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `currentId` bigint(20) NOT NULL,
  `MODIFICATION_DATE` datetime NOT NULL,
  `MOOD` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`)
);