[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_58257 ] Philippe Laflamme commented on IBATIS-50: -----------------------------------------
> And the ultimate result of Beans.instantiate()? Answer: result = > cl.newInstance(); Yes, but it could be anything else also. The JavaBean Specification actually states that it is recommended, but not required, to instantiate JavaBean objects in this way, as it provides isolation from the creation mechanism. > Furthermore, this is a contradictory argument, because if you're going to > deserialize > your bean from the disk, why would you be trying to retrieve it from the > datbase? The Beans.instantiate() method handles JavaBean instantiation. As you stated, part of this process could require deserialization from disk. It also has special handling for JavaBeans that are Applets. But this is besides the point, which is that the method is hiding how the bean is actually created. I mentioned the method simply as an example of how isolation can be helpful when working with APIs, in this case the JavaBean API. > Perhaps for non-bean POJOs, this might be useful. That is precisely what I think. Allowing iBatis to work with non-fully-JavaBean objects would be useful. BTW, I appreciate exchanging views on this... In whichever way people on this, iBatis will only get better! Thanks, Philippe > Ability to override the default bean creation mechanism > ------------------------------------------------------- > > Key: IBATIS-50 > URL: http://issues.apache.org/jira/browse/IBATIS-50 > Project: iBatis for Java > Type: Wish > Components: SQL Maps > Versions: 2.0.9 > Reporter: Philippe Laflamme > > Currently, iBatis is responsible for creating instances of classes used in > result maps. It relies on the assumption that objects can be obtained using > the Class.newInstance() method (or something equivalent). > The assumption forces users of the framework to create classes with a no-arg > default constructor. IMHO, this also has the effect of favoring > implementation inheritance (extends) over interface inheritance. > Although this is not a problem in most cases, the ability to plug in an > external instance factory would provide more flexibility and favor good > programming practices. Amongst other things, it would provide developers the > ability write code in terms of interface. > A simple solution is to provide an extension point where resultMap class > instances are obtained from. > The simplest form would be: > public interface InstanceFactory { > Object createInstance(Class resultMapClass); > } > The default implementation would do something along the lines of: > [...] > return resultMapClass.newInstance(); > [...] > Developers could configure iBatis to either use the default implementation or > their own custom implementation. The setting could be part of the > sqlMapConfig file or even per resultMap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
