2016-11-21 5 views
2

Ich erfahre wirklich merkwürdiges Verhalten von Frühling. Ich habe eine @Bean, die eine Map zurückgibt. Wenn die Bean jedoch @Autowired ist, unterscheidet sich der Schlüssel für die Zuordnung von dem, was in der @Bean-Methode zugewiesen wurde. Meine @Bean hat zwei Eingabeparameter, die auch Spring Beans aus einer anderen Konfigurationsklasse sind. Einmal @Autowired Die Schlüssel meiner Karte werden geändert, um den Namen der @Bean Methoden zu entsprechen, die als Abhängigkeiten in meiner Karte zurückgegeben werden, die Bean zurückgibt. Die fragliche @Bean befindet sich in einer @ConfigurationProperties Klasse, in der ich einige Werte aus meiner application.yml-Datei extrahiere, die alle korrekt zurückgegeben werden.Frühling, der Bean bei der Rückkehr unnötig ändert

@Component 
@ConfigurationProperties(prefix = "channel-broker") 
@EnableConfigurationProperties 
public class ChannelLookupConfig { 

    private String messageDeliveryChannelKey; 

    private String otherDeliveryChannelKey; 


    public String getMessageDeliveryChannelKey() { 
     return messageDeliveryChannelKey; 
    } 

    public void setMessageDeliveryChannelKey(String messageDeliveryChannelKey) { 
     this.messageDeliveryChannelKey = messageDeliveryChannelKey; 
    } 

    public String getOtherDeliveryChannelKey() { 
     return otherDeliveryChannelKey; 
    } 

    public void setOtherDeliveryChannelKey(String OtherDeliveryChannelKey) { 
     this.otherDeliveryChannelKey = OtherDeliveryChannelKey; 
    } 

    @Bean 
    public Map<String, MessageDeliveryClient> channelCallerLookup(MessageDeliveryClient MessageDispatcherClient, MessageDeliveryClient otherDeliveryClient) { 
     Map<String, MessageDeliveryClient> channelCallerLookup = new HashMap<>(); 
     channelCallerLookup.put(messageDeliveryChannelKey, MessageDispatcherClient); 
     channelCallerLookup.put(otherDeliveryChannelKey, otherDeliveryClient); 
     return channelCallerLookup; 
    } 
} 

Meine zweite Konfigurationsdatei

@Configuration 
public class Config { 
    @Bean 
    public MessageDeliveryClient MessageDispatcherClient() { 
     MessageDeliveryClient client = MessageDeliveryClient.builder() 
       .awsAccessKey(destinationSqsAccessKey) 
       .awsSecretKey(destinationSqsSecretKey) 
       .awsRegion(destinationSqsRegion) 
       .destinationQueueName(destinationSqsName) 
       .build(); 
     return client; 
    } 

    @Bean 
    public MessageDeliveryClient otherPickerDeliveryClient() { 
     MessageDeliveryClient client = MessageDeliveryClient.builder() 
       .awsAccessKey(destinationSqsAccessKey) 
       .awsSecretKey(destinationSqsSecretKey) 
       .awsRegion(destinationSqsRegion) 
       .destinationQueueName(destinationOtherPickerSqsName) 
       .build(); 
     return client; 
    } 
} 

Autowired in zur Verwendung als solche:

public class SimpleCustomerMessageDeliveryBrokerImpl implements CustomerMessageDeliveryBroker { 
     private Map<String, MessageDeliveryClient> channelCallerLookup = new HashMap<>(); 

     @Autowired 
     public void setBrokerConfiguration(BrokerConfiguration brokerConfiguration) { 
      this.brokerConfiguration = brokerConfiguration; 
     } 
    } 

die Karte 2 Elemente der ersten mit einem Schlüssel gleich den Wert in String enthalten sollte messageDeliveryChannelKey und die zweite mit einem Schlüssel gleich dem Wert in String otherDeliveryChannelKey. Die Schlüssel werden jedoch immer gleich dem Namen der @Beans-Methoden gesetzt, die in meine Partitur übernommen werden. Selbst wenn ich die Methodennamen in Unsinn ändere, entsprechen die Schlüssel der Karte diesem Wert.

Wie kann ich verhindern, dass dieses Verhalten von geschieht

+1

A 'Map ' von Spring interpretiert wird, wie Sie in alle Bohnen eines Typs injiziert wollen diese Karte. Der Schlüssel ist der Name der Bean. Also, wenn Sie die 'Map ' verwenden, erhalten Sie das. Dies ist das Standardverhalten und kann nicht deaktiviert werden. –

+0

Sie können diese Parameter jedoch mit der Annotation @Value in der Klasse SimpleCustomerMessageDeliveryBrokerImpl lesen. –

+0

@ FedericoJoséSorenson ja das ist, was ich vorher hatte. Aber ich habe versucht, das aus dieser Klasse zu extrahieren und ihm nur die Map zu geben, damit die Map im Wesentlichen wachsen kann, wie es nötig ist, und die Klasse müsste sich nicht jedes Mal ändern, wenn eine neue Sache hinzugefügt wird. –

Antwort

0

Dies wurde wegen Nichterfüllung Federverhalten auftreten. Um dies zu umgehen, habe ich einen Wrapper um die Return Map gelegt.

meine Bean zu diesem

@Bean 
public ChannelCallerLookup channelCallerLookup(MessageDeliveryClient messageDispatcherClient, MessageDeliveryClient otherPickerDeliveryClient) { 
    HashMap<String, MessageDeliveryClient> channelCallerLookup = new HashMap<>(); 
    channelCallerLookup.put(CHANNEL1_KEY, messageDispatcherClient); 
    channelCallerLookup.put(CHANNEL1_KEY2, otherPickerDeliveryClient); 
    ChannelCallerLookup callerLookup = new ChannelCallerLookup(channelCallerLookup); 
    return callerLookup; 
} 

Diese Wrapper-Klasse

Erstellt Changed
public class ChannelCallerLookup { 

    Map<String, MessageDeliveryClient> lookupMap; 

    public ChannelCallerLookup(Map<String, MessageDeliveryClient> lookupMap) { 
     this.lookupMap = lookupMap; 
    } 

    public Map<String, MessageDeliveryClient> getLookupMap() { 
     return lookupMap; 
    } 

    public MessageDeliveryClient get(String key){ 
     return lookupMap.get(key); 
    } 
} 
Verwandte Themen