Как изменить бобы, определенные в пружинном контейнере
Новый Пережиток профилирование направляющих предложений включая свободный 'Облегченный' версия.
4 ответа
Вы можете использовать BeanFactoryPostProcessor , чтобы изменить метаданные bean-компонента до Spring контейнер создает экземпляр bean-компонента CodeBase. Например:
public class CodebaseOverrider implements BeanFactoryPostProcessor {
private List<String> sourceCodeLocations;
public void postProcessBeanFactory(
ConfigurableListableBeanFactory beanFactory) throws BeansException {
CodeBase codebase = (CodeBase)beanFactory.getBean("codebase");
if (sourceCodeLocations != null)
{
codebase.setSourceCodeLocations(sourceCodeLocations);
}
}
public void setSourceCodeLocations(List<String> sourceCodeLocations) {
this.sourceCodeLocations = sourceCodeLocations;
}
}
Затем в contextSpecial.xml:
<beans>
<import resource="context1.xml" />
<bean class="com.example.CodebaseOverrider">
<property name="sourceCodeLocations">
<list>
<value>src/handmade/productive</value>
<value>src/generated/productive</value>
</list>
</property>
</bean>
</beans>
Да. Определение компонента может иметь "родительский" атрибут, который ссылается на определение родительского компонента. Новый «ребенок» определение наследует большинство свойств родителя, и любое из этих свойств может быть переопределено.
См. Наследование определения объекта
Также вы можете использовать Объединение коллекций для объединения определения свойства списка из определения родительского и дочернего компонентов. Таким образом, вы можете указать некоторые элементы списка в определении родительского компонента и добавить к нему дополнительные элементы в определении дочернего компонента.
Есть ли способ заранее определить список в свойствах или другой конфигурации?
Похоже, что конфигурация приложения и проводка тесно связаны. По моему опыту, если что-то сделать весной сложно, вероятно, есть другой более простой способ сделать это.
3 подхода:
Простой: имейте два списка defaultSourceCodeLocations и additionalSourceCodeLocations и пусть ваши методы доступа проверят оба из них (или объединят их). Я видел это в некоторых фреймворках - список обработчиков по умолчанию заполняется, затем добавляются дополнительные созданные пользователем ...
Более сложный, но сохраняет исходный класс чистым: затем вы можете создать класс CodeBaseModifier. У этого будет метод инициализации для изменения внедренного экземпляра компонента.
<список> источник / ручной работы / продуктивный
Если вы хотите сделать это действительно универсальным, вы можете создать модификатор bean-компонента, который будет делать это путем отражения. Будьте осторожны с порядком, если используете этот подход. Зависимые bean-компоненты CodeBase должны были бы убедиться, что этот класс был создан первым (в зависимости от)
3 Вариант 2 ... Вместо прямого создания класса CodeBase вместо этого создайте фабрику, которая возвращает заполненный bean-компонент. Затем эту фабрику можно настроить с помощью Spring аналогично 2. Имейте defaultSourceCodeLocations и additionalSourceCodeLocations
Если вам не нужно много расширяемых свойств, я бы выбрал вариант 1.