Configure Abator on eclipse

So we are thinking of using iBatis on our project… And our team is very excited about it…

We decided to play around with iBatis to get some hands-on experience.. and after some Googling, i found out that Abator is the tool that will help us get started quickly on the iBatis road…

But when i googled for steps to configure Abator on eclipse, i did not find clear steps. Though the documentation and Adam Smith’s blog Introduction to iBatis helped me a lot to configure Abator. I just want to reconcile all the information at the single place.

So here we go….

1. Download the abator.jar from here. The version i used is “abator-1.0.0-238″.

2. Download the iBatis jars from here. The version i used is “2.2.0.638″

3. Make sure that you have the database driver jars. I am using DB2 (Version 8.1.7.445) to test and the jar files are: db2jcc.jar and db2jcc_license_cu.jar

4. Create a simple java project in eclipse.

5. Add the following directories to the project.

src – will contain Abator generated source

lib – will contain the necessary jars

config – will contain some configuration files needed for Abator.

6. Add the abator.jar, iBatis jars and database related jars to the lib directory.

7. Add all these jars on the project build path by right clicking the Project > select properties > select Java Build Path > Libraries on RHS > Add Jars and select all the jars.

8. Now in the “config” folder add two files: abatorConfig.xml and configuration.properties.

abatorConfig.xml:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE abatorConfiguration PUBLIC "-//Apache Software Foundation//DTD Abator for iBATIS Configuration 1.0//EN"

  "http://ibatis.apache.org/dtd/abator-config_1_0.dtd"><abatorConfiguration>

  <abatorContext>

    <jdbcConnection driverClass="${database.driver}"

        connectionURL="${database.url}"

        userId="${database.username}"

        password="${database.password}">

      <classPathEntry location="${database.driver.jar.path}" />

   <classPathEntry location="${database.driver.license.jar.path}" />

    </jdbcConnection>

<javaModelGenerator targetPackage="${ibatis.generated.source.model.pkg}"

    	targetProject="src">

    	<property name="trimStrings" value="true" />

    </javaModelGenerator>

<sqlMapGenerator targetPackage="${ibatis.generated.source.sqlmap.pkg}"

    	targetProject="src">

    	<property name="trimStrings" value="true" />

    </sqlMapGenerator>

<daoGenerator targetPackage="${ibatis.generated.source.dao.pkg}"

    	targetProject="src" type="IBATIS">

    </daoGenerator>

<table schema="ABC" tableName="TBLSTUDENT" />

</abatorContext>

</abatorConfiguration>

And this is my configuration.properties file:

database.driver=com.ibm.db2.jcc.DB2Driver
database.url=jdbc:db2:AMOL
database.username=db2inst
database.password=db2inst
database.driver.jar.path=lib/db2jcc.jar
database.driver.license.jar.path=lib/db2jcc_license_cu.jar
ibatis.generated.source.model.pkg=com.ibatis.model
ibatis.generated.source.sqlmap.pkg=com.ibatis.dao.sqlmap
ibatis.generated.source.dao.pkg=com.ibatis.dao

9. Add a build.xml file to your project:

build.xml:

<project name="AbatorTest" default="generate-ibatis" basedir=".">

	<property name="abator.config.dir" 		value="config"/>
	<property name="lib.dir" 		value="lib" />

	<property file="${abator.config.dir}/configuration.properties"/>

	<path id="classpath">
        <fileset dir="${lib.dir}" includes="**/*.jar"/>
    </path>

	<target name="generate-ibatis" description="Generate iBatis Code">
		<taskdef name="abator"
		      classname="org.apache.ibatis.abator.ant.AbatorAntTask"
						classpathref="classpath"/>
		<abator overwrite="true" configfile="${abator.config.dir}/abatorConfig.xml" verbose="true" >
			<propertyset>
				<propertyref name="ibatis.generated.source.model.pkg"/>
				<propertyref name="ibatis.generated.source.sqlmap.pkg"/>
				<propertyref name="ibatis.generated.source.dao.pkg"/>
				<propertyref name="database.driver" />
				<propertyref name="database.url" />
				<propertyref name="database.username" />
				<propertyref name="database.password" />
				<propertyref name="database.driver.jar.path" />
				<propertyref name="database.driver.license.jar.path" />
			</propertyset>
		</abator>
	</target>
</project>

10. Thats it… you are done with the setup.
11. Now to generate the iBatis code for any table you simply need to put the table name in the abatorConfig.xml.. something like tableName=”TBLSTUDENT” – i have already put.

12. Now tweak around the generated code as per your requirements…

Inversion Of Control (IoC)

Inversion of Control, also called as dependency Injection, is all about inverting the control. Or, how one object uses another object. Suppose class A wants to use class B. Traditionally, you would create and use an instance of class B within class A, like in the following example:

Class A {
private B b;
public A() {
b = new B();
}
public void doSomething(){
b.someMethod();
}
}

This approach has following problems:

1. The creation of object B relies upon the availability of a default constructor.
2. Any change in the constructor implementation of class B will necessitate a change in the implementation of class A.
3. Suppose class A wants to use class C instead of class B. Then class A needs to change. What happens if class B and class C are two separate implementations of same service and the application will need to switch over from one implementation to the other?

All three of the problems in the code example are due the strong coupling of class A and class B. Class A first needs to know that it must use an instance of class B and then it needs to know how to construct an instance of class B.

The solution to this problem is to eliminate the dependency from class A. What follows is a modified class A, where strong coupling is removed:

Class A {

private B b;  

public A(B b) {

this.b = b;

}

public void doSomething(){    

b.someMethod();

}

}

This example accepts an instance of class B via the constructor. This relieves class A from knowing how to instantiate class B. Now, in order to use class A, the caller class of A must also instantiate class B and pass it into class A. In this context, the caller class is also acting as an assembler of object A and object B. Object A does not explicitly look for B, but B is supplied to it. This is the Inversion of Control. The control of class B is taken out of class A and placed in the Assembler class.

IoC Frameworks
Several open source IoC frameworks like Spring, PicoContainer, and HiveMind support the IoC pattern. While the general IoC principle is simple, each of these frameworks supports different implementations and offers different benefits. The IoC pattern can be implemented in three ways: setter based, constructor based, and interface based.
Setter-Based IoC
This type of IoC uses a setter method to inject the referenced object into a referring object. This is the most common type of IoC, and both Spring and PicoContainer implement it. Setter-based IoC is good for objects that take optional parameters and objects that need to change their properties many times during their lifecycles. Its main disadvantage is that you need to expose all the properties of an object to the outside world when using a setter method. This breaks one of the key OO principles: data encapsulation and information hiding.
Constructor-Based IoC
This type of IoC uses a constructor to set the reference of the object. Its main advantage is that only the creator knows about the referenced object. Once the object is created, the client code that uses the object is unaware of the referenced object. This approach may not work in all types of applications, however. For example, if you use an external API that needs a default constructor, then you need to go with a setter-based IoC. A constructor-based IoC is the main type of implementation in Spring.
Interface-Based IoC
In this type of IoC, objects implement a specific interface from the IoC framework, which the IoC framework will use to properly inject the objects. One of the main advantages of this type is that it doesn’t need an external configuration file to configure the object references. Since you need to use the IoC framework’s marker interface, the IoC framework knows how to glue the objects together. It is similar to using EJB. Any EJB container knows how to instantiate your objects and hook them with itself. The main
disadvantage of this approach is that the marker interface ties your application to a specific IoC framework. Apache Avalon is based on this approach but this project has been closed.