ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: [2.2.0] Use case for ResultObjectFactory
Date Thu, 07 Sep 2006 19:27:59 GMT
Sure - feel free to open the issue with the Spring folks.  I hope it works
out well for you.

Jeff Butler



On 9/7/06, Christopher.Mathrusse@sybase.com <
Christopher.Mathrusse@sybase.com> wrote:
>
>  Thanks for the follow-up Jeff. I'll look into implementing this as I like
> it as a solution better than the way I currently have it. If you would like
> I would be willing to open an issue with Spring to see if we can get this
> functionality added. I've seen some rather fast resolutions to some requests
> by the Spring team.
>
>  ------------------------------
> *From:* "Jeff Butler" <jeffgbutler@gmail.com> [mailto:"Jeff Butler" <
> jeffgbutler@gmail.com>]
> *Sent:* Thursday, September 07, 2006 10:27 AM
>
> *To:* user-java@ibatis.apache.org
> *Subject:* Re: [2.2.0] Use case for ResultObjectFactory
>
>
>  I'm just getting around to adding to this discussion...I had to do some
> investigation into Spring.
>
> iBATIS 2.2.0 would support injecting the result object factory from
> Spring.  The problem is that Spring's SqlMapClientFactoryBean needs some
> changes.  The result object factory could be injected in exactly the same
> way that the transaction configuration is injected.
>
> Assuming that it might take some time to get Spring's
> SqlMapClientFactoryBean changed, you could also inject the factory yourself
> using a bit of Java code as follows:
>
> ExtendedSqlMapClient client = (ExtendedSqlMapClient) factory.getBean
> ("sqlMapClient);
> ResultObjectFactory rof = (ResultObjectFactory) factory.getBean
> ("resultObjectFactory");
> client.getDelegate().setResultObjectFactory(rof);
>
> You could also create your own subclass of Spring's
> SqlMapClientFactoryBean and do something similar:
>
> 1. override the afterPropertiesSet method
> 2. call super.afterPropertiesSet()
> 3. inject the result object factory as shown above (see the
> applyTransactionConfig method as an example)
>
> Jeff Butler
>
>
>
> On 8/31/06, Christopher.Mathrusse@sybase.com <Christopher.Mathrusse@sybase.com
> > wrote:
> >
> >  I was one of the requestors of this functionality. The practical use
> > case for this was to be able to specify an object factory that could
> > instantiate objects rather than having iBatis use the newInstance() method.
> > This would allow for someone to specify an object factory that could
> > potentially return objects, for example, from the Spring container. While
> > the interface does define an API for creating such an object factory it is
> > incomplete of what is actually needed. The interface defines a way to return
> > requested objects but requires that the implementing class provide a no
> > argument constructor. This has some serious limitations.
> >
> > To better complete this requirement we need a way to inject the
> > ResultObjectFactory into iBatis rather that iBatis instantiating the
> > implementation. While I have found a way to get this to work within the
> > Spring container I feel that it is less than elegant and would welcome the
> > ability to inject the ResultObjectFactory into iBatis.
> >
> >  ------------------------------
> > *From:* Jan Vissers <Jan.Vissers@cumquat.nl> [mailto: Jan Vissers <
> > Jan.Vissers@cumquat.nl>]
> > *Sent:* Wednesday, August 30, 2006 10:30 PM
> > *To:* user-java@ibatis.apache.org
> > *Subject:* [2.2.0] Use case for ResultObjectFactory
> >
> >
> >  I'm trying to figure out why/when/how one would use a
> > ResultObjectFactory - does anybody have a real practical use case for
> > it?
> >
> >
> >
> >
>

Mime
View raw message