Получить путь к файлу конфигурации, в котором объект настроен в Spring.NET

#c# #spring.net

Вопрос:

Я хотел бы настроить объект в Spring.СЕТЬ, которая способна считывать дополнительные файлы конфигурации. Эти файлы должны быть расположены относительно источника.Файл конфигурации СЕТИ (или app.config, если Spring.Там лежит NET config).

Итак, что мне нужно, так это способ выяснить, из какого файла конфигурации взято определение объекта для моего объекта. Или если нет файла конфигурации (поскольку он был настроен программно).

Если для этого нет универсального решения (боюсь, что его нет …), также подойдет решение, специально предназначенное для XmlApplicationContext.

То, что я пробовал до сих пор, заключалось в извлечении из IApplicationContextAware, а затем приведении контекста приложения к XmlApplicationContext. Это содержит свойство ConfigurationLocations. Но это не работает, поскольку ConfigurationLocations

защищен, поэтому недоступен
это массив файлов, поэтому, если существует более одного файла, я не знаю, из какого из них происходит мой объект
специфично для XmlApplicationContext (как сказано: нормально, но не оптимально)
Я уверен, что это не сработает, если config находится внутри app.config.

Есть ли какое-либо решение моей проблемы?

1. Не могли бы вы объяснить, почему вам нужно было бы прочитать эти файлы конфигурации? Возможно, есть альтернативное решение.

2. Я могу думать только о взломах… Я бы поместил имена файлов в конфигурацию DI вашего внешнего объекта, это самое чистое решение, ИМО.

Ответ №1:

Я могу подтвердить, что нет способа сопоставить ObjectDefinition конкретного объекта, определенного для контекста, с конкретным «источником» этого ObjectDefinition после его регистрации.

Дизайн базового ObjectFactory для контекста специально таков, что ему не нужно знать / заботиться о том, откуда возникли метаданные ObjectDefinition, но объединить все метаданные вместе при инициализации ObjectFactory.

В любом случае я бы остерегался «отслеживания» пути к файлам конфигурации, поскольку, хотя это может сработать для вашего конкретного варианта использования, это вряд ли будет хорошим решением общего назначения для проблемы, поскольку это важный принцип Spring.Конструкция СЕТЕВОГО файла конфигурации такова, что один файл конфигурации может «импортировать» один или несколько других файлов конфигурации, которые, в свою очередь, могут импортировать один или несколько других и т.д. И поэтому знание полного пути только к одному из этих взаимозависимых файлов конфигурации не будет (обязательно) иметь ничего общего с путем к фактическому файлу конфигурации, который содержит метаданные для конкретного объекта, который вы ищете.

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