You need to add your new resolver to the same classpath as the Ibator JAR. <classPathEntry> elements are only used for JDBC drivers and one other esoteric place. Because your resolver extends an ibator class, it should be loaded by the same classloader.
http://ibatis.apache.org/docs/tools/ibator/configreference/classPathEntry.html Jeff Butler On Mon, May 18, 2009 at 7:50 PM, NathanM <nathan.mel...@infdig.com> wrote: > > Then what am I doing wrong with my resolver type? > > Ibator keeps failing with the "Cannot instantiate object . . . . > JavaTypeResolverWithNVarChar"; > > Does this instantiation not use the classpath entries in the > ibatorConfig.xml file? I've tried putting an entry in there for the bin > directory which has class files, and I've tried putting the custom resolver > in a jar file and putting the jar file as a classpath entry. > > I have done a unit test and have no trouble loading this particular class. > > == > > import java.sql.Types; > import java.util.List; > import java.util.Properties; > > import org.apache.ibatis.ibator.api.IntrospectedColumn; > import org.apache.ibatis.ibator.api.JavaTypeResolver; > import org.apache.ibatis.ibator.api.dom.java.FullyQualifiedJavaType; > import org.apache.ibatis.ibator.config.IbatorContext; > import org.apache.ibatis.ibator.internal.types.JavaTypeResolverDefaultImpl; > > public class JavaTypeResolverWithNVarChar implements JavaTypeResolver { > > JavaTypeResolverDefaultImpl impl = new JavaTypeResolverDefaultImpl(); > > public JavaTypeResolverWithNVarChar() > { > > > } > > /* (non-Javadoc) > * @see > org.apache.ibatis.ibator.api.JavaTypeResolver#addConfigurationProperties(java.util.Properties) > */ > �...@override > public void addConfigurationProperties(Properties properties) { > impl.addConfigurationProperties(properties); > > } > > /* (non-Javadoc) > * @see > org.apache.ibatis.ibator.api.JavaTypeResolver#setIbatorContext(org.apache.ibatis.ibator.config.IbatorContext) > */ > �...@override > public void setIbatorContext(IbatorContext ibatorContext) { > impl.setIbatorContext(ibatorContext); > } > > /* (non-Javadoc) > * @see > org.apache.ibatis.ibator.api.JavaTypeResolver#setWarnings(java.util.List) > */ > �...@override > public void setWarnings(List<String> warnings) { > impl.setWarnings(warnings); > } > > > /** > * Override this method to add NVarChar to the list of supported types > */ > �...@override > public FullyQualifiedJavaType calculateJavaType(IntrospectedColumn > introspectedColumn) > { > FullyQualifiedJavaType answer; > if(introspectedColumn.getJdbcType() == Types.NVARCHAR) > answer = new > FullyQualifiedJavaType(String.class.getName()); > else > answer = impl.calculateJavaType(introspectedColumn); > return answer; > } > } > > ==== > > Jeff Butler-2 wrote: >> >> As far as iBATIS goes, as long as the driver allows treating the >> NVARCHAR column as VARCHAR, it should work out of the box. If the >> driver requires you to call the new JDBC 4.0 methods, then you'll have >> to write a custom type handler. >> >> Jeff Butler >> > > So I take it the SqlServer driver doesn't allow treating NVarChars as > VARCHARS, or it would already work? I'm using the Microsoft sqljdbc4.jar > driver. > > > -- > View this message in context: > http://www.nabble.com/NVARCHAR-not-supported--tp23568890p23607788.html > Sent from the iBATIS - User - Java mailing list archive at Nabble.com. > >
