Migrating from Abator

This page details changes between Ibator and Abator. For most users, the changes should be simple. If you extended any of Abator's classes to supply custom implementations of code generators or the Java type resolver, you will need to rework those custom classes.

The changes are listed in three categories: from required configuration changes to less common changes. Note that most changes are described assuming you are using XML configuration for Ibator. If you are using Java based configuration, then the changes are still required and should be easy to deduce from the description of the XML changes.

Required for All Users

• The DTD has changed. The new DOCTYPE should be

  
  <!DOCTYPE ibatorConfiguration
    PUBLIC "-//Apache Software Foundation//DTD Apache iBATIS Ibator Configuration 1.0//EN"
    "http://ibatis.apache.org/dtd/ibator-config_1_0.dtd">
      

• The <abatorConfiguration> element is renamed to <ibatorConfiguration>
• The <abatorContext> element is renamed to <ibatorContext>

Required for Many Users

• <ibatorContext> elements now require an ID
• The generatorSet attribute is removed from the <ibatorContext> element and replaced with the targetRuntime attribute. Valid values for this attribute are Ibatis2Java2 or Ibatis2Java5. Ibator does not include the legacy generator set from Abator - so iBATIS version 2.2.0 or higher is required for the code generated by Ibator.
• The Ibator classloading strategy has changed substantially, and we now recommend that you manage the runtime classpath external to Ibator. If you manage the classpath with configuration entries, you must make the following changes from Abator:
  • Class path entries are specified at the configuration file level with the <classPathEntry> element - now a child element of <ibatorConfiguration> only.
  • A <classPathEntry> element is not longer allowed as a child of <jdbcConnection>
  • The "rootClasspath" property is no longer valid for the <javaModelGenerator> element.

Rarely Required Changes

• The type attribute is removed from both the <javaModelGenerator> and <sqlMapGenerator> elements. Ibator has an entirely different method of supplying custom code generators than Abator. See the Extending Ibator page for full details.
• The type attribute on the <daoGenerator> element has a different meaning from the attribute in Abator. The special values remain the same, the difference manifests if you used this attribute the specify a custom DAO generator for Abator. With Ibator, the type specifies the type of a custom DAO template rather than an implementation of a custom DAO generator. Again, no changes are required unless you used this attribute to specify a custom DAO generator in Abator. Ibator has an entirely different method of supplying custom code generators than Abator. See the Extending Ibator page for full details.
• The JavaTypeResolver interface has changed and is simplified. If you specified a custom implementation on the <javaTypeResolver> element, you must rework your implementation class.
• The ProgressCallback interface has changed significantly. If you implemented this interface for some other execution environment, you will need to rework your implementation.