получить доступ к общему файлу свойств внутри пакета с osgi

У меня есть приложение osgi (в felix) с несколькими пакетами. В одном пакете есть несколько общих файлов свойств, а остальным пакетам нужно просто использовать их.

Мы используем maven и spring osgi, файлы свойств находятся в таких ресурсах, как:

<path to bundle>/src/main/resources/
    common.properties
    engine.properties
    ...

Maven обычно создает их внутри jar-пакета, поэтому они должны быть в пути к классам приложения, но Spring не имеет к ним доступа, это терпит неудачу:

<context:property-placeholder location="classpath:common.properties" />

(пробовал classpath*: и другие комбинации)

Я прочитал это и это

Действительно ли это какая-то глобальная проблема с идеологией osgi и отсутствием стандартного способа заставить ее работать? Только хаки и обходные пути, такие как это или <osgix:cmProperties...>?

Это беспокоит, потому что это делает развертывание более сложным и подверженным ошибкам: вы не можете развертывать файлы свойств внутри jar-файлов только с помощью mvn deploy, как в обычном приложении, — вам придется вручную копировать их в рабочую коробку при каждом выпуске.


java spring properties-file classpath osgi
person yetanothercoder    schedule 17.05.2012    source источник

Ответы (4)


arrow_upward
5
arrow_downward

В OSGi нет универсального пути к классам приложений. Хотя свойства находятся в пути к классам пакета, который их содержит, они не обязательно находятся в пути к классам пакетов, которые их используют.

Это немного некрасиво, но в целом экспорт «пакета», содержащего папки свойств, сделает их доступными. В данном случае это выглядит как «.», что очень некрасиво, но вы можете поместить их в каталог «свойства» (скажем), а затем экспортировать пакет свойств. Пакеты, использующие эти свойства, также должны импортировать пакет свойств.

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

person Holly Cummins    schedule 18.05.2012
comment
но вы можете поместить их в каталог "properties" (скажем), а затем экспортировать пакет свойств... - спасибо, не слышал о таком способе, хотя экспортировать папку prop как пакет java , кажется очередной хак) - person yetanothercoder; 18.05.2012
comment
Я согласен, это похоже на взлом. :) Один из способов думать об этом состоит в том, что модульность означает, что банки не должны копаться во внутренностях других банок без объявления явной зависимости. Экспорт пакетов хорошо работает для классов и немного неуклюж для свойств, и, возможно, урок состоит в том, что существуют более чистые методы для общей конфигурации, чем файлы общих свойств; либо предоставьте службу конфигурации, и ею можно будет поделиться более чистым способом, либо используйте Configuration Admin. Входной барьер для любого из них, конечно, выше, чем для простого старого файла свойств. - person Holly Cummins; 18.05.2012
comment
Я вижу, да, osgi поднимает вас на один корпоративный уровень, чтобы избежать работы с простыми файлами свойств =) либо выставляйте службу конфигурации и можете делиться ею более чистым способом, либо используйте Configuration Admin. Входной барьер для любого из них выше.. - я боюсь, что не только входной барьер, но вы также получите накладные расходы на производительность, когда будете ссылаться на значения свойств через какую-либо службу конфигурации из другого пакета, Я имею в виду незначительную часть накладных расходов на сериализацию/проксирование/отражение. - person yetanothercoder; 18.05.2012
comment
Я отмечаю это как ответ, потому что это кажется более разумным обходным путем, но лично я предпочитаю другое: размещение общих реквизитов в файловой системе и ссылка на Spring как файл:./path/to/common-props. - person yetanothercoder; 21.05.2012

arrow_upward
2
arrow_downward

Лучший способ прочитать общие свойства во всех пакетах — использовать сервис компендиума, который предоставляется Spring DM.

person Damoder    schedule 13.12.2012

arrow_upward
0
arrow_downward

Я обнаружил, что редко бывает случай, когда файл свойств должен быть «общим». Разве вы не можете разбить содержимое файла свойств и поместить его в пакеты, которые на самом деле требуют его. Свойства должны быть сгруппированы по контексту и помещены в пакет, который требует этого контекста.

Теоретически аналогично отказу от использования класса констант или интерфейса, который считается анти-шаблоном.

person Robin    schedule 18.05.2012
comment
рассмотреть несколько пакетов с доступом к одной и той же базе данных - вам придется жестко задавать одни и те же свойства базы данных в каждом пакете? - person yetanothercoder; 19.05.2012
comment
В этом конкретном случае использование пакета сохраняемости и JPA, вероятно, будет чище и проще. - person Holly Cummins; 20.05.2012
comment
Если вам нужна общая база данных, то лучше всего настроить источник данных и опубликовать его как службу OSGi. Тогда ваши пользовательские пакеты могут просто ссылаться на службу и не должны знать о свойствах БД. См.: liquid-reality.de/x/LYBk - person Christian Schneider; 21.05.2012

arrow_upward
0
arrow_downward

Другая альтернатива, которую я, наконец, использовал, - это размещение файлов свойств в файловой системе и просто ссылка на них из Spring (или другого кода) как file:path/to/common.props.

person yetanothercoder    schedule 21.05.2012