Why wsdl2java generated code use CXF dependencies

I use Apache CXF 3.0.4 wsdl2java to generate code from this wsdl with following command:

./wsdl2java -client -exsh true -d weather -p weather -verbose url

As far as I know wsdl2java generates pure java code using only JAX-WS. Generated code works fine without any additional library/dependency. I've grepped it to find any CXF classes, but it seems to be free from CXF. The problem flows out when I add specific CXF dependency to my pom.xml. This dependency is:

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-frontend-jaxws</artifactId>
    <version>3.1.0</version>
</dependency>

After adding this, application seems to use different implementation of JAX-WS( is it even possible?).

Generated code contains among other things WeatherSoap interface. One of it's methods is getWeatherInformation()

@WebService(targetNamespace = "http://ws.cdyne.com/WeatherWS/", name = "WeatherSoap")
@XmlSeeAlso({ObjectFactory.class})
public interface WeatherSoap {

    /**
     * Gets Information for each WeatherID
     */
    @WebResult(name = "GetWeatherInformationResult", targetNamespace = "http://ws.cdyne.com/WeatherWS/")
    @RequestWrapper(localName = "GetWeatherInformation", targetNamespace = "http://ws.cdyne.com/WeatherWS/", className = "weather.GetWeatherInformation")
    @WebMethod(operationName = "GetWeatherInformation", action = "http://ws.cdyne.com/WeatherWS/GetWeatherInformation")
    @ResponseWrapper(localName = "GetWeatherInformationResponse", targetNamespace = "http://ws.cdyne.com/WeatherWS/", className = "weather.GetWeatherInformationResponse")
    public weather.ArrayOfWeatherDescription getWeatherInformation();

...

}

Without cxf-rt-frontend-jaxws dependency

Step into getWeatherInformation() while debugging leads to GetWeatherInformation( another generated class.
Step into GetWeatherInformation leads to com.oracle.webservices.internal.api.message.BasePropertySet
...
Result from SOAP webservice received.

With cxf-rt-frontend-jaxws dependency

Step into getWeatherInformation while debugging leads to org.apache.cxf.jaxws.JaxWsClientProxy (why?)
...
Exception is thrown:

Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Could not find conduit initiator for address: http://wsf.cdyne.com/WeatherWS/Weather.asmx and transport: http://schemas.xmlsoap.org/soap/http
    at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:161)
    at com.sun.proxy.$Proxy33.getWeatherInformation(Unknown Source)
    at weather.WeatherSoap_WeatherSoap_Client.main(WeatherSoap_WeatherSoap_Client.java:49)
Caused by: java.lang.RuntimeException: Could not find conduit initiator for address: http://wsf.cdyne.com/WeatherWS/Weather.asmx and transport: http://schemas.xmlsoap.org/soap/http
    at org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:224)
    at org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:229)
    at org.apache.cxf.endpoint.AbstractConduitSelector.createConduit(AbstractConduitSelector.java:145)
    at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:107)
    at org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduitSelector.java:63)
    at org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl.java:853)
    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:511)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
    at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
    at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
    ... 2 more

I know that there is workaround for this exception which is mentioned here and it works. But not for my work application. It throws NPE after all:

Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: java.lang.NullPointerException
    ...
Caused by: org.apache.cxf.binding.soap.SoapFault: java.lang.NullPointerException
    at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:86)
    at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:52)
    at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:41)
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
    at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113)
    at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
    at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
    at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:802)
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1642)
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1533)
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1336)
    at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
    at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:652)
    at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
    at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
    at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
    ... 7 more

Question time

Why Apache-CXF is used even when application works fine without it?
Is it possible to force application to stop using Apache-CXF in this case?

I don't need this dependencies for client( since it works fine without them). I just want to produce SOAP as well. And thats why I need this dependencies. The only solution which I see is to split application into separate consumer and producer.

application seems to use different implementation of JAX-WS( is it even possible?).

Yes. CXF have it's own jax-ws provider and it's jar contains a service file declaring it. (when the JVM needs a jax-ws provider: it looks on the classpath to see if there is a non-default provider declared... and if any use it).

Why ? That's the Java specs : http://docs.oracle.com/javaee/5/api/javax/xml/ws/spi/Provider.html#provider()

Is it possible to force application to stop using Apache-CXF in this case?

Yes. Create the appropriate resource file on your classpath to redirect to the default implementation.

In details : the file must be here : META-INF/services/javax.xml.ws.spi.Provider (if you use maven: put it simply here : /src/main/resources/META-INF/services/javax.xml.ws.spi.Provider)

And it must contains one single line :