Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error "Missing @Injectable for field" with @Resource annotation #359

Closed
AlexStasko opened this issue Nov 9, 2016 · 7 comments
Closed

Error "Missing @Injectable for field" with @Resource annotation #359

AlexStasko opened this issue Nov 9, 2016 · 7 comments
Assignees
Labels

Comments

@AlexStasko
Copy link

@AlexStasko AlexStasko commented Nov 9, 2016

I use JMockit 1.28 (tried 1.29)
Java 1.8.92

I work with @Resource annotation. But with name value my tests not working. Without it tests work fine.
Console output:

java.lang.IllegalStateException: Missing @Injectable for field "by.common.model.DummyDomain dummyDomain" in DummyService

Also if using @Autowired with @Qualifier tests work fine.
Test case is here: jmockit-check.zip

I use something like this as workaround:

    @BeforeMethod
    public void setUp() {
        dummyService = new DummyService();
        ReflectionTestUtils.setField(dummyServie, "dummyDomain", mockDummyDomain);
    }

Might be that is a bug, maybe I 'm doing something wrong. Thank you in advance and hope for your help.

Thank you,
Alex

@rliesenfeld rliesenfeld added the question label Nov 9, 2016
@rliesenfeld

This comment has been minimized.

Copy link
Member

@rliesenfeld rliesenfeld commented Nov 9, 2016

The @Injectable field should match the name of the target @resource ("test"). So, name it "test".

@AlexStasko

This comment has been minimized.

Copy link
Author

@AlexStasko AlexStasko commented Nov 9, 2016

@rliesenfeld in my project I use names like "subname1.subname2.name" and in this case I cannot name field with dots.

@rliesenfeld

This comment has been minimized.

Copy link
Member

@rliesenfeld rliesenfeld commented Nov 9, 2016

The names need to match, otherwise it's not possible to support a scenario where multiple @resource's of the same type are injected into a given object.

Name matching can be made more flexible, though. I am thinking of two possible solutions, when given a resource name composed of multiple parts separated by special characters such as "." (dot) or "-" (hyphen):

  1. Use only the last name part. So, if the resource is named "part1.part2.last", then the @Injectable would need to be named "last".
  2. Use the full resource name, but replacing separator characters with the underscore "_" character, which can be used in the name of the injectable: "@Injectable Xyz part1_part2_last".

Which solution would you prefer?

@siarhei-usau

This comment has been minimized.

Copy link

@siarhei-usau siarhei-usau commented Nov 9, 2016

I am tech lead of the project so let me answer.
Var N2 looks definitely better but my previous question is still valid I think.

How possible to support a scenario where multiple @Autowied with @Qualifier the same type are injected into a given object? Because as I mentioned if change in the test case @Resource ("test") to
@Autowired
@Qualifier("test)
(which is same thing from Spring prospective) it works. Might be if multiple @Resource but with different types we can use the same "@Autowired " approach?

@rliesenfeld rliesenfeld added enhancement and removed question labels Nov 9, 2016
@rliesenfeld rliesenfeld self-assigned this Nov 9, 2016
@AlexStasko

This comment has been minimized.

Copy link
Author

@AlexStasko AlexStasko commented Nov 10, 2016

Thanks for your suggestions. But if we will use solution with underscore we will face with codestyle problems. In this case can we use camelcase solution? Something like this:
name = "part1.part2.name"
field name = "part1Part2Name"

@siarhei-usau

This comment has been minimized.

Copy link

@siarhei-usau siarhei-usau commented Nov 10, 2016

codestyle problems

Good catch, I didn't release that. Camelcase is definitely better

@rliesenfeld

This comment has been minimized.

Copy link
Member

@rliesenfeld rliesenfeld commented Nov 10, 2016

Ok, camel case can be supported too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.