Factory Method Overload matching

[Great]

First off I am using Spring.NET 1.1 Preview 3 and .net 2.0

My configuration looks like this:


<object id="Location" type="MyStuff.Location, MyStuff" singleton="false"
factory-object="LocationFactory" factory-method="CreateInstance"></object>
<object id="LocationFactory" type ="MyStuff.Factory.LocationFactory, MyStuff"
abstract="false" singleton="true"></object>

My LocationFactory looks like this.

public class LocationFactory
{

public Location CreateInstance()
{
return new Location();
}
public Location CreateInstance(DataRow dr)
{
return new Location(dr);
}

public Location CreateInstance(IDataRecord dr)
{
return new Location(dr);
}
}

My issue is when I "GetObject" using the AbstractObjectFactory with a SqlDataReader as my argument, it tries to match it with the DataRow Overload when it should match the IDataRecord overload. The DataRow overload is matching correctly only because it is first. Please take a look at the Spring.Objects.Factory.Support.AbstractAutoWireCap ableObjectFactory class in the method InstantiateUsingFactoryMethod(string name, RootObjectDefinition definition, object[] arguments). I believe for some reason the correct overload is not being matched here. And remember I am using 2.0.

[Mark Pollack]

Hi,

Thanks for reporting this. I've created a JIRA (http://opensource.atlassian.com/projects/spring/browse/SPRNET-517) entry and will fix it asap.

As a work around in the meantime, if you are going to be calling 'GetObject' directly in your code, you can create prototype instances directly passing in constructor arguments via the following call to GetObject

public object GetObject(string name, object[] arguments)

You then don't need to have your own custom LocatorFactory class for this purpose. You can also define properties to wire up for your prototype instance, in effect mixing runtime values with spring singletons defined at compile-time.

This thread (http://forum.springframework.net/showthread.php?t=2289), at the end, shows more detailed usage. The current wiring is by type, which will change to by position (at a minimum), in the future, so it is more robust. However, this is sufficient for your case. I'll be updating the docs as well of course once this is done as this comes up quite alot!

Cheers,
Mark

[Mark Pollack]

Hi,
This issue is now fixed, though I will be refactoring the implementation to make it cleaner internally. You can pick up the nighly download from 6/15 to get the fix.
Cheers,
Mark