autowiring by type (AbstractTransactionalDataSourceSpringContextTests )

[kreismeister]

Hi!

Spring 2.0 RC1 build 44.

I've followed the petclinic example that comes with the distribution to implement a simple DAO using Spring's JdbcDaoSupport.

So there is an interface MyDao and an implementation MyJdbcDaoImpl.

I then created a test case that inherits from AbstractTransactionalDataSourceSpringContextTests and I get an exception when executing this test case.

Error creating bean with name 'MyJdbcDaoImplTest': Unsatisfied dependency expressed through bean property 'myDao': There are 2 beans of type [interface MyDao] for autowire by type....

Now I'm a little bit confused. There are two types but one is an interface. Why is Spring unable to resolve this?

Any ideas?

Thanks,
KM

[gmazza]

I guess the best answer to your question may ironically be a non-answer: Rob Harrop, in his ProSpring book (p. 87) does recommend avoiding autowiring to begin with. ("For any non-trivial application, steer clear of auto-wiring at all costs.")

Perhaps the next best answer may also be a non-answer: Why do you need to declare a bean that is just an interface (and not an actual class)? What use would it serve?

Finally, the third best answer may be the real answer for you here: Once you determine the use case for having an interface as a bean, that is probably a reason why Spring cannot simply ignore bean-interfaces and just go with the bean-class while autowiring (and further, only raising a complaint if more than one *class* of a given type is declared.)

You seem to be saying on one hand, that you should be able to declare interfaces as beans alongside classes implementing them because they serve a useful purpose, and, on the other, that Spring should be ignoring them when matching by type because interfaces aren't useful as beans. It seems to be a contradiction in thinking here, unless I am missing something (*very* possible here.)

Glen

[kreismeister]

I don't know. I'm just referring to the sample code that is shipped WITH Spring.

And the advantage of this abstract test case is, that is very simply to adapt. You point to the applicationContext.xml from within the test case and that's it. It's very simple and easy to use.

Anyway, I just think that the problem could be avoided in this case because it is really simple. There is only one interface and one implementation. But I agree that it gets ambigious when there are multiple implementations.

I could workaround by making the getMyDao abstract in the test case and having a MyJdbcDaoImpl specific testcase that gets wired by type nicely.

[Costin Leau]

Now I'm a little bit confused. There are two types but one is an interface. Why is Spring unable to resolve this?

Your setter probably accepts the interface so there are two objects (two interface implementations) that can be passed to the setter. That's why Spring doesn't know which one to choose.
Autowiring is something that should not be used in production environments in my opinion but it comes in handy when in tests since you don't have to build separate application contexts for your tests.

[kreismeister]

Your setter probably accepts the interface so there are two objects (two interface implementations) that can be passed to the setter.

Yes, that's how it's implemented in the PetClinic example. And because it is done in the PetClinic example I assumed it's the suggested way of doing tests that way. Maybe I shouldn't trust too much in the examples.

Anyway, I changed it now and it works.

[Costin Leau]

Yes, that's how it's implemented in the PetClinic example. And because it is done in the PetClinic example I assumed it's the suggested way of doing tests that way. Maybe I shouldn't trust too much in the examples.

Using the lowest common element is the best way to go. You can do the wiring by yourself or select a different wiring type (by name for example). Testing should not affect the way you code - it should be the other way around.