

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
4 messages in net.java.dev.appfuse.usersRe: [appfuse-user] multiple datasourc...| From | Sent On | Attachments |
|---|---|---|
| Steve Tynor | Feb 1, 2006 5:25 pm | |
| Matt Raible | Feb 1, 2006 7:32 pm | |
| Steve Tynor | Feb 2, 2006 6:22 am | |
| Matt Raible | Feb 2, 2006 6:42 am |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [appfuse-user] multiple datasources vs. AbstractTransactionalDataSourceSpringContextTests | Actions... |
|---|---|---|
| From: | Matt Raible (mrai...@gmail.com) | |
| Date: | Feb 1, 2006 7:32:42 pm | |
| List: | net.java.dev.appfuse.users | |
I've run into this a couple of times and here is my recommended solution:
1. Name one of your beans "dataSource". 2. In BaseDAOTestCase.getConfigLocations(), set the autowireMode to byName.
protected String[] getConfigLocations() { setAutowireMode(AUTOWIRE_BY_NAME); return new String [] {"classpath*:/**/dao/applicationContext-*.xml", "classpath*:META-INF/applicationContext-*.xml"}; }
Of course, you could also do this in the constructor.
If you don't want to rename your bean to datasource, turn off dependency checking.
protected String[] getConfigLocations() { setAutowireMode(AUTOWIRE_BY_NAME); setDependencyCheck(false); return new String [] {"classpath*:/**/dao/applicationContext-*.xml", "classpath*:META-INF/applicationContext-*.xml"}; }
Then create appropriately named setters in your test for both of your datasources:
public void setDataSource1(DataSource ds) public void setDataSource2(DataSource ds)
Where your datasources are named "dataSource1" and "dataSource2". I'm considering making byName the default in AppFuse since I've seen this issue crop up a fair amount with AbstractTransactionalDataSourceSpringContextTest (phew - that's a lot to type).
Matt
On 2/1/06, Steve Tynor <tyn...@iintiip.com> wrote:
Matt et. al,
I'm a very happy user of Equinox 1.5 (and Appfuse 1.8 before that), but have run into a tussle with Spring which I've not managed to solve. Perhaps someone on the list has faced a similar problem and can guide me in the right direction.
I've added a second data source to my application. Suddenly my nice unit tests no longer work since the Spring autowire finds two DataSource beans and can't decide which to wire to my test DAO's. I'm using the fancy dancy Spring transactional test support class (AbstractTransactionalDataSourceSpringContextTests) as configured by Equinox:
[junit] Error creating bean with name 'com.myco.dao.MydataDAOTest' defined in null: Unsatisfied dependency expressed through bean property 'dataSource': There are 2 beans of type [interface javax.sql.DataSource] for autowire by type. There should have been 1 to be able to autowire property 'dataSource' of bean 'com.myco.dao.MydataDAOTest'.
No problem says I, the Spring manual tells me what I need to do: (section 23.2.2):
"The superclasses use autowire by type. Thus if you have multiple bean definitions of the same type, you cannot rely on this approach for those particular beans. In that case, you can use the inherited applicationContext instance variable, and explicit lookup using getBean()."
Howsoever, they don't document just exactly _where_ to call getBean... If I do it in the test class constructor, the applicationContext variable is not yet initialize (i.e. null). If i do it in the onSetUp() callback, it's too late -- the setUp() function doesn't call that until after it's wired up the beans...
The docs for the spring classes also say you can turn off wire-by-type and use wire-by-name, but that appears to require that I lace up a lot of other beans that I'm not in direct control of -- finding a way to simply override this one bean seems like the right solution, but i'm not seeing how...
Google has not come to the rescue. Ever used these classes and faced a similar quandry?
Thanks! Steve







