Hello,
I've been able to reproduce the issue using a very basic Java app, in which I
only create a JAX-WS port and invoke an operation.
You can find part of the trace output below:
FINE: registering incoming observer: org.apache.cxf.endpoint.ClientImpl@ca44b8
22-aug-2012 13:43:24 org.apache.cxf.transport.http.HTTPConduit
setTlsClientParameters
FINE: Conduit
'{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquittal/V3}NisseAcquittal.http-conduit'
has been (re) configured for TLS keyManagers
[com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl@ce9a4a]trustManagers
[com.sun.net.ssl.internal.ssl.X509TrustManagerImpl@ceb594]secureRandom null
22-aug-2012 13:43:24 org.apache.cxf.endpoint.ClientImpl doInvoke
FINE: Invoke, operation info: [BindingOperationInfo:
{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquittal/V3}requestAcquittal],
params:
[be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcquittal@cec6c6]
22-aug-2012 13:43:24 org.apache.cxf.endpoint.ClientImpl setContext
FINE: set requestContext to message be{java.lang.reflect.Method=public abstract
be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcquittalResponse
be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.NisseAcquittal.requestAcquittal(be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcquittal)
throws
be.fgov.rsvz_inasti.schemas.ws.helper.v3.SystemFault,be.fgov.rsvz_inasti.schemas.ws.helper.v3.AuthorizationFault,be.fgov.rsvz_inasti.schemas.ws.helper.v3.AuthenticationFault,be.fgov.rsvz_inasti.schemas.ws.helper.v3.ValidationFault,
org.apache.cxf.jaxws.context.WrappedMessageContext.SCOPES={org.apache.cxf.message.Message.ENDPOINT_ADDRESS=APPLICATION},
org.apache.cxf.message.Message.ENDPOINT_ADDRESS=https://localhost:8101/NisseAcquittal_V3}
22-aug-2012 13:43:24 org.apache.cxf.endpoint.ClientImpl setupInterceptorChain
FINE: Interceptors contributed by bus:
[org.apache.cxf.ws.policy.PolicyOutInterceptor@de9603]
22-aug-2012 13:43:24 org.apache.cxf.endpoint.ClientImpl setupInterceptorChain
FINE: Interceptors contributed by client: []
....
22-aug-2012 13:43:24 org.apache.cxf.endpoint.ClientImpl setupInterceptorChain
22-aug-2012 13:43:24 org.apache.cxf.phase.PhaseInterceptorChain add
FINE: Adding interceptor
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor@c9bf4d to phase write
22-aug-2012 13:43:24 org.apache.cxf.transport.http.HTTPConduit
setTlsClientParameters
FINE: Conduit
'{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquittal/V3}NisseAcquittal.http-conduit'
has been (re)configured for plain http.
22-aug-2012 13:43:24 org.apache.cxf.transport.http.HTTPConduit logConfig
FINE: No Trust Decider configured for Conduit
'{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquittal/V3}NisseAcquittal.http-conduit'
22-aug-2012 13:43:24 org.apache.cxf.transport.http.HTTPConduit logConfig
FINE: No Auth Supplier configured for Conduit
'{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquittal/V3}NisseAcquittal.http-conduit'
22-aug-2012 13:43:24 org.apache.cxf.transport.http.HTTPConduit logConfig
FINE: Conduit
'{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquittal/V3}NisseAcquittal.http-conduit'
has been configured for plain http.
22-aug-2012 13:43:24 org.apache.cxf.transport.AbstractObservable
setMessageObserver
...
WARNING: Interceptor for
{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquittal/V3}NisseAcquittalService#{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquittal/V3}requestAcquittal
has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:464)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:367)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:320)
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:91)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
at $Proxy33.requestAcquittal(Unknown Source)
at be.cegeka.rsvz.acquittal.gateway.Tester.main(Tester.java:43)
Caused by: javax.net.ssl.SSLHandshakeException: SSLHandshakeException invoking
https://localhost:8101/NisseAcquittal_V3:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
Let me know if you need more information.
Regards,
Gert
-----Original Message-----
From: Driesen Gert [mailto:[email protected]]
Sent: dinsdag 21 augustus 2012 22:25
To: [email protected]
Subject: RE: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Hey Daniel,
Sorry for not responding inline, but I have this beautiful email client that
does not automatically prefix/indent the message you're replying too :( I've
sent the log file to you directly, but let me know if I should send it to the
list again (and how I can bypass the apache filters).
Perhaps the fact that I'm using the CXFServlet - instead of the
CXFNoSpringServlet - is causing the problem.
I'm using a JAX-WS proxy to invoke a SOAP operation on a remote ESB, which in
turn invokes a SOAP operation on a CXF SOAP endpoint (which in fact is a mock).
This is done as part of a test suite for the ESB implementation.
Perhaps by (mistakenly) using the "spring" CXFServlet, CXF is also attempting
to apply spring configuration to the JAX-WS proxy.
I'll verify this tomorrow.
Regards,
Gert
-----Original Message-----
From: Daniel Kulp [mailto:[email protected]]<mailto:[mailto:[email protected]]>
Sent: dinsdag 21 augustus 2012 22:05
To: [email protected]<mailto:[email protected]>
Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
On Aug 21, 2012, at 3:52 PM, Driesen Gert
<[email protected]<mailto:[email protected]>> wrote:
> Hello,
>
> In CXF 2.5.4, I'm successfully configuring a JAX-WS proxy to use a specific
> keymanager and trustmanager.
> When I do exactly the same on CXF 2.6.x (2.6.1 and 2.6.2), then the
> TlsClientParameters appear to get reset when I invoke an operation on the
> proxy.
>
> I've attached a file that shows the log output (at level FINE) between the
> creation of the JAX-WS proxy, and the (failed) invocation of an operation on
> that proxy.
> I've "annotated" the log file to show where the creation of the proxy starts
> and ends, and where I think that the TlsClientParameters are getting reset.
Log didn't' make it through the apache filters... :-(
> When you search for ">>> END CREATE PORT", then the line just above shows
> that I configured the HTTP conduit for TLS.
> If you then search for ">>> TlsClientParameters are reconfigured for plain
> HTTP ??", the line below shows that setTlsClientParameters is invoked again.
> Note that I'm NOT using spring at all.
> What am I missing here ?
>
> On a side note (let me know if this deserves a separate thread):
> Has spring(-web) always been a required dependency to use a CXFServlet ?
Well, no, but it should have been. In 2.5.x, cxf-rt-transport-http had a
transitive dependency on spring-web. Thus, even if you didn't depend on it,
maven would bring it in automatically. With 2.6, we made sure all the spring
deps are marked optional and likely provided as well. Thus, they are no longer
pulled in by Maven transitively and if you are using Spring, you really need to
make sure you depend on it.
> I had to explicitly add it as a maven dependency to get 2.6.x working, if not
> I get a NoClassDefFoundError when the default ctor of CXFServlet is invoked.
> I checked the source code, and it indeed uses spring.
> If it now IS a required dependency, then why is that dependency marked
> "optional" in the POM for cxf-rt-transports-http ? And while I'm at it, why
> is that dependency (like many others) marked "provided" ?
Specifically because spring is optional. You can use the CXFNoSpringServlet
or many other use cases without spring. Marking it optional allows the
maven-bundle-plugin to properly mark the OSGi imports as optional as well.
Basically, Spring IS optional with CXF.
Dan
>
> Thanks!
> Gert
>
> This e-mail and all files transmitted as attachment(s) thereto are
> confidential and solely intended for the individual to whom or the
> organization to which they are addressed. If you received this e-mail by
> mistake, please notify Cegeka's Service Desk at
> [email protected]<mailto:[email protected]> or call +32 (0)11
> 240 363. We thank you in advance. Cegeka hereby confirms that this message
> has been swept by Sophos for the presence of viruses.
--
Daniel Kulp
[email protected]<mailto:[email protected]> - http://dankulp.com/blog Talend
Community Coder - http://coders.talend.com
