Вы можете определить exampleMapping - второе определение находится в отдельном файле, и вы используете <import resource="..."/> для импорта одного файла в другой, но это хрупкий подход, который легко сломать.
Я предлагаю более надежную стратегию. Замените exampleMapping классом Registry, который, в свою очередь, содержит и управляет отображениями:
public MappingRegistry<K,V> {
private final Map<K,V> mappings = new HashMap<K,V>();
public void addMapping(K key, V value) {
mappings.put(key, value);
}
public Map<K,V> getMappings() {
return Collections.unmodifiableMap(mappings);
}
}
Затем напишите класс, который регистрирует сопоставление с реестром:
public class MappingRegistrar<K,V> {
private final MappingRegistry<K,V> registry;
private K key;
private V value;
@Autowired
public MappingRegistrar(MappingRegistry<K,V> registry) {
this.registry = registry;
}
public void setKey(K key) {
this.key = key;
}
public void setValue(V value) {
this.value = value;
}
@PostConstruct
public void registerMapping() {
registry.addMapping(key, value);
}
}
Ваш конфиг становится примерно таким:
<bean id="mappingRegistry" class="com.xyz.MappingRegistry"/>
<bean id="mappingA" class="com.xyz.MappingRegistrar" p:key="keyA" p:value="valueA"/>
<bean id="mappingB" class="com.xyz.MappingRegistrar" p:key="keyB" p:value="valueB"/>
<bean id="mappingC" class="com.xyz.MappingRegistrar" p:key="keyC" p:value="valueC"/>
Эти сопоставления теперь могут быть разбросаны по всей конфигурации любым удобным для вас способом, и они будут собираться самостоятельно. ExampleServcie затем вводится с помощью MappingRegistry и соответственно извлекает сопоставления.
Это немного больше работы, чем у вас уже есть, но гораздо более гибко и менее подвержено ошибкам. Это особенно ценно, если вы пытаетесь создать какую-то расширяемую структуру; Вы хотите наложить меньше ограничений на то, как люди его используют.