You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by "Philippe Laflamme (JIRA)" <ib...@incubator.apache.org> on 2005/01/17 23:11:17 UTC
[jira] Created: (IBATIS-50) Ability to override the default bean creation mechanism
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
[jira] Commented: (IBATIS-50) Ability to override the default bean creation mechanism
Posted by "Clinton Begin (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_58247 ]
Clinton Begin commented on IBATIS-50:
-------------------------------------
I don't necessarily disagree with the idea of allowing factories, but I do disagree with the reasons and intended use.
A few things:
1) Programming to interfaces is a best practice for services, behaviors, functions, etc. However, it is a horrible idea to program against interfaces to represent state. Why? Because it implies that there is more than one implementation of the behavior of the state (????). Doesn't make sense? Well it shouldn't, because it's an odd semantic. You should not have interfaces for your JavaBeans that represent state. Entity Beans are a perfect example of how ridiculous and problematic this design can be (session beans are a different story).
2) This entire request is contradictory. One of the complaints is that the "bean" must have a parameterless constructor. Well, that is more than acceptable since the JavaBeans specification requires this. That said, we are going to support parameterized constructors definable through result maps.
3) Factories are not the way to solve inheritance as described (yet another contradiction in this request --first a complaint, and then an intended use). We're going to support the <resultMap> <subclass> element, as in the .NET version of the framework.
These new features will hopefully be available within the next 2 releases (2.1.0 or 2.1.1).
Cheers,
Clinton
> 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
[jira] Commented: (IBATIS-50) Ability to override the default bean
creation mechanism
Posted by "Joe Celentano (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_12364114 ]
Joe Celentano commented on IBATIS-50:
-------------------------------------
I originally replied to the mailing list with my comments, and I see they aren't here, so I'll add them. This issue has by far the most votes, and seems fairly straightforward to incorporate...
Joe Celentano
Fri, 01 Apr 2005 10:47:19 -0800
Incidentally, I'd like to offer you an example of how the lack of this capability is impacting my use of another Apache project...
I just mocked up a set of DAOs and SQLMaps using resultset objects created by XMLBeans, not realizing the problem with Factory creation vs. the newInstance method. XMLBeans are perfect for holding the results of my queries because the receiving application code can choose from a variety of xml or Java methods for data access. However, XMLBeans require object creation via a Factory and cannot be created via iBatis. For example, a PurchaseOrderDocument is created via PurchaseOrderDocument.Factory.newInstance(). Quite frustrating...
Just my 2 cents.
Joe Celentano
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-50) Ability to override the default bean creation mechanism
Posted by "Philippe Laflamme (JIRA)" <ib...@incubator.apache.org>.
[ 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
[jira] Commented: (IBATIS-50) Ability to override the default bean creation mechanism
Posted by "Clinton Begin (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_58256 ]
Clinton Begin commented on IBATIS-50:
-------------------------------------
>> 1) Take unit testing for example
Unit testing frameworks such as JMock and EasyMock allow you to dynamically extend your domain model without mangling the domain design.
>> Beans.instantiate() method which is designed (amongst other things) to isolate calling classes
And the ultimate result of Beans.instantiate()? Answer: result = cl.newInstance();
Beans.instantiate() is intended to allow beans to be transparently desirialized or instantiated, depending on the security privileges, environment and configuration (and whether a serialized version of the class exists). It doesn't give the developer any additional control over the object creation process, and still requires a parameterless constructor.
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? Where's the data? I can't think of even a single interesting (or even safe) use of such a design (please share if you have a real world example).
>> 3) I agree. Where can I read about the <subclass> element?
The platform independent (.NET/Java) developer's guide.
http://prdownloads.sourceforge.net/ibatisnet/DevGuide.pdf?download
>> would you agree that isolating iBatis from the bean instantiation mechanism is important?
Not me personally, and especially not for JavaBeans. Perhaps for non-bean POJOs, this might be useful.
The good news is that it's logged here in JIRA, and people can vote for it if they like. I'm sure you're not alone, and this feature could be implemented in a future release. We don't really ever say "no" to anything (unless it's seriously contradictory to the goals of the framework --which this is not)...we just prioritize.
Cheers,
Clinton
> 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
[jira] Commented: (IBATIS-50) Ability to override the default bean creation mechanism
Posted by "Fabio Insaccanebbia (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_12329426 ]
Fabio Insaccanebbia commented on IBATIS-50:
-------------------------------------------
I'd be interested in seeing this "wish" come true. My problem is that sometimes I'd like my result class to be a POJO, following the Immutable pattern (avoiding the "setXYZ" methods and putting all the parameters in the constructors). If I'm not wrong, I cannot do that directly with SqlMaps.
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-50) Ability to override the default bean creation mechanism
Posted by "Aitor Imaz (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_58237 ]
Aitor Imaz commented on IBATIS-50:
----------------------------------
I agree with the submitter. Programming against interfaces is usually better practice than programming against concrete classes. Furthermore, there are a few situations where an object creation mechanism like the one proposed could be useful.
For instance, to simulate polymorphism on a relational database. Let's say you have a "SHAPES" table with a "TYPE" column, where TYPE 1 = Circle, TYPE 2 = Square, TYPE 3 = Triangle, etc. If I'm not wrong, there's currently no mechanism to map rows from that table to objects of a Circle, Square and Triangle class, which would all implement a Shape interface. The only way I can think of is to first obtain the type, then create the object, and finally to pass that object to an iBATIS sqlmap and populate the result object.
If iBATIS had a way to delegate class instantiation, such a problem could be solved. Something along the lines of what the submitter proposed and the TypeHandlerCallback mechanism could be used:
public interface InstanceFactory {
Object createInstance(ResultGetter getter);
}
A possible implementation being:
(...)
public Object createInstance(ResultGetter getter) {
Shape shape = null;
if (getter.getInt() == 1) {
shape = new Circle();
} else if (getter.getInt() == 2) {
shape = new Square();
}
...
return shape;
}
(...)
A "factory" result property would have to be specified per resultmap, which would be evaluated before the result object creation.
I'm sure there are a few more examples of possible uses for a mechanism as the one proposed.
> 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
[jira] Commented: (IBATIS-50) Ability to override the default bean creation mechanism
Posted by "Philippe Laflamme (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_58255 ]
Philippe Laflamme commented on IBATIS-50:
-----------------------------------------
I'd like to comment on the points you made Clinton...
1) I understand your point that state objects shouldn't have different behaviours. But it is reasonable that a state can be extended to add behaviour in certain contexts. Take unit testing for example: from a common interface, you could create an extended version of a state object with some sort of "validation" behaviour so it can validate itself. Also, proxies could be used to inject all sorts of security, profiling, logging, etc. functionalities, that do not alter the bean's behaviour.
2) My statement in regards to the needs of a no-arg constructor was not a complaint. I was simply stating that the requirement could limit the ability to integrate iBatis into non-standard "legacy" applications. Also, the JavaBeans specification provides the Beans.instantiate() method which is designed (amongst other things) to isolate calling classes from the bean instantiation mechanism. This, I think, is the whole issue here: isolation.
3) I agree. Where can I read about the <subclass> element?
We might not agree on the intended uses mentioned (I'm not saying they're good ideas anyway), but would you agree that isolating iBatis from the bean instantiation mechanism is important? Personally I think it would provide greater flexibility to your framework without pushing the burden onto users.
> 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
[jira] Commented: (IBATIS-50) Ability to override the default bean creation mechanism
Posted by "Kishore Koya (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_12315499 ]
Kishore Koya commented on IBATIS-50:
------------------------------------
What would be the good starting place to make changes to iBatis source for Factory based instantiation.
We are currently looking at xmlBeans generated (Factory based instantiation) classes, for our project.
By the way, when is this feature available in iBatis, approximate time....
Thanks,
Kishore.
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-50) Ability to override the default bean creation mechanism
Posted by "Oleg Shpak (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_12319991 ]
Oleg Shpak commented on IBATIS-50:
----------------------------------
Because I need factories very much I had a go at hacking iBatis.
If iBatis developers are interested I would be glad to send them the modified files/diff.
Of course, I do not think that what I did is a complete solution and that it is implemented in the most correct way.
My idea was very simple (maybe overly simple):
- I added getFactory/setFactory to ResultMap iface and implemented it in BasicResultMap. I added the setter because I didn't want to mess about with the configuration code. It's fine by me to set the factory in my DAO initialisation.
- defined this interface
public interface ObjectFactory {
Object createInstance(Class resultMapClass);
}
- patched 2 classes in com.ibatis.sqlmap.engine.exchange
ComplexDataExchange and JavaBeanDataExchange
replaced line (2 occurencies in every file).
object = Resources.instantiate(resultMap.getResultClass());
with
if(resultMap.getFactory()!=null)
object = resultMap.getFactory().createInstance(resultMap.getResultClass());
else
object = Resources.instantiate(resultMap.getResultClass());
that's all.
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira