Frames No Frames

Extending Abator

Abator is designed for extensibility. All code generation is performed using a simple DOM representation of Java and XML elements that is included with Abator.

The Java DOM is included in the package org.apache.ibatis.abator.api.dom.java

The XML DOM is included in the package org.apache.ibatis.abator.api.dom.xml

These classes are not sufficient for every conceivable code generation possibility, but they are quite useful for generating simple to moderately complex Java and XML code.

Using options in the Abator configuration file, you can provide your own implementations of any of Abator's key interfaces. You can also subclass any of the provided implementations to provide customized behaviors. This page will describe the public APIs available in Abator and provide pointers to the source code for further investigation. If you have any difficulty understanding how to extend Abator, feel free to send a note to the support mailing list at user-java@ibatis.apache.org.

org.apache.ibatis.abator.api.JavaModelGenerator

Abator calls methods in this interface to generate the Java model POJOs. You can provide your own implementation, and the default implementations have been designed for extensibility. The default implementation of the interface is dependant on the value of the generatorSet property of the <abatorContext> configuration element. The following table shows the different possibilities:

To provide your own implementation, specify the fully qualified class name in the XML configuration like this:

    <javaModelGenerator type="mypackage.MyImplementation">
      ...
    </javaModelGenerator>

org.apache.ibatis.abator.api.SqlMapGenerator

Abator calls methods in this interface to generate the SQL Maps. You can provide your own implementation, and the default implementations have been designed for extensibility. The default implementation of the interface is dependant on the value of the generatorSet property of the <abatorContext> configuration element. The following table shows the different possibilities:

To provide your own implementation, specify the fully qualified class name in the XML configuration like this:

    <sqlMapGenerator type="mypackage.MyImplementation">
      ...
    </sqlMapGenerator>

org.apache.ibatis.abator.api.DAOGenerator

Abator calls methods in this interface to generate the DAOs for each introspected table. Abator supplies twelve implementations of this interface to match the four different types of DAOs, and the three different sets of code generators. The implementation is selected based on the value of the <abatorContext> configuration element and the value of the type attribute of the <daoGenerator> element. The implementations are:

The different DAO implementations are "configured" through the use of a template described in org.apache.ibatis.abator.internal.java.dao.AbstractDAOTemplate. It should be fairly simple to provide a new template for a different type of DAO if needed.

The DAO generators are also designed for extensibility. To provide your own implementation, specify the fully qualified class name in the XML configuration like this:

    <daoGenerator type="mypackage.MyImplementation">
      ...
    </daoGenerator>

org.apache.ibatis.abator.api.JavaTypeResolver

Abator calls methods in this interface to map JDBC types to Java types during database introspection. The default implementation of this interface is org.apache.ibatis.abator.internal.types.JavaTypeResolverDefaultImpl. You can provide your own implementation, and the default implementation has been designed for extensibility.

To provide your own implementation, specify the fully qualified class name in the XML configuration like this:

    <javaTypeResolver type="mypackage.MyImplementation">
      ...
    </javaTypeResolver>

org.apache.ibatis.abator.api.ShellCallback

Abator calls methods in this interface to perform functions that it cannot do on its own. The most important of these functions are:

• Translating project/package into a directory structure
• Merging Java source files in the event that an existing Java file of the same name/package exists.

The default implementation of this interface is org.apache.ibatis.abator.internal.DefaultShellCallback. The default implementation simply concatenates project and package together and creates the necessary package directories if needed. The default implementation does not support merging of Java files, and will either overwrite or ignore files.

You can provide your own implementation. This would be the most important class to write if you want to integrate Abator into some other environment. The Eclipse plugin provides an implementation of this interface that supports Java file merging when running in the Eclipse environment.

To provide your own implementation, supply an instance of the interface on the constructor to the org.apache.ibatis.abator.api.Abator object. This cannot be configured through XML. If you are providing your own implementation of this interface then we assume that you are also providing some collateral code (like a new Ant task) to run your implementation.

org.apache.ibatis.abator.api.ProgressCallback

Abator calls methods in this interface to report progress during the generation of files (a long running process). The default implementation of this interface is org.apache.ibatis.abator.internal.NullProgressCallback which simply ignores all progress messages. You can provide an implementation of this interface to support progress notifications and cancellation of file generation.

Implementing this interface would be important when integrating Abator into other IDE environments. The Eclipse plugin provides an implementation of this interface that hooks into Eclipse's progress notification system.

To provide your own implementation, supply an instance of the interface in the org.apache.ibatis.abator.api.Abator.generate() method call. This cannot be configured through XML. Again, we assume that if you are providing your own implementation of this interface then you are also providing some collateral code (like a new Ant task or an IDE integration) to run your implementation.