quarkus.cxf.client.ServiceName.handlers = eu.code.handler.ServiceNameHandler doesn't inject @ConfigProperty

[Owlz]

We can't seem to make inject @ConfigProperty into an handler created with the property.

How to reproduce:

application.properties

ServiceName.clientIdentifier=MyClientIdentifier

quarkus.cxf.codegen.wsdl2java.ServiceName.includes=wsdl/ServiceName.wsdl
quarkus.cxf.codegen.wsdl2java.ServiceName.additional-params=-wsdlLocation,src/main/resources/wsdl/ServiceName.wsdl,-suppress-generated-date
quarkus.cxf.client.ServiceName.client-endpoint-url = https://webserver.com/ServiceName
quarkus.cxf.client.ServiceName.service-interface = com.code.ServiceName
quarkus.cxf.client.ServiceName.handlers = eu.code.ServiceName

ServiceName.java

package eu.code;
[...]
public class ServiceName implements SOAPHandler<SOAPMessageContext> {
    private static final Logger LOG = [...];

    @ConfigProperty(name = "ServiceName.clientIdentifier")
    String clientIdentifier;

    public boolean handleMessage(SOAPMessageContext soapMessageContext) {
        LOG.info("handling message with clientIdentifier=" + clientIdentifier);
    }

    [...]
}

This will always log "handling message with clientIdentifier=null". Is this an issue or am I missing something?

I could not find a suitable example in the integration-test folder

[ppalaga]

It looks like ServiceName is not a bean present in the CDI container and thus Quarkus CXF creates it reflectively using the default constructor.

The solution is simple: add @ApplicationScoped or similar annotation to ServiceName. That will make the CDI container create the bean and inject the config property.

[Owlz]

Than you for the pointer, i missed that completely.

With the @ApplicationScoped annotation there is a new warning in the logs:

2024-03-05 17:22:50,098 WARN  [io.qua.arc.impl] (executor-thread-1) 
================================================================================
CDI: programmatic lookup problem detected
-----------------------------------------
At least one bean matched the required type and qualifiers but was marked as unused and removed during build

Stack frame: io.quarkiverse.cxf.CxfClientProducer.addToCols(CxfClientProducer.java:150)
Required type: class eu.code.ServiceName
Required qualifiers: [@javax.enterprise.inject.Default()]
Removed beans:
    - CLASS bean  [types=[class eu.code.ServiceName, null<javax.xml.ws.handler.soap.SOAPMessageContext>], qualifiers=null]
Solutions:
    - Application developers can eliminate false positives via the @Unremovable annotation
    - Extensions can eliminate false positives via build items, e.g. using the UnremovableBeanBuildItem
    - See also https://quarkus.io/guides/cdi-reference#remove_unused_beans
    - Enable the DEBUG log level to see the full stack trace
================================================================================

Adding @Unremovable actually fixes the issue and makes the @ConfigProperty work properly.

Is it normal that Quarkus tries to remove the Handler?

[ppalaga]

Is it normal that Quarkus tries to remove the Handler?

Yeah, it removes beans it thinks are unused. The Quarkus CXF configuration parameters that support bean references are mostly changeable at runtime and therefore Quarkus CXF cannot instruct Quarkus at build time not to remove them. So yes, @Unremovable is the proper situation for this kind of situation.

[ppalaga]

Hm... when thinking of it again, we actually have a solution in place for interceptors. It consists in listing all beans that implement org.apache.cxf.interceptor.Interceptor and making those as unremovable programmatically. ~I guess we could/should do~ We have the same in place for all beans implementing jakarta.xml.ws.handler.Handler. I wonder why it does not work. Let me try to reproduce it.

[ppalaga]

This PR shows that @Unremovable is not required for handlers https://github.com/quarkiverse/quarkus-cxf/pull/1277/files

Also, as expected, Quarkus starts complaining about the programmatic access, when this line is removed

https://github.com/quarkiverse/quarkus-cxf/blob/aaac506abdb8c498bb1ed5281bd8137abc78ee85/extensions/core/deployment/src/main/java/io/quarkiverse/cxf/deployment/QuarkusCxfProcessor.java#L630

I wonder what you do differently.

[Owlz]

Could it be that I'm on an older version of the extension?

Currently using the 1.5.14.redhat-00010

[ppalaga]

Ah, of course! That one is really old.