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

Incorrect target type with wildcard List #18767

Closed
hban opened this issue Oct 28, 2019 · 3 comments
Closed

Incorrect target type with wildcard List #18767

hban opened this issue Oct 28, 2019 · 3 comments
Assignees
Labels
type: bug A general bug
Milestone

Comments

@hban
Copy link

hban commented Oct 28, 2019

When constructor for ConfigurationProperties bean has wildcard parameters, Boot doesn't apply converters, but instead keeps String as-is.

For example, if parameter is Map<String, ? extends List<? extends InetAddress>> (this is how Kotlin translates List<String, Map<InetAddress>> into Java bytecode), Boot will pass into constructor a map of lists of strings, while it should have converted those strings into InetAddresses.

Reproducer:

package net.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.boot.context.properties.ConstructorBinding;
import org.springframework.context.ConfigurableApplicationContext;

import java.net.InetAddress;
import java.util.List;
import java.util.Map;

@SpringBootApplication
public class ExampleApplication {

    public static void main(String[] args) {
        ConfigurableApplicationContext ctx = SpringApplication.run(ExampleApplication.class, args);
        ExampleProperties properties = ctx.getBean(ExampleProperties.class);

        // OK.
        System.out.println(properties.getAddresses1().get("localhost").get(0).getHostAddress());

        // ClassCastException: class java.lang.String cannot be cast to class java.net.InetAddress
        System.out.println(properties.getAddresses2().get("localhost").get(0).getHostAddress());
    }

    @ConstructorBinding
    @ConfigurationProperties("example")
    public static class ExampleProperties {
        private final Map<String, List<InetAddress>> addresses1;
        private final Map<String, ? extends List<? extends InetAddress>> addresses2;

        public ExampleProperties(Map<String, List<InetAddress>> addresses1, Map<String, ? extends List<? extends InetAddress>> addresses2) {
            this.addresses1 = addresses1;
            this.addresses2 = addresses2;
        }

        public Map<String, List<InetAddress>> getAddresses1() {
            return addresses1;
        }

        public Map<String, ? extends List<? extends InetAddress>> getAddresses2() {
            return addresses2;
        }
    }

}
example:
    addresses1:
        localhost:
            -   127.0.0.1
    addresses2:
        localhost:
            -   127.0.0.1
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Oct 28, 2019
@snicoll snicoll changed the title Heap pollution with ConstructorBinding Incorrect target type with wildcard List Oct 28, 2019
@snicoll
Copy link
Member

snicoll commented Oct 28, 2019

Thanks for the sample. I've edited your title to clarify the issue is not related to constructor binding (I can reproduce with regular JavaBean accessors as well).

@snicoll snicoll added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels Oct 28, 2019
@snicoll snicoll added this to the 2.1.x milestone Oct 28, 2019
snicoll added a commit to snicoll/spring-boot that referenced this issue Oct 28, 2019
@mbhave mbhave self-assigned this Dec 5, 2019
@mbhave
Copy link
Contributor

mbhave commented Dec 5, 2019

This is a bug in Spring Framework's ResolvableType class. I'll leave this issue open so that we can add a test for this case in MapBinderTests.

@mbhave mbhave added the status: blocked An issue that's blocked on an external project change label Dec 5, 2019
@philwebb
Copy link
Member

philwebb commented Dec 5, 2019

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

No branches or pull requests

5 participants