Injection of SOAP client without using CXFClient

[amoscatelli]

Hi everybody,
Thank you for your work !

All I want to know is :
Can I inject an instance of the SEI without using the io.quarkiverse.cxf.annotation.CXFClient annotation ?
I would like not to use quarkus/quarkiverse specific API to use standard JAX-WS api ...

Please let me know,
Thank you in advance.

[ppalaga]

Can I inject an instance of the SEI without using the io.quarkiverse.cxf.annotation.CXFClient annotation?

No, it is currently not possible, unless you implement a bean @Producer that creates (via jakarta.xml.ws.Service.create(URL, QName)) and configures the client. It should work at least in JVM mode.

[amoscatelli]

and I suppose native support also is out of question.

Why did you say "currently" ?
Is this something planned ?

Thank you in advance

[ppalaga]

Is this something planned?

Not really, but I am open to discuss the idea. The main problem to solve would be the configuration. The current @CXFClient style adheres to some rules which config set in application.properties belongs to which client. We would have to find some replacement for the config key passed via @CXFClient("key"). Maybe the injected field name could be used as a key. Not sure the additional rules would be easy to document/learn/use. What do others think?

[amoscatelli]

I think the field name could be used as key AND you could use jakarta.inject.Named to override the key value ...

    @Inject 
    CalculatorService myCalculator;

will use myCalculator as key :

quarkus.cxf.client.myCalculator.wsdl=${cxf.it.calculator.baseUri}/calculator-ws/CalculatorService?wsdl
quarkus.cxf.client.myCalculator.client-endpoint-url=${cxf.it.calculator.baseUri}/calculator-ws/CalculatorService
quarkus.cxf.client.myCalculator.service-interface=org.jboss.eap.quickstarts.wscalculator.calculator.CalculatorService

and

    @Inject 
    @Named("test")
    CalculatorService myCalculator;

will use test as key :

quarkus.cxf.client.test.wsdl=${cxf.it.calculator.baseUri}/calculator-ws/CalculatorService?wsdl
quarkus.cxf.client.test.client-endpoint-url=${cxf.it.calculator.baseUri}/calculator-ws/CalculatorService
quarkus.cxf.client.test.service-interface=org.jboss.eap.quickstarts.wscalculator.calculator.CalculatorService

[ppalaga]

I was curious, how other Quarkus extensions having named config sets solve the bean mapping problem. I found Argoal and Caffeine which both have their own annotations to set the key: @DataSource and @CacheName respectively. See here and here. Argoal supports injecting the default nameless datasource via plain @Inject. So I'd say having @CXFClient is in line with conventions present elsewhere in Quarkus. Pure @Inject at least for the non-ambiguous cases sounds interesting though. I'd vote for not introducing the mapping by field name or @Named. If the case is ambiguous, the extension should throw an exception (ideally at build time) advising the user to use @CXFClient. Contributions are welcome!

[amoscatelli]

I can/want to contribute on this.
But I want to work on a generic/robust/abstract solution.

If you want to use JPA you can use the official annotation PersistenceUnit to switch between multiple configurations :
https://quarkus.io/guides/hibernate-orm

So you are not forced to use Argoal specific annotation.

If you want I can make a contribution when there is an extra/optional boolean config to enable/support the Named annotation alongside the CXFClient.

So enabling this configuration you will able to inject both this :

    @Inject 
    @CXFClient("test")
    CalculatorService myCalculator;

and this :

    @Inject 
    @Named("test")
    CalculatorService myCalculator;

I think this is an elegant solution, Named is a standard CDI qualifier used in situations like this.

[amoscatelli]

I give up.
I was working on a contribution but I discovered Named annotation values must be globally unique among every bean, even with different types.
I was not aware of this so my idea loses appeal since the probability to have collisions increases.

Nevermind, probably to make this clean, more support on spec side is required (maybe a combination of jakarta ws and jakarta config).
Anyway for now that's all.

[ppalaga]

Thanks for trying this @amoscatelli!

I created a follow up issue for the non-ambiguous cases #961