|
Sort Order:
Yes, I'm sure that can be done but it's non-trivial in this project because it's large and has been working this way for some time. I will find a way to make this work but thought I'd run it by your team first in case it made sense to change the component scanner behavior. OK, I just checked that even the very same class file sitting in the classpath twice leads to this sort of problem... I'll see what we can do about it for 2.5.6. Juergen ClassPathBeanDefinitionScanner ignores the same class found multiple times in the classpath now (i.e. it ignores equal bean definitions, even when coming from different source files). This will be available in tonight's 2.5.6 snapshot (http://static.springframework.org/downloads/nightly/snapshot-download.php?project=SPR Juergen This is working great, thanks for the help. Hi, I think that we encountered the same problem with buildr cobertura run. It puts the same class in target/classes/ as well as in target/instrumented . Why it uses both paths in the classpaths I don't know. Our build works on 2.5.4 and 2.5.6-SNAPSHOT. So thanks for the fix! And awaiting for 2.5.6 release. |
||||||||||||||||||||||||||||||||||||||
Improvement
Resolved
Major
Component scanner doesn't recognize same beans when included multiple times on classpath
IMHO something is wrong in your test classpath setup if the classes are available twice, with the classes in the "nearest" classpath root getting picked up. I find this rather strange... Can't you set up your test classpath such that either the regular classes or the instrumented classes are available, but never both at the same time?
Juergen