Any chance you could attach the very basic app to a JIRA or maybe try and reproduce with our wsdl_first_https example?
The flipping back and forth thing kind of bothers me. I'm not really sure what would cause that. I'm kind of wondering if the WSDL has a non-https URL in the soap:address but you are then overriding that with an https URL. That MIGHT do it, I'm not really sure. Definitely a strange log. Dan On Aug 22, 2012, at 7:48 AM, Driesen Gert <[email protected]> wrote: > 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 > > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
