Spring component scan and StoredProcedure

Let’s say you wrap stored procedures with Spring’s StoredProcedure class like this:

That @Repository annotation, like @Component and @Service, allows you to tell Spring to scan the
classpath and instantiate them without you having to write a bean element in your Spring XML file.
You can even inject dependencies like the DataSource with the @Autowired annotation as you see here.

You enable it with this in your XML config file:

It will recursively scan the package you specify for these annotations. You will get a bean in your context
with the simple classname. (You can override that if you want).

N.B. this used to be aop:component-scan but it was moved.

Then in some DAO you can do this:

Pretty cool. Unless you use AOP – and hey, you’re just not hip and happenin’ if you’re not right?

Turn the logging level up and you will indeed see Spring create the SP. But then it will fail when creating your
DaoImpl saying that there is no bean that satisfied the dependency on the SP class. But two lines above that
it just said it has the bean in the context. WTF?

Here’s a clue. Do this:

You’ll see that Spring’s StoredProcedure class does not have a default constructor so there is a problem creating the proxy.

What RJ says in his Intro to Spring 2.5 article about StoredProcedures is that you can have them implement an interface blah blah fishcake…
Something like this.

Sure enough that solves the problem. OK, interfaces are good.
A glass of wine is good too. Drinking a vat of wine will kill you.