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 messes up the build sequence #112

Closed
robert-bor opened this issue Jun 19, 2018 · 0 comments
Closed

Strict mapping messes up the build sequence #112

robert-bor opened this issue Jun 19, 2018 · 0 comments
Assignees
Labels

Comments

@robert-bor
Copy link
Contributor

When strict mapping is in place, List mapping is hampered. What currently happens is that collection handlers cannot be found. The result is that no collection instructions are attached to a pair of fields, resulting in the collection converter not being chosen.

This code in BeanMapperBuilder is the culprit:

    public BeanMapper build() {
        BeanMapper beanMapper = new BeanMapper(configuration);
        // Make sure all strict bean classes have matching properties on the other side
        configuration.getBeanMatchStore().validateStrictBeanPairs(configuration.getBeanPairs());
        // Custom collection handlers must be registered before default ones
        addCollectionHandlers(customCollectionHandlers);
        addCollectionHandlers(DEFAULT_COLLECTION_HANDLERS);
        // Custom bean converters must be registered before default ones
        addCustomConverters();
        if (configuration.isAddDefaultConverters()) {
            addDefaultConverters();
        }
        return beanMapper;
    }

The validateLine triggers the verification of mappings before the full BeanMapper build has taken place.

The validation needs to take place after the build has completed, not before.

@robert-bor robert-bor added the bug label Jun 19, 2018
@robert-bor robert-bor self-assigned this Jun 19, 2018
robert-bor added a commit that referenced this issue Jun 19, 2018
Bug #111; when a source and target have been assigned to a collection
 handler, it will now treat a null value for the source as special,
 subscribing it to the BeanCollectionUsage rules (default: CLEAR).
 That is, it will REUSE the target, CLEAR it, or CONSTRUCT a new one.
 This is the most logical behaviour with Hibernate on the other side.

Bug #112 The validation took place before all configuration was done,
 resulting in collection handlers not being available in some cases.
 The validation of strict classes is done as part of the last step of
 the ```BeanMapperBuilder.build()``` method, after all required steps
 have been taken.
robert-bor added a commit that referenced this issue Jun 19, 2018
Bug #111; when a source and target have been assigned to a collection
 handler, it will now treat a null value for the source as special,
 subscribing it to the BeanCollectionUsage rules (default: CLEAR).
 That is, it will REUSE the target, CLEAR it, or CONSTRUCT a new one.
 This is the most logical behaviour with Hibernate on the other side.

Bug #112 The validation took place before all configuration was done,
 resulting in collection handlers not being available in some cases.
 The validation of strict classes is done as part of the last step of
 the ```BeanMapperBuilder.build()``` method, after all required steps
 have been taken.
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