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

Comments

3 participants
@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.

Show comment
Hide comment
@rliesenfeld

rliesenfeld Nov 9, 2016

Member

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

Member

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.

Show comment
Hide comment
@AlexStasko

AlexStasko Nov 9, 2016

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

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.

Show comment
Hide comment
@rliesenfeld

rliesenfeld Nov 9, 2016

Member

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?

Member

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.

Show comment
Hide comment
@siarhei-usau

siarhei-usau 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?

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.

Show comment
Hide comment
@AlexStasko

AlexStasko 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"

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.

Show comment
Hide comment
@siarhei-usau

siarhei-usau Nov 10, 2016

codestyle problems

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

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.

Show comment
Hide comment
@rliesenfeld

rliesenfeld Nov 10, 2016

Member

Ok, camel case can be supported too.

Member

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