CODEWITHSUNDEEP
websphere-libertyopen-libertymicroprofile
bwa
bwa

Reputation: 81

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

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

Upvotes: 4

Views: 2514

Answers (1)

Andy Guibert
Andy Guibert

Reputation: 42936

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:

Upvotes: 2

Related Questions