Support LoggingFeature and Headers

[quarkiverse]

Support LoggingFeature and Headers

[dufoli]

@bnazare
for point 1 I have already fix it on my current work to move build time config to runtime.
So I have cherry picked the commits to master
for point 2 & 3, I have to analyzed it. Anyway, I prefer to succeed to move build time config to runtime.
cf #61 because it change many many things.

[dufoli]

hmmm.
About header, I think you can add it by injecting client.

@Inject
MyWebService service;

// and in init function of bean do:
        AuthSoapHeader authHeader = new AuthSoapHeader();
	authHeader.setStrUserName(username);
	authHeader.setStrPassword(password);
	Header soapHdr = new Header(AUTH_HEADER_NAME, authHeader, new JAXBDataBinding(AuthSoapHeader.class));
	ClientProxy.getClient(service).getRequestContext().put(Header.HEADER_LIST, List.of(soapHdr));

Indeed we have many functions missing in client:
http://cxf.apache.org/docs/jax-ws-configuration.html

setFeatures
setInInterceptors
setInFaultInterceptors
setOutInterceptors
setOutFaultInterceptors
setHandlers
setLoadHandlers

setClientFactoryBean - quarkus one is used so not planned.
setWsdlLocation
setConduitSelector
setTransportId
setServiceFactory
setBus - custom bus. not sure if usefull
setProperties
setDataBinding - jaxbdatabinding is default
setBindingConfig
2 solution:

• implement a system for all
• implement an handler system to customize JaxWsProxyFactoryBean

design idea:

[dufoli]

• add in config element with list of class to load by reflection for :
  setFeatures
  setInInterceptors
  setInFaultInterceptors
  setOutInterceptors
  setOutFaultInterceptors
  setHandlers
  setLoadHandlers

• add customize handler method that is called inside client producer and add it to config or with a dedicated annotation. => it mean that we enable handlers but no granularity to declare one or remove one... but it add that we give full access to it so it can been fully customized.

• add a injection point for it in producer classes and use annotation: issue it make it only available at buildtime not runtime...=> wrong idea.

[dufoli]

@jimbogithub can you test with annotation:
https://cxf.apache.org/docs/interceptors.html
basicly :

@org.apache.cxf.feature.Features (features = {"org.apache.cxf.feature.LoggingFeature"})
@WebService
public class MyWebService

[dufoli]

I have added config for that.
1 solutions currently:

• annotation
• add config
  quarkus.cxf.endpoint."/greeting".features=org.apache.cxf.feature.LoggingFeature
  quarkus.cxf.endpoint."/greeting".in-interceptors=com.example.MyInterceptor
  quarkus.cxf.endpoint."/greeting".out-interceptors=com.example.MyInterceptor
  quarkus.cxf.endpoint."/greeting".in-fault-interceptors=com.example.MyInterceptor
  quarkus.cxf.endpoint."/greeting".out-fault-interceptors=com.example.MyInterceptor

[bnazare]

hmmm.
About header, I think you can add it by injecting client.

@Inject
MyWebService service;

// and in init function of bean do:
        AuthSoapHeader authHeader = new AuthSoapHeader();
	authHeader.setStrUserName(username);
	authHeader.setStrPassword(password);
	Header soapHdr = new Header(AUTH_HEADER_NAME, authHeader, new JAXBDataBinding(AuthSoapHeader.class));
	ClientProxy.getClient(service).getRequestContext().put(Header.HEADER_LIST, List.of(soapHdr));

hi @dufoli

I'm not really trying to use this approach but I feel like I should warn you that calls to ClientProxy.getClient(service) with injected services never work. Or at least, they never have in my environment. Instead, I always get this exception:

java.lang.IllegalArgumentException: not a proxy instance
	at java.base/java.lang.reflect.Proxy.getInvocationHandler(Proxy.java:1103)
	at org.apache.cxf.frontend.ClientProxy.getClient(ClientProxy.java:127)

The reasoning here, I believe, is that at this point service is actually a CDI/Arc proxy and not a CXF-created proxy like the method expects.
At some point I actually had a variation of this working but it required a reflective call to arc_contextualInstance() soooo ... quite the hack.

[bnazare]

I have added config for that.
1 solutions currently:

* annotation

* add config
  quarkus.cxf.endpoint."/greeting".features=org.apache.cxf.feature.LoggingFeature
  quarkus.cxf.endpoint."/greeting".in-interceptors=com.example.MyInterceptor
  quarkus.cxf.endpoint."/greeting".out-interceptors=com.example.MyInterceptor
  quarkus.cxf.endpoint."/greeting".in-fault-interceptors=com.example.MyInterceptor
  quarkus.cxf.endpoint."/greeting".out-fault-interceptors=com.example.MyInterceptor

You might want to re-open this issue as I think I found at least 3 bugs in the configuration-based approach.

1. Only the "features" config is being checked for its presence and if present the code attempts to use all the other configs which causes an exception if one of those is empty (see here).
2. The lists of features and interceptors never reach CXFClientInfo which in turn means that CxfClientProducer can only see empty lists and thus no feature or interceptor is applied.
3. Even after fixing 2., if the feature/interceptor is not available as an injectable bean an exception will be raised instead of a new instance being created. This is because the call to CDI.current().select(cls).get() (here) throws an UnsatisfiedResolutionException instead of returning null as the code seems to expect.

[bnazare]

@dufoli
I confirm point 1 was fixed as you said and #61 fixed point 2 afterwards. This leaves point 3 as the only sticking point. If you're not refactoring that particular piece of code then it is a fairly trivial fix. You can either:

• Add UnsatisfiedResolutionException to the catch block and ignore the exception
• Check the result of isResolvable() before you call get() on the CDI instance