1

Let's imagine, there are 1000 classes (X1...X1000) which are all defined in a library abc.jar.

The X* classes have used some JSR-330 annotations, like:

class X12 { @Inject Foo foo; @Inject Bar bar; }

My main class is a test case @RunWith(SpringJUnit4ClassRunner.class), and the referenced Foo, Bar are well defined in the bean XML files.

The question is, I don't want to define X1...X1000 in any XML files. But I'd like to auto wire them, for example:

X173 x173 = new X173();

But the problem is, using Java new instance, foo/bar isn't wired.

This also not works: 

X173 x173 = applicationContext.getBean(X173.class);

because no bean for X173 is defined.

And, X173 may also contains a member of class X258 which should be wired, too. I can't figure out how to implement it until I've resolved this question.

Improve this question

2 Answers 2

Reset to default
3

You can use autodetection to declare them as Spring beans.

The most obvious way is to annotate these classes with Spring annotations such as @Component and then add <context:component-scan /> to your XML.

If annotating is not an option, <context:component-scan /> supports configurable filters. For example, if these classes are actually named X1...X1000, you can use regexp filter:

<context:component-scan base-package="com.example"> <context:include-filter type="regex" expression="com\.example\.X\d{1,4}"/> </context:component-scan>
Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Unfortunately, the class names are arbitrary. hmm.. I think component-scan will get unnecessary side-effects. When I write applicationContext.getBean(X173.class), I know exactly what will be injected, but component-scan looks rough.
@继雷'Lenik: Your problem goes against the concept of Spring, since Spring creates beans from predefined bean definitions, not in ad-hoc manner. You can create a bean without definition with applicationContext.getAutowireCapableBeanFactory().createBean(X173.class), but it doesn't satisfy the last requirement (interdependencies of beans).
Great tip! Say F=AutowireCapableBeanFactory, then I can replace all new X by F.createBean(X.class) in the library implementation. And that's just what I want. I think it's clear, and not against the Spring concept, anyhow. Thanks.
0

Ok. There is different types of testing. Let's look at too of them.

  • In modular testing you should test single class and mock it's dependency. So, you should avoid any injector.

  • In integration you should test some class's interaction, so you can use injector as in usual application.

Improve this answer

5 Comments

For modular testing, why not just inject with mocked instance? (By specify a test-purpose context xml)
@谢继雷'Lenik, The best injection is constructor injection. So, in modular testing, you should provide some instances to constructor. It can be and should be mock's.
@谢继雷'Lenik, I didn't get "mocked instance". Can you clarify it, please.
I mean the fake instance, for example, the mocked instance for FileSystem maybe just print logs, but don't do anything harmful. Sorry for my english, HTH.
@谢继雷'Lenik, my mocking dependency I mean exactly fake instances. So I don't need do any Spring IOC in your modular tests. BTW, Sorry for my english too)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.