Использование API поиска вне платформы NetBeans - PullRequest
Новая
       9

Использование API поиска вне платформы NetBeans

2 голосов
/ 31 мая 2011

Я пытаюсь оценить, подходит ли для нашего магазина использование API поиска NetBeans без всей платформы NetBeans.

Пока мне удалось создать проект с таким кодом: 

 for (SomeInterface si : Lookup.getDefault().lookupAll(SomeInterface.class)) {
     si.doSomething();
 }

Я также создал несколько других проектов, каждый с классом AnImplementation, реализующим SomeInterface, и сопровождающий файл META-INF / services / path.to.SomeInterface, содержащий строку, ссылающуюся на класс (например, «other.path.to»). .AnImplementation ").

Когда я добавляю эти проекты реализации в библиотеки (зависимости) основного проекта в IDE NetBeans, он работает нормально, и я вижу последовательные результаты doSomething () из обеих реализаций.

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

Если я не ошибаюсь, это поведение, описанное в документации по Lookup API. Заранее спасибо.

Редактировать : На данный момент я пришел к выводу, что без платформы NetBeans (или OSGi?) Невозможно определить, какие поставщики услуг присутствуют во время запуска. Вам нужно ссылаться на их фляги в вашем classpath и, таким образом, идентифицировать их перед запуском. Не стесняйтесь доказать, что я неправ.

Ответы [ 2 ]

4 голосов
/ 31 мая 2011

Вы должны ссылаться на подпроект в вызывающем приложении, так как это помещает его в путь к классам - если jar / library не находится на пути к классам, то API, такие как Lookup и ServiceLoader, не смогут его найти.

Если вы используете OSGI или платформу NetBeans, эти системы позволяют изменять путь к классам во время выполнения.

Блог Geertjans содержит запись именно об этом (используя API поиска вне платформы NetBeans), в своем блоге он также ссылается на блог Джона О'Коннорса , который противопоставляет ServiceLoader и API поиска

EDIT

Я только что видел ответ Джона Скитса на подобный вопрос . Вы можете использовать свойство -Djava.ext.dirs=lib, чтобы установить папку (в данном случае 'libs') как место, где она должна искать jar для вашего classpath.

1 голос
/ 31 мая 2011

В моем понимании вам не нужно связывать все модули вместе с основным проектом, чтобы это работало. Все, что вам нужно, это убедиться, что ваши модули находятся на пути к классам при запуске приложения, потому что глобальный Lookup использует механизм ServiceLoader под капотом. Исходя из вашего вопроса, я рекомендую подумать, если

  • использование ServiceLoader напрямую лучше для вашей проблемы или
  • некоторые DI Framework, такие как Guice стоит попробовать или
  • если OSGI предлагает что-то полезное для вас и используйте это.

Не поймите меня неправильно, я очень люблю NetBeans и платформу NetBeans, но, по моему мнению, использование только Lookup имеет ограниченное применение из-за возможностей, перечисленных выше.

...