В поле @Reference добавлены сервисы osgi, которые в случайном порядке выводятся на ноль.

Question

У нас есть приложение osgi приличного размера, которое состоит примерно из 80 пользовательских пакетов услуг с дополнительными 20-30 сторонними зависимостями пакетов во время выполнения (мы запускаем R7-версию osgi).Когда мы начинали этот проект, мы обычно использовали внедрение наших служб с аннотацией @Reference и вообще не имели проблем, но теперь мы все больше и больше видим, что эти внедренные зависимости иногда случайным образом оказываются нулевыми - один из способовнашли, чтобы решить проблему, чтобы заменить полевую инъекцию методом инъекции услуг.

Что я заметил, так это то, что там, где внедренные сервисы обычно приходят в ноль, находится в наших компонентных сервисах, которые фактически являются просто Java-классами с наложенной аннотацией @Component, но не реализуют «ProviderType»"или" ConsumerType "интерфейс (наши конечные точки REST такие).В настоящее время мы уже устанавливаем для свойства этого компонента значение «немедленный = истина», но это, похоже, не влияет на случайным образом добавленные внедренные службы.

Когда мы проверяем список пакетов - все правильные пакеты кажутся активными, а иногда даже службы кажутся хорошими (НЕТ неудовлетворенных ссылок), что совершенно ошеломляет.

Любой, кто может иметь некоторое представление о том, почему это происходит?

Некоторые текущие отклонения / возможные причины: С начала проекта мы увидели следующую ошибку почти со всеми нашими RESTконечные точки, но не знаю точно, почему фреймворк считает, что видит дублирующие классы и методы.И

полностью.qualified.class.path.CustomServiceRest # doStuff и полностью.qualified.class.path.CustomeServiceRest # doStuff являются равными кандидатами для обработки текущего запроса, что может привести к непредсказуемым результатам 13 декабря 2018 г. 2:41:45 вечера org.apache.cxf.jaxrs.model.OperationResourceInfoComparator сравнивать ПРЕДУПРЕЖДЕНИЕ: Оба полностью.qualified.class.path.CustomServiceRest # doSomeOtherStuff и полностью.qualified.class.path.CustomServiceRest # doSomeOtherStuff для текущего запроса равнычто может привести к непредсказуемым результатам

Недавно мы добавили службу osgi WebSocket, которая потребовала добавления еще одного пакета зависимостей Jetty, и возникла некоторая обеспокоенность по поводу того, чтобы два пакета Jetty хорошо воспроизводились в миксе времени выполнения.

Answer 1

После долгой борьбы с этой проблемой, что было найдено - каждый из наших пакетов RestEndpoint содержал класс JaxRsApp, который расширяет javax.ws.rs.core.Application, и мы добавляли каждый из наших статических классов RestEndpoint в набор Set> внутриоднако метод overridden getClasses (), каждый из наших классов RestEntpoints аннотирован @Component, а каждому @Component присвоено свойство service, соответствующее этому соответствующему имени класса endoints, и поэтому мы считаем, что каждый классрегистрируется дважды (один раз JaxRsApp и один раз SCR с нотацией @Component), следовательно, дублирующее предупреждающее сообщение всякий раз, когда мы ударяем по любой из точек restenment с помощью теста Postman или пользовательский интерфейс делает вызов rest.

Кроме того, благодаря удалению статических регистраций из файла JaxRsApp (так что теперь мы только регистрируем компоненты точки восстановления с помощью SCR), предупреждение не только исчезло, но и была устранена проблема с нулевым обслуживанием.Таким образом, мы считаем, что до изменения SCR фактически внедрял сервисы зависимостей, но каким-то образом с «дублированными» конечными точками сервисов сервисы зависимостей внедрялись в зарегистрированные классы обслуживания JaxRsApp?Я не уверен на 100%, поэтому, если кто-то здесь сможет это объяснить, будет очень признателен.

В любом случае это работает сейчас.