заполнитель свойства в конфигурации мула разрешается из одного файла, но не из другого

Я столкнулся со странной проблемой. У меня есть файл конфигурации мула. В нем нет ничего действительно захватывающего, и он отлично работает. По крайней мере, это сработало...

Проблемы начались, когда я начал помещать параметры конфигурации в несколько файлов свойств. Если я определяю свойство в одном файле, оно разрешается, но ничего из другого файла.

Отсутствие сообщения об ошибке указывает на то, что чтение файла не удалось или что-то еще...

Мои сцены говорят мне, что это как-то связано с тем, что файлы конфигурации читаются org.mule.config.spring.SpringXmlConfigurationBuilder...

У кого-нибудь была похожая проблема? или кто-нибудь знает, что, черт возьми, происходит?


spring configuration mule
person uthomas    schedule 17.06.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я не уверен, как вы настраиваете заполнитель своего контекста, но если вы используете несколько свойств, вы должны объявить список местоположений, разделенных запятыми, как показано ниже:

<context:property-placeholder
         location="classpath:my-mule-app.properties,
                   classpath:my-mule-app-override.properties" />

Если вам нужна дополнительная информация, вы можете найти ее в официальная страница документации по теме

person genjosanzo    schedule 20.06.2012

arrow_upward
0
arrow_downward

Спасибо, парни.

Итак, загадочная проблема решена. В моем интеграционном тесте мне нужна была запущенная пара серверов hornetq/mule. Для теста я хотел внедрить все возможные объекты из обычной XML-конфигурации Spring. Поэтому я определил свой bean-компонент MuleServer в XML-файле конфигурации spring и использовал конструктор, который принимает файлы конфигурации мула в виде массива String. То, о чем я не знал (или не думал), что класс MuleServer создает свой собственный контекст приложения...

Итак, в моем тестовом контексте приложения я создал экземпляр объекта, который создает свой собственный контекст приложения...

Поскольку заполнители свойств являются своего рода специальными bean-компонентами и должны быть инициализированы перед всеми другими bean-компонентами, это вызвало странное поведение, описанное выше.

Решение заключалось в том, что я создал экземпляр MuleServer с новым ключевым словом, как в старые времена, в моем методе setUp тестов.

Это сработало для меня.

person uthomas    schedule 12.07.2012