Использование microprofile-config-api: WELD-001408: Неудовлетворенные зависимости для типа String с квалификаторами @ConfigProperty - PullRequest
Новая
       87

Использование microprofile-config-api: WELD-001408: Неудовлетворенные зависимости для типа String с квалификаторами @ConfigProperty

0 голосов
/ 28 августа 2018

Я играю с функцией mpConfig-1.2, но, похоже, она не работает в моей настройке.

Использование Liberty 18.0.0.2.

Добавлена ​​зависимость maven для microprofile-config-api, CDI работает нормально, но при запуске @ConfigProperty происходит сбой с сообщением 

[ERROR   ] CWWKZ0106E: Could not start web application demo-service-ear {1.0-SNAPSHOT}.
[ERROR   ] CWWKZ0004E: An exception occurred while starting the application demo-service-ear {1.0-SNAPSHOT}. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @ConfigProperty
  at injection point [BackedAnnotatedField] @Inject @ConfigProperty private no.klp.bpm.task.KOPSTask.endpoint2
  at no.klp.bpm.task.KOPSTask.endpoint2(KOPSTask.java:0)

Аннотация такая: 

@Inject
@ConfigProperty(name="rule.engine.host", defaultValue="ukjent!")
private String endpoint2;

Что здесь может быть неправильного?

/ BWA

1 Ответ

0 голосов
/ 26 февраля 2019

Справочная информация:

Это проблема видимости загрузчика классов, которая в основном возникает, когда старые конфигурации (например, до 2017 года) переносятся в приложения, использующие MicroProfile. В Liberty API были классифицированы по следующим категориям:

  • api (например, API JavaSE)
  • spec (например, API JavaEE)
  • ibm-api (например, com.ibm.websphere.* API)
  • third-party (например, org.eclipse.persistence.* API из функции JPA 2.1)

По умолчанию api,spec,ibm-api видны приложениям, а это означает, что third-party - нет (поскольку сторонние библиотеки могут нарушать изменения, которые нарушают политику нулевой миграции Liberty).

Затем, когда появились функции MicroProfile, они не вписывались ни в одну из вышеуказанных категорий API (не достаточно универсально, чтобы считаться spec, но более стабильными, чем third-party), поэтому мы создали новый API Тип видимости:

  • stable (например, org.eclipse.microprofile.* API)

Новый тип API stable теперь включен по умолчанию, поэтому приложения могут видеть эти API.

Объяснение вопроса:

Поскольку ваш apiTypeVisibility был жестко запрограммирован в spec, ibm-api, api, third-party, это фактически исключало новый тип API stable, под которым были классифицированы API MicroProfile. Чтобы решить эту проблему, вы можете указать: 

<classloader apiTypeVisibility="spec, stable, ibm-api, api, third-party"/>

Это довольно многословно, и все, что вы действительно пытаетесь сделать, - это сделать видимыми third-party API, в дополнение к тому, что вы получаете по умолчанию. По этой причине с 18.0.0.3 теперь вы можете использовать синтаксис "chmod style" для предоставления или отмены отдельных типов API со знаками + или -. Например, приведенная выше конфигурация <classloader> эквивалентна: 

<!-- Read as: In addition to default values, also grant 'third-party' api type visibility -->
<classloader apiTypeVisibility="+third-party"/>

Дополнительные ресурсы:

...