Here's some new insight into this problem. Look at how two objects of mine get
serialized by XStream:
<state class="my.model.Address-State--EnhancerByCGLIB--675f34ca">
<CGLIB_DOLLAR_BOUND>true</CGLIB_DOLLAR_BOUND>
<CGLIB_DOLLAR_CALLBACK__0
class="com.ibatis.sqlmap.engine.mapping.result.loader.EnhancedLazyResultLoader-EnhancedLazyResultLoaderImpl"/>
</state>
<country class="my.model.Address-Country--EnhancerByCGLIB--24c53861">
<CGLIB_DOLLAR_BOUND>true</CGLIB_DOLLAR_BOUND>
<CGLIB_DOLLAR_CALLBACK__0
class="com.ibatis.sqlmap.engine.mapping.result.loader.EnhancedLazyResultLoader-EnhancedLazyResultLoaderImpl"/>
</country>
It appears as IBATIS isn't creating instances of static inner classes like I
would expcet. For reference, here's what my SQL map looks like
<typeAlias alias="state" type="my.model.Address$State"/>
<typeAlias alias="country" type="my.model.Address$Country"/>
my.model.Address.State POJO has String code, String name, Country country.
my.model.Address.Country POJO has String code, String name
Also, there seems to be issues with some POJOs that implement a common
interface, my.model.Type. They're being serialized as
<status class="my.model.Type--EnhancerByCGLIB--a88b2d31">
<CGLIB_DOLLAR_BOUND>true</CGLIB_DOLLAR_BOUND>
<CGLIB_DOLLAR_CALLBACK__0
class="com.ibatis.sqlmap.engine.mapping.result.loader.EnhancedLazyResultLoader-EnhancedLazyResultLoaderImpl"/>
</status>
On January 27, 2006, Joe Wolf wrote:
>
> I have a fairly interesting problem involving iBATIS 2.1.5 and XStream 1.1.2.
> I have some POJOs that get created by iBATIS when I run some queries. I
> then serialize them to XML through XStream--however, I'm getting a
> StackOverflowError when doing so. Through debugging, I found that XStream is
> eventually encountering within my POJOs a
> com.ibatis.sqlmap.engine.exchange.DataExchangeFactory object and then a
> com.ibatis.sqlmap.engine.exchange.DomDataExchange object, and then it finds
> another DataExchangeFactory and DomDataExchange, and so on, cycling until the
> stack overflows. But this begs the question, how are these ibatis objects
> getting into my POJOs?
>
> The only thing I can think of is that I'm using java.math.BigIntegers for my
> numeric IDs, so I wrote a callback to help handle them:
>
> public class BigIntegerTypeHandlerCallback implements TypeHandlerCallback {
> public void setParameter(ParameterSetter setter, Object parameter) throws
> SQLException {
> if (parameter != null)
> setter.setLong(((BigInteger)parameter).longValue());
> }
> public Object getResult(ResultGetter getter) throws SQLException {
> return getter.getString() == null ? null : new
> BigInteger(getter.getString());
> }
> public Object valueOf(String val) {
> return val == null ? null : new BigInteger(val);
> }
> }
>
> In my sqlMapConfig... <typeHandler javaType="java.math.BigInteger"
> callback="gov.sec.acts.util.BigIntegerTypeHandlerCallback"/>
>
> Perhaps my callback isn't working correctly, or I'm not specifying
> javaType="java.math.BigInteger" in all of my resultMaps whenever I'm
> retrieving a NUMERIC id? Any ideas?
>
> Joe Wolf
> ___________________________________
> CompSci Resources, LLC
> www.compsciresources.com
>
>
> ____________________
> Joe Wolf - Software Engineer
> CompSci Resources, LLC
> 703-750-3547
____________________
Joe Wolf - Software Engineer
CompSci Resources, LLC
703-750-3547
