Ibator is designed for extensibility. All code generation is performed using a simple DOM representation of Java and XML elements that is included with Ibator.
The Java DOM is included in the package org.apache.ibatis.ibator.api.dom.java
The XML DOM is included in the package org.apache.ibatis.ibator.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 Ibator configuration file, you can provide your own implementations of many of Ibator'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 Ibator and provide pointers to the source code for further investigation. If you have any difficulty understanding how to extend Ibator, feel free to send a note to the support mailing list at user-java@ibatis.apache.org.
Although there are a number of different extension points for Ibator, as shown on this page, in most cases it will be far easier to extend Ibator through the use of a plugin. See the Implementing Ibator Plugins reference page for more information.
The primary extension point for code generation is
org.apache.ibatis.ibator.api.IntrospectedTable. Implementing a code generator
is a non-trivial task and should only be contemplated when you want to completely replace
the code generation activities of Ibator. In the years since the original release of Abator,
very few enhancement requests have appeared that could not be handled by a plugin.
Ibator includes a number of different extension points. The following sections list the different methods of extending Ibator, and describes the types of activities that can be accomplished with the different extensions. If you need some help understanding the different options, feel free to ask a question on the iBATIS user mailing list.
Use this extension point if you need to generate DAO objects that are different from
one of Ibator's built-in options. Classes that extend AbstractDAOTemplate
have the opportunity to override and implement a variety of different methods that
define how the DAO objects should be constructed, and how the DOAs interact with iBATIS.
If you implement this extension point, then you should specify the fully qualified
name of the implementing class on the type attribute of the
<daoGenerator> configuration element.
IntrospectedTable is an abstract class that can be extended to supply
different code generators than the versions supplied with Ibator. A good example of
such an implementation would be a FreeMarker or Velocity template based
implementation of Ibator. In most other instances, coding a plugin is the better way to go.
If you choose to extend this class, you must supply code to generate Java model classes,
DAO classes, and SQL Map XML files. You may choose to generated those generators with the
technology of your choice. You should also ensure that you follow all the Ibator rules for
code generation (for example, do not generate a primary key class if the table doesn't have
a primary key). The base IntrospectedTable class holds an instance
of org.apache.ibatis.ibator.internal.rules.IbatorRules that can be queried
to determine many of the rules for code generation.
Ibator supplies two implementations of introspected table. The implementation is chosen
bases on the value of the targetRuntime attribute of the
<ibatorContext> element. In many cases it will be far simpler
to extend one of the built in implementations, rather than creating an implementation
from scratch. The following table shows the built in implementations:
| TargetRuntime | Implementation |
|---|---|
| Ibatis2Java2 (default) | org.apache.ibatis.ibator.generator.ibatis2.IntrospectedTableIbatis2Java2Impl |
| Ibatis2Java5 | org.apache.ibatis.ibator.generator.ibatis2.IntrospectedTableIbatis2Java5Impl |
If you choose to implement this extension point, specify the fully qualified
class name of your implementation with the targetRuntime
attribute of the <ibatorContext> element.
IntrospectedColumn is a class that holds information about a
column as it is returned from database metadata, as well as methods used
during code generation to generate specific phrases for iBATIS. In some rare
circumstances it might be desirable to override this class to provide
your own implementation - especially if you create a new set of code
generators for Ibator.
If you choose to implement this extension point, specify the fully qualified
class name of your implementation with the introspectedColumnImpl
attribute of the <ibatorContext> element.
Ibator 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.ibator.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>
Ibator calls methods in this interface to perform functions that it cannot do on its own. The most important of these functions are:
The default implementation of this interface is
org.apache.ibatis.ibator.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 Ibator into some other environment. For example, 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.ibator.api.Ibator
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.
Ibator 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.ibator.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 Ibator 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.ibator.api.Ibator.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.