Skip to content

Unwrapped fields cannot be resolved in the constructor #4491

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

Closed
kakao-rick-lee opened this issue Sep 1, 2023 · 1 comment
Closed

Unwrapped fields cannot be resolved in the constructor #4491

kakao-rick-lee opened this issue Sep 1, 2023 · 1 comment
Assignees
Labels
type: bug A general bug

Comments

@kakao-rick-lee
Copy link

I am designing a domain object using @unwrapped, but the constructor fails to resolve the Unwrapped Field (age).

public class Age {
    private int age;

    public Age(int age) {
        this.age = age;
    }
}
@Document("mydoc")
public class MyDoc {

    @Id
    private String id;
    private String name;

    @Unwrapped.Empty
    private Age age;

    @PersistenceCreator
    public MyDoc(String id, String name, Age age) {
        this.id = id;
        this.name = name;
        this.age = age;
    }
}

Error Message

No converter found capable of converting from type [java.lang.Integer] to type [com.company.test.mongotest.model.Age]

I've checked with @Vaule and SpEl that it's possible to use the code below, but I don't think it's a good idea. Is there any way to automatically resolve unwrapped fields in the constructor?

public class MyDoc {

    // omitted

    @PersistenceCreator
    public MyDoc(String id, String name, @Value("new com.company.test.mongotest.model.Age(age)") Age age) {
        this.id = id;
        this.name = name;
        this.age = age;
    }
}
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Sep 1, 2023
@mp911de mp911de added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels Sep 1, 2023
@mp911de
Copy link
Member

mp911de commented Sep 1, 2023

This sounds pretty much like a bug where we do not consider the proper conversion path.

@mp911de mp911de self-assigned this Sep 1, 2023
mp911de added a commit that referenced this issue Sep 1, 2023
Return the value to set instead of calling the accessor directly. Remove duplicate calls to resolve associations.

See #4491
mp911de added a commit that referenced this issue Sep 1, 2023
Remove sysout from tests.

See #4491
christophstrobl pushed a commit that referenced this issue Sep 11, 2023
christophstrobl pushed a commit that referenced this issue Sep 11, 2023
Return the value to set instead of calling the accessor directly. Remove duplicate calls to resolve associations.

See #4491
christophstrobl pushed a commit that referenced this issue Sep 11, 2023
Remove sysout from tests.

See #4491
christophstrobl pushed a commit that referenced this issue Sep 11, 2023
christophstrobl pushed a commit that referenced this issue Sep 11, 2023
Return the value to set instead of calling the accessor directly. Remove duplicate calls to resolve associations.

See #4491
christophstrobl pushed a commit that referenced this issue Sep 11, 2023
Return the value to set instead of calling the accessor directly. Remove duplicate calls to resolve associations.

See #4491
christophstrobl pushed a commit that referenced this issue Sep 11, 2023
Remove sysout from tests.

See #4491
@christophstrobl christophstrobl added this to the 4.0.10 (2022.0.10) milestone Sep 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants