Using microprofile-config-api: WELD-001408: Unsatisfied dependencies for type String with qualifiers @ConfigProperty

Question

I playing with the mpConfig-1.2 feature, but it seems to not work in my setup.

Using Liberty 18.0.0.2.

Have added the maven dependency for microprofile-config-api, CDI is working fine, but the @ConfigProperty is failing at startup with the message

[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)

The annotation is like this:

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

What can be possible wrong here ?

/bwa

looks like you have not added the dependency properly. can you post your pom.xml or gradle or ivy file? — sofarsoghood, Sep 07 '18 at 09:41
Well, the dependency IS correkt, but for some reason this fixed the problem in the enterpriseApplication config in the server.xml: to ..... So, for some unknown reason apiTypeVisibility="spec, ibm-api, api, third-party" kills the mpConfig — bwa, Sep 11 '18 at 05:42
have you tried enabling the feature in the server.xml with mpConfig-1.2? — sofarsoghood, Sep 11 '18 at 11:42

score 1 · Answer 1 · answered Feb 25 '19 at 21:28

Background info:

This is a classloader visibility problem, which will mainly exist when older configurations (e.g. pre-2017) are carried forward to apps that make use of MicroProfile. In Liberty, APIs were classified into the following categories:

api (e.g. JavaSE APIs)
spec (e.g. JavaEE APIs)
ibm-api (e.g. com.ibm.websphere.* APIs)
third-party (e.g. org.eclipse.persistence.* APIs from the JPA 2.1 feature)

By default, api,spec,ibm-api are visible to applications, meaning third-party is not (because third party libs may may breaking changes, which would violate Liberty's zero migration policy).

Then, when MicroProfile features came along, they didn't fit into any of the above API categories (not universally standard enough to be considered spec, but more stable than third-party), so we made a new API type visibility:

stable (e.g. org.eclipse.microprofile.* APIs)

The new stable API type was now enabled by default, so applications could see those APIs.

Explanation of issue:

Since you had your apiTypeVisibility hard-coded to spec, ibm-api, api, third-party, this actually excluded the new stable API type, which MicroProfile APIs were categorized under. To fix this issue, you could specify:

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

This is pretty verbose though, and all you are really trying to do is enable third-party APIs to be visible, in addition to whatever you get by default. For this reason, as of 18.0.0.3 you can now use "chmod style" syntax to grant or revoke the individual API types with + or - signs. For example, the above <classloader> config is equivalent to:

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

Additional resources:

Great info, even that, it's hard to know the difference of the api — bwa, Feb 27 '19 at 08:11

Using microprofile-config-api: WELD-001408: Unsatisfied dependencies for type String with qualifiers @ConfigProperty

1 Answers1

Background info:

Explanation of issue:

Additional resources: