autowire byType

[Jeanne Boyarsky]

I'm playing with auto-wiring and seeing something unexpected. The following xml throws an exception complaining there are two beans of type Parent. This I expect. However, if I use a bean id of "mother" instead of "mom", it autowires that one in.

<bean id="dad" class="example.Parent">
  <property name="name" value="Peter" />
</bean>

<bean id="mom" class="example.Parent">
  <property name="name" value="Mary" />
</bean>

<bean id="child" class="example.Child" autowire="byType" />
 

Allows a property to be autowired if exactly one bean of the property type exists in the container. If more than one exists, a fatal exception is thrown, which indicates that you may not use byType autowiring for that bean. If there are no matching beans, nothing happens; the property is not set. If this is not desirable, setting the dependency-check="objects" attribute value specifies that an error should be thrown in this case.

The documentation (for Spring 3) doesn't say it defaults to byName if byType has multiple matches. Does it? Or am I seeing an undocumented side effect/feature?

[Christophe Verré]

Mmmmhhh... An exception is raised in Spring 2.5. Would this be an undocumented feature ? Either the documentation is not up to date, or this is a bug. I'd point my finger toward the later.

[Mark Spritzler]

Is your setter method called setMother?

I am confused as to why changing the bean name makes a difference. You have a method or constructor that takes a Parent object correct?

Can you post the code?

Thanks

Mark

btw. I think it is so cool Jeanne that you are learning Spring, and hopefully means you can get away from Websphere and EJBs. ;)

[Jeanne Boyarsky]

Mark Spritzler wrote:Is your setter method called setMother?

Yes. That's why it looks like it is matching by name after type. But the documentation states it doesn't hence thinking I am missing something obvious.

Mark Spritzler wrote:Can you post the code?

Of course. It's a toy example not a secret .

Mark Spritzler wrote:btw. I think it is so cool Jeanne that you are learning Spring, and hopefully means you can get away from Websphere and EJBs. ;)

I've read a couple books about Spring over the years and tried some toy examples. This time is different as I'm actually going through things in detail with a computer. I'm also reading EJB 3 in Action as a guide which is helping me be detailed about it.

And the code:

package example;

public class Child {
	
	private Parent mother;

	public Parent getMother() {
		return mother;
	}

	public void setMother(Parent mother) {
		this.mother = mother;
	}

}

package example;

public class Parent {
	
	private String name;

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

}

[Mark Spritzler]

I've duplicated your findings and it looks like you found an undocumented feature.

Mark

[Jeanne Boyarsky]

Mark Spritzler wrote:I've duplicated your findings and it looks like you found an undocumented feature.

Whoo hoo! Finding an undocumented feature beats the pants off not understanding something simple!

[Mark Spritzler]

Lets see what the guys at SpringSource say about it.

http://forum.springsource.org/showthread.php?p=285994#post285994

Mark

[Mark Spritzler]

Sorry, I did it wrong, I only configured on Parent. When I put two Parents, but still had "mother" as id, I got the exception that you would expect, and it didn't work.

I am using Spring 3.0

Mark

[Jeanne Boyarsky]

Mark,
That was actually helpful in narrowing things down. (time consuming, but still helpful)

There's a difference in our examples. Mine uses mother as both the parameter and method name. Apparently that matters because I tried it with your example. As provided, it throws the advertised exception. When I changed the parameter name to "mother", it stopped throwing the exception. I posted this in the springsource thread as well,.

public void setMother(Parent mother) 
public void setMother(Parent parent) 

It's weird because I don't see any of the wiring options where it matters what the parameter name is.

In any case, I now have 100% confidence that I'm not missing something stupid, which is why I posted this thread . Thanks.

[Christophe Verré]

By chance, I made the exact same sample as Jeanne, setMother(Parent mother). That's why I didn't get any exception either.

Spring Log:
[org.springframework.beans.factory.support.DefaultListableBeanFactory] - Eagerly caching bean 'child' to allow for resolving potential circular references
[org.springframework.beans.factory.support.DefaultListableBeanFactory] - Returning cached instance of singleton bean 'dad'
[org.springframework.beans.factory.support.DefaultListableBeanFactory] - Returning cached instance of singleton bean 'mother'
[org.springframework.beans.factory.support.DefaultListableBeanFactory] - Autowiring by type from bean name 'child' via property 'mother' to bean named 'mother'

[Ben Logan]

I think I've just done the same thing - very helpful post!

Mind you, defaulting to byName if byType isn't unique sounds like a it would be a good feature. Or horribly dangerous, come to think of it.

[Jeanne Boyarsky]

Except that it's not by property name. Or even method name. It's by method parameter name. Which seems weird.

[Jeanne Boyarsky]

Conclusion: Spring is using the parameter name for auto-wiring if you compile with debug info enabled. It is now logged in JIRA as SPR-6917

[Christophe Verré]

Spring 3.0.2 has been released and this bug is fixed.

[Jeanne Boyarsky]

Sweet. Thanks for noticing.