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

Strict mapping convention also tries to find matches for private fields #78

Closed
robert-bor opened this issue Oct 4, 2017 · 1 comment
Assignees
Labels

Comments

@robert-bor
Copy link
Contributor

robert-bor commented Oct 4, 2017

The strict mapping convention also triggers on private fields. This should not be the case.

Form:

public class SCSourceAForm {
    public String name;
    private String doesNotExist;

    public void setDoesNotExist(String doesNotExist) {
        this.doesNotExist = doesNotExist;
    }
    public String getDoesExist() { 
        return this.doesNotExist;
    }
}

Result:

public class SCTargetA {
    public String name;
    public String doesExist;
}

Test

    @Test
    public void strictMappingConventionWithPrivateField() {
        SCSourceAForm source = new SCSourceAForm();
        source.name = "Alpha";
        source.setDoesNotExist("some value");
        SCTargetA target = beanMapper.map(source, SCTargetA.class);
        assertEquals("Alpha", target.name);
        assertEquals("some value", target.doesExist);
    }

Results in the validator throwing an exception:

Missing matching properties for source [io.beanmapper.testmodel.strictconvention.SCSourceAForm]* > target [io.beanmapper.testmodel.strictconvention.SCTargetA] for fields:
> SCSourceAForm.doesNotExist
@robert-bor robert-bor added the bug label Oct 4, 2017
@robert-bor robert-bor self-assigned this Oct 4, 2017
robert-bor added a commit that referenced this issue Oct 4, 2017
…resulting in it always returning true when asked if it was readable. This resulted in more properties being marked as mapping candidates. This then resulted in the strict mapping convention validation failing, because matching properties on the other side were missing.
@robert-bor
Copy link
Contributor Author

Root cause was error in FieldPropertyAccessor.isReadable. Method always returned true.

robert-bor added a commit that referenced this issue Oct 24, 2017
Issue #83 In the resolution of issue #78 the definition of getter fields has been tightened, because previously all private fields were tagged as available as well. One project made use of this loophole by reading the name field of an enumeration class to a String field. With the new fix this is no longer possible, since the name field is private.

This fix makes an exception for the name field of an enum class. It will be considered available for reading.
robert-bor added a commit that referenced this issue Oct 24, 2017
Issue #83 In the resolution of issue #78 the definition of getter fields has been tightened, because previously all private fields were tagged as available as well. One project made use of this loophole by reading the name field of an enumeration class to a String field. With the new fix this is no longer possible, since the name field is private.

This fix makes an exception for the name field of an enum class. It will be considered available for reading.
robert-bor added a commit that referenced this issue Oct 24, 2017
Issue #83 In the resolution of issue #78 the definition of getter fields has been tightened, because previously all private fields were tagged as available as well. One project made use of this loophole by reading the name field of an enumeration class to a String field. With the new fix this is no longer possible, since the name field is private.

This fix makes an exception for the name field of an enum class. It will be considered available for reading.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant