You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Driesen Gert <Ge...@cegeka.be> on 2012/08/21 21:52:56 UTC
2.6.x: TlsClientParameters are reset on JAX-WS proxy
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.
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 ?
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" ?
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 cegeka.support@cegeka.be 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.
RE: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Posted by Driesen Gert <Ge...@cegeka.be>.
Sorry for the tabs in the patch, I didn't check your policy on tabs vs. spaces first.
My mistake.
________________________________________
From: Driesen Gert [Gert.Driesen@cegeka.be]
Sent: Thursday, August 23, 2012 9:52 PM
To: users@cxf.apache.org
Subject: RE: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Hey Dan,
You hit the spot: if you modify the WLSD to contain a HTTPS URL then everything works just fine.
Currently, our WSDLs contains a placeholder URL (eg. http://your-server-dns/Acquittal_V3).
I could change all our WSDLs, but I'd still consider it a bug. What do you think ?
You should be able to reproduce the issue with the wsdl_first_https example after applying the attached patch, and using the "secure-override-endpoint-address.client.non.spring" profile.
Yeah, naming isn't one my better skills :p
Let me know if you can reproduce the issue.
Gert
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: donderdag 23 augustus 2012 20:31
To: users@cxf.apache.org
Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
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 <Ge...@cegeka.be> 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}NisseAcq
> uittal.http-conduit' has been (re) configured for TLS keyManagers
> [com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl@ce9a4a]trustManage
> rs
> [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}requestAc
> quittal], params:
> [be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcquittal@cec
> 6c6]
>
> 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.RequestAcquittalRespo
> nse
> be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.NisseAcquittal.reques
> tAcquittal(be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcq
> uittal) throws
> be.fgov.rsvz_inasti.schemas.ws.helper.v3.SystemFault,be.fgov.rsvz_inas
> ti.schemas.ws.helper.v3.AuthorizationFault,be.fgov.rsvz_inasti.schemas
> .ws.helper.v3.AuthenticationFault,be.fgov.rsvz_inasti.schemas.ws.helpe
> r.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}NisseAcqu
> ittalService#{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$MessageSenderEndin
> gInterceptor.handleMessage(MessageSenderInterceptor.java:64)
>
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> rChain.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(NativeConstructo
> rAccessorImpl.java:39)
>
>
>
> Let me know if you need more information.
>
>
>
> Regards,
>
> Gert
>
>
>
>
>
> -----Original Message-----
> From: Driesen Gert [mailto:Gert.Driesen@cegeka.be]
> Sent: dinsdag 21 augustus 2012 22:25
> To: users@cxf.apache.org
> 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:dkulp@apache.org]<mailto:[mailto:dkulp@apache.org]>
>
> Sent: dinsdag 21 augustus 2012 22:05
>
> To: users@cxf.apache.org<ma...@cxf.apache.org>
>
> Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
>
>
>
>
>
> On Aug 21, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be>> 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 cegeka.support@cegeka.be<ma...@cegeka.be> 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
>
> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Passing Array's via formparam
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 09/09/12 04:40, Venu.Garimella@parc.com wrote:
>
> Hi,
>
> I am getting a length of 0 for an array passed using FormParam (via POST).
>
> Details :
>
> Javascript snippet (using jQuery):
>
> var searchList = ["abc", "def"];
> var req = $.post("/test/sendArray", { 'searchList[]' : searchList});
>
> Java snippet :
>
> Interface:
>
> @POST
> @Path("/")
> @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
> @Produces(MediaType.APPLICATION_JSON)
>
> public Response addList(@FormParam("searchTermsList") List<String>
> searchTermsList);
>
>
> Impl code:
>
> public Response addList(List<String> searchTermsList) {
>
> logger.log(Level.INFO, "Impl : addList : searchTermsList size =" +
> searchTermsList.size());
>
> Iterator<String> itr = searchTermsList.iterator();
> while(itr.hasNext()) {
> String element = itr.next();
> logger.log(Level.INFO, "Impl : addCollection : searchTermsList=" +
> element);
> }
>
> ResponseBuilder rb = Response.status(HttpURLConnection.HTTP_OK);
> rb.header("Status-Code", HttpURLConnection.HTTP_OK);
>
> return rb.build();
> }
>
>
>
>
>
>
> The searchTermsList prints out a size of 0, I was expecting 2.=
>
> Using cxf 2.5.2.
>
> Any ideas what I am doing wrong?
>
Can you please confirm that the actual payload looks like this:
searchTermsList=abc&searchTermsList=def
Thanks, Sergey
> Thanks
>
> Venu
>
Re: Passing Array's via formparam
Posted by Ve...@parc.com.
A mistake in my post.
The Javascript searchList[] should read searchTermsList, to match what's
in the REST interface.
Venu
On 9/8/12 8:40 PM, "Venu.Garimella@parc.com" <Ve...@parc.com>
wrote:
>
>Hi,
>
>I am getting a length of 0 for an array passed using FormParam (via POST).
>
>Details :
>
>Javascript snippet (using jQuery):
>
>var searchList = ["abc", "def"];
>var req = $.post("/test/sendArray", { 'searchList[]' : searchList});
>
>Java snippet :
>
>Interface:
>
>@POST
> @Path("/")
> @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
> @Produces(MediaType.APPLICATION_JSON)
>
>public Response addList(@FormParam("searchTermsList") List<String>
>searchTermsList);
>
>
>Impl code:
>
>public Response addList(List<String> searchTermsList) {
>
> logger.log(Level.INFO, "Impl : addList : searchTermsList size =" +
>searchTermsList.size());
>
> Iterator<String> itr = searchTermsList.iterator();
> while(itr.hasNext()) {
> String element = itr.next();
> logger.log(Level.INFO, "Impl : addCollection : searchTermsList=" +
>element);
> }
>
> ResponseBuilder rb = Response.status(HttpURLConnection.HTTP_OK);
> rb.header("Status-Code", HttpURLConnection.HTTP_OK);
>
> return rb.build();
>}
>
>
>
>
>
>
>The searchTermsList prints out a size of 0, I was expecting 2.
>
>Using cxf 2.5.2.
>
>Any ideas what I am doing wrong?
>
>Thanks
>
>Venu
>
Passing Array's via formparam
Posted by Ve...@parc.com.
Hi,
I am getting a length of 0 for an array passed using FormParam (via POST).
Details :
Javascript snippet (using jQuery):
var searchList = ["abc", "def"];
var req = $.post("/test/sendArray", { 'searchList[]' : searchList});
Java snippet :
Interface:
@POST
@Path("/")
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
@Produces(MediaType.APPLICATION_JSON)
public Response addList(@FormParam("searchTermsList") List<String>
searchTermsList);
Impl code:
public Response addList(List<String> searchTermsList) {
logger.log(Level.INFO, "Impl : addList : searchTermsList size =" +
searchTermsList.size());
Iterator<String> itr = searchTermsList.iterator();
while(itr.hasNext()) {
String element = itr.next();
logger.log(Level.INFO, "Impl : addCollection : searchTermsList=" +
element);
}
ResponseBuilder rb = Response.status(HttpURLConnection.HTTP_OK);
rb.header("Status-Code", HttpURLConnection.HTTP_OK);
return rb.build();
}
The searchTermsList prints out a size of 0, I was expecting 2.
Using cxf 2.5.2.
Any ideas what I am doing wrong?
Thanks
Venu
RE: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Posted by Driesen Gert <Ge...@cegeka.be>.
Hey Dan,
Can you comment on the email below ?
Thanks!
Gert
PS. Sorry if I'm impatient
________________________________________
From: Driesen Gert
Sent: Friday, August 24, 2012 1:52 PM
To: Daniel Kulp; users@cxf.apache.org
Subject: RE: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Hey Dan,
Thanks for your thorough response.
I did a test, and I can confirm that in CXF 2.6.x the following code works for overriding the endpoint address:
BindingProvider bp = (BindingProvider) webservicePort;
Map<String, Object> context = bp.getRequestContext();
context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpointAddress);
Client client = ClientProxy.getClient(webservicePort);
HTTPConduit http = (HTTPConduit) client.getConduit();
http.getTarget().getAddress().setValue(endpointAddress);
I'm still inclined to consider it a bug, as prior to CXF 2.6.x only the first three lines were necessary.
I'm sure you'll find quite a few references to that way of overriding the endpoint address.
Is it OK if I submit a bug for this. I'll also attach the patch for the wsdl first example to that bug.
If you decide that it's by design, then I can at least reference that bug in the "workaround" that I'll add to our code base.
In that case it may also be a good idea to add a FAQ entry for this.
Would it be an option to change the target of the conduit when ENDPOINT_ADDRESS_PROPERTY is set on the RequestContext ?
Regards,
Gert
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: donderdag 23 augustus 2012 22:40
To: users@cxf.apache.org; Driesen Gert
Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
On Aug 23, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be> wrote:
> Hey Dan,
>
> You hit the spot: if you modify the WLSD to contain a HTTPS URL then everything works just fine.
> Currently, our WSDLs contains a placeholder URL (eg. http://your-server-dns/Acquittal_V3).
> I could change all our WSDLs, but I'd still consider it a bug. What do you think ?
>
> You should be able to reproduce the issue with the wsdl_first_https example after applying the attached patch, and using the "secure-override-endpoint-address.client.non.spring" profile.
Patch didn't come through the Apache filters, but I did some quick mods and was able to reproduce.
Now, is it a bug or not… Kind of a toss up. Basically, a change was made to the ConduitSelector so that if the protocol changes from request to request, it will create a new Conduit that works with the new conduit. There are flags to also make it check the whole URL, not just the scheme part, but the default is to check just the scheme.
This allows a bunch of things that were much harder (or impossible) to do before:
1) Flip a client from something like local to http or jms just by setting the ENDPOINT_ADDRESS_PROPERTY. A new conduit will be created and setup that should work. With previous versions, it would try to use the old conduit and likely not work at all.
2) Reconfigure when flipping from http to https…. One of the reasons the change was made was EXACTLY for this use case believe it or not. If the conduit originally had an http url, but the user wants https, this would cause a new Conduit to be created and then go back into the configuration mechanism (spring/blueprint/osgi/whatever) to have it apply the https stuff. The new URL would be used to find the proper http:conduit settings and get them properly applied.
Thus, it's not really a bug, kind of the result of a new feature, but it may cause issues if not using configuration to specify the https settings.
However, there is another semi-easy workaround. When you configure the conduit for the tls stuff, also do:
httpConduit.getTarget().getAddress().setValue("https://localhost:9001/SoapContext/SoapPort");
that will reset the address of the conduit to the https version. Thus, it will be considered "compatible" with https URL's and then a new conduit won't be created.
Dan
> Yeah, naming isn't one my better skills :p
>
> Let me know if you can reproduce the issue.
>
> Gert
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: donderdag 23 augustus 2012 20:31
> To: users@cxf.apache.org
> Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
>
>
> 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 <Ge...@cegeka.be> 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}NisseAc
>> q uittal.http-conduit' has been (re) configured for TLS keyManagers
>> [com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl@ce9a4a]trustManag
>> e
>> rs
>> [com.sun.net.ssl.internal.ssl.X509TrustManagerImpl@ceb594]secureRando
>> m
>> 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}requestA
>> c
>> quittal], params:
>> [be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcquittal@ce
>> c
>> 6c6]
>>
>> 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.RequestAcquittalResp
>> o
>> nse
>> be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.NisseAcquittal.reque
>> s
>> tAcquittal(be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAc
>> q
>> uittal) throws
>> be.fgov.rsvz_inasti.schemas.ws.helper.v3.SystemFault,be.fgov.rsvz_ina
>> s
>> ti.schemas.ws.helper.v3.AuthorizationFault,be.fgov.rsvz_inasti.schema
>> s
>> .ws.helper.v3.AuthenticationFault,be.fgov.rsvz_inasti.schemas.ws.help
>> e
>> r.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:810
>> 1
>> /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}NisseAcq
>> u
>> ittalService#{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquitta
>> l /V3}requestAcquittal has thrown exception, unwinding now
>>
>> org.apache.cxf.interceptor.Fault: Could not send Message.
>>
>> at
>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndi
>> n
>> gInterceptor.handleMessage(MessageSenderInterceptor.java:64)
>>
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>> o
>> rChain.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:13
>> 4
>> )
>>
>> 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(NativeConstruct
>> o
>> rAccessorImpl.java:39)
>>
>>
>>
>> Let me know if you need more information.
>>
>>
>>
>> Regards,
>>
>> Gert
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Driesen Gert [mailto:Gert.Driesen@cegeka.be]
>> Sent: dinsdag 21 augustus 2012 22:25
>> To: users@cxf.apache.org
>> 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:dkulp@apache.org]<mailto:[mailto:dkulp@apache.org]>
>>
>> Sent: dinsdag 21 augustus 2012 22:05
>>
>> To: users@cxf.apache.org<ma...@cxf.apache.org>
>>
>> Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
>>
>>
>>
>>
>>
>> On Aug 21, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be>> 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 cegeka.support@cegeka.be<ma...@cegeka.be> 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
>>
>> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
RE: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Posted by Driesen Gert <Ge...@cegeka.be>.
Hey Dan,
Thanks for your thorough response.
I did a test, and I can confirm that in CXF 2.6.x the following code works for overriding the endpoint address:
BindingProvider bp = (BindingProvider) webservicePort;
Map<String, Object> context = bp.getRequestContext();
context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpointAddress);
Client client = ClientProxy.getClient(webservicePort);
HTTPConduit http = (HTTPConduit) client.getConduit();
http.getTarget().getAddress().setValue(endpointAddress);
I'm still inclined to consider it a bug, as prior to CXF 2.6.x only the first three lines were necessary.
I'm sure you'll find quite a few references to that way of overriding the endpoint address.
Is it OK if I submit a bug for this. I'll also attach the patch for the wsdl first example to that bug.
If you decide that it's by design, then I can at least reference that bug in the "workaround" that I'll add to our code base.
In that case it may also be a good idea to add a FAQ entry for this.
Would it be an option to change the target of the conduit when ENDPOINT_ADDRESS_PROPERTY is set on the RequestContext ?
Regards,
Gert
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: donderdag 23 augustus 2012 22:40
To: users@cxf.apache.org; Driesen Gert
Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
On Aug 23, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be> wrote:
> Hey Dan,
>
> You hit the spot: if you modify the WLSD to contain a HTTPS URL then everything works just fine.
> Currently, our WSDLs contains a placeholder URL (eg. http://your-server-dns/Acquittal_V3).
> I could change all our WSDLs, but I'd still consider it a bug. What do you think ?
>
> You should be able to reproduce the issue with the wsdl_first_https example after applying the attached patch, and using the "secure-override-endpoint-address.client.non.spring" profile.
Patch didn't come through the Apache filters, but I did some quick mods and was able to reproduce.
Now, is it a bug or not... Kind of a toss up. Basically, a change was made to the ConduitSelector so that if the protocol changes from request to request, it will create a new Conduit that works with the new conduit. There are flags to also make it check the whole URL, not just the scheme part, but the default is to check just the scheme.
This allows a bunch of things that were much harder (or impossible) to do before:
1) Flip a client from something like local to http or jms just by setting the ENDPOINT_ADDRESS_PROPERTY. A new conduit will be created and setup that should work. With previous versions, it would try to use the old conduit and likely not work at all.
2) Reconfigure when flipping from http to https.... One of the reasons the change was made was EXACTLY for this use case believe it or not. If the conduit originally had an http url, but the user wants https, this would cause a new Conduit to be created and then go back into the configuration mechanism (spring/blueprint/osgi/whatever) to have it apply the https stuff. The new URL would be used to find the proper http:conduit settings and get them properly applied.
Thus, it's not really a bug, kind of the result of a new feature, but it may cause issues if not using configuration to specify the https settings.
However, there is another semi-easy workaround. When you configure the conduit for the tls stuff, also do:
httpConduit.getTarget().getAddress().setValue("https://localhost:9001/SoapContext/SoapPort");
that will reset the address of the conduit to the https version. Thus, it will be considered "compatible" with https URL's and then a new conduit won't be created.
Dan
> Yeah, naming isn't one my better skills :p
>
> Let me know if you can reproduce the issue.
>
> Gert
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: donderdag 23 augustus 2012 20:31
> To: users@cxf.apache.org
> Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
>
>
> 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 <Ge...@cegeka.be> 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}NisseAc
>> q uittal.http-conduit' has been (re) configured for TLS keyManagers
>> [com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl@ce9a4a]trustManag
>> e
>> rs
>> [com.sun.net.ssl.internal.ssl.X509TrustManagerImpl@ceb594]secureRando
>> m
>> 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}requestA
>> c
>> quittal], params:
>> [be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcquittal@ce
>> c
>> 6c6]
>>
>> 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.RequestAcquittalResp
>> o
>> nse
>> be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.NisseAcquittal.reque
>> s
>> tAcquittal(be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAc
>> q
>> uittal) throws
>> be.fgov.rsvz_inasti.schemas.ws.helper.v3.SystemFault,be.fgov.rsvz_ina
>> s
>> ti.schemas.ws.helper.v3.AuthorizationFault,be.fgov.rsvz_inasti.schema
>> s
>> .ws.helper.v3.AuthenticationFault,be.fgov.rsvz_inasti.schemas.ws.help
>> e
>> r.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:810
>> 1
>> /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}NisseAcq
>> u
>> ittalService#{http://www.rsvz-inasti.fgov.be/schemas/WS/NisseAcquitta
>> l /V3}requestAcquittal has thrown exception, unwinding now
>>
>> org.apache.cxf.interceptor.Fault: Could not send Message.
>>
>> at
>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndi
>> n
>> gInterceptor.handleMessage(MessageSenderInterceptor.java:64)
>>
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>> o
>> rChain.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:13
>> 4
>> )
>>
>> 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(NativeConstruct
>> o
>> rAccessorImpl.java:39)
>>
>>
>>
>> Let me know if you need more information.
>>
>>
>>
>> Regards,
>>
>> Gert
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Driesen Gert [mailto:Gert.Driesen@cegeka.be]
>> Sent: dinsdag 21 augustus 2012 22:25
>> To: users@cxf.apache.org
>> 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:dkulp@apache.org]<mailto:[mailto:dkulp@apache.org]>
>>
>> Sent: dinsdag 21 augustus 2012 22:05
>>
>> To: users@cxf.apache.org<ma...@cxf.apache.org>
>>
>> Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
>>
>>
>>
>>
>>
>> On Aug 21, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be>> 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 cegeka.support@cegeka.be<ma...@cegeka.be> 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
>>
>> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Posted by Daniel Kulp <dk...@apache.org>.
On Aug 23, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be> wrote:
> Hey Dan,
>
> You hit the spot: if you modify the WLSD to contain a HTTPS URL then everything works just fine.
> Currently, our WSDLs contains a placeholder URL (eg. http://your-server-dns/Acquittal_V3).
> I could change all our WSDLs, but I'd still consider it a bug. What do you think ?
>
> You should be able to reproduce the issue with the wsdl_first_https example after applying the attached patch, and using the "secure-override-endpoint-address.client.non.spring" profile.
Patch didn't come through the Apache filters, but I did some quick mods and was able to reproduce.
Now, is it a bug or not… Kind of a toss up. Basically, a change was made to the ConduitSelector so that if the protocol changes from request to request, it will create a new Conduit that works with the new conduit. There are flags to also make it check the whole URL, not just the scheme part, but the default is to check just the scheme.
This allows a bunch of things that were much harder (or impossible) to do before:
1) Flip a client from something like local to http or jms just by setting the ENDPOINT_ADDRESS_PROPERTY. A new conduit will be created and setup that should work. With previous versions, it would try to use the old conduit and likely not work at all.
2) Reconfigure when flipping from http to https…. One of the reasons the change was made was EXACTLY for this use case believe it or not. If the conduit originally had an http url, but the user wants https, this would cause a new Conduit to be created and then go back into the configuration mechanism (spring/blueprint/osgi/whatever) to have it apply the https stuff. The new URL would be used to find the proper http:conduit settings and get them properly applied.
Thus, it's not really a bug, kind of the result of a new feature, but it may cause issues if not using configuration to specify the https settings.
However, there is another semi-easy workaround. When you configure the conduit for the tls stuff, also do:
httpConduit.getTarget().getAddress().setValue("https://localhost:9001/SoapContext/SoapPort");
that will reset the address of the conduit to the https version. Thus, it will be considered "compatible" with https URL's and then a new conduit won't be created.
Dan
> Yeah, naming isn't one my better skills :p
>
> Let me know if you can reproduce the issue.
>
> Gert
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: donderdag 23 augustus 2012 20:31
> To: users@cxf.apache.org
> Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
>
>
> 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 <Ge...@cegeka.be> 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}NisseAcq
>> uittal.http-conduit' has been (re) configured for TLS keyManagers
>> [com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl@ce9a4a]trustManage
>> rs
>> [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}requestAc
>> quittal], params:
>> [be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcquittal@cec
>> 6c6]
>>
>> 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.RequestAcquittalRespo
>> nse
>> be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.NisseAcquittal.reques
>> tAcquittal(be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcq
>> uittal) throws
>> be.fgov.rsvz_inasti.schemas.ws.helper.v3.SystemFault,be.fgov.rsvz_inas
>> ti.schemas.ws.helper.v3.AuthorizationFault,be.fgov.rsvz_inasti.schemas
>> .ws.helper.v3.AuthenticationFault,be.fgov.rsvz_inasti.schemas.ws.helpe
>> r.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}NisseAcqu
>> ittalService#{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$MessageSenderEndin
>> gInterceptor.handleMessage(MessageSenderInterceptor.java:64)
>>
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>> rChain.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(NativeConstructo
>> rAccessorImpl.java:39)
>>
>>
>>
>> Let me know if you need more information.
>>
>>
>>
>> Regards,
>>
>> Gert
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Driesen Gert [mailto:Gert.Driesen@cegeka.be]
>> Sent: dinsdag 21 augustus 2012 22:25
>> To: users@cxf.apache.org
>> 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:dkulp@apache.org]<mailto:[mailto:dkulp@apache.org]>
>>
>> Sent: dinsdag 21 augustus 2012 22:05
>>
>> To: users@cxf.apache.org<ma...@cxf.apache.org>
>>
>> Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
>>
>>
>>
>>
>>
>> On Aug 21, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be>> 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 cegeka.support@cegeka.be<ma...@cegeka.be> 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
>>
>> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
RE: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Posted by Driesen Gert <Ge...@cegeka.be>.
Hey Dan,
You hit the spot: if you modify the WLSD to contain a HTTPS URL then everything works just fine.
Currently, our WSDLs contains a placeholder URL (eg. http://your-server-dns/Acquittal_V3).
I could change all our WSDLs, but I'd still consider it a bug. What do you think ?
You should be able to reproduce the issue with the wsdl_first_https example after applying the attached patch, and using the "secure-override-endpoint-address.client.non.spring" profile.
Yeah, naming isn't one my better skills :p
Let me know if you can reproduce the issue.
Gert
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: donderdag 23 augustus 2012 20:31
To: users@cxf.apache.org
Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
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 <Ge...@cegeka.be> 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}NisseAcq
> uittal.http-conduit' has been (re) configured for TLS keyManagers
> [com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl@ce9a4a]trustManage
> rs
> [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}requestAc
> quittal], params:
> [be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcquittal@cec
> 6c6]
>
> 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.RequestAcquittalRespo
> nse
> be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.NisseAcquittal.reques
> tAcquittal(be.fgov.rsvz_inasti.schemas.ws.nisseacquittal.v3.RequestAcq
> uittal) throws
> be.fgov.rsvz_inasti.schemas.ws.helper.v3.SystemFault,be.fgov.rsvz_inas
> ti.schemas.ws.helper.v3.AuthorizationFault,be.fgov.rsvz_inasti.schemas
> .ws.helper.v3.AuthenticationFault,be.fgov.rsvz_inasti.schemas.ws.helpe
> r.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}NisseAcqu
> ittalService#{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$MessageSenderEndin
> gInterceptor.handleMessage(MessageSenderInterceptor.java:64)
>
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> rChain.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(NativeConstructo
> rAccessorImpl.java:39)
>
>
>
> Let me know if you need more information.
>
>
>
> Regards,
>
> Gert
>
>
>
>
>
> -----Original Message-----
> From: Driesen Gert [mailto:Gert.Driesen@cegeka.be]
> Sent: dinsdag 21 augustus 2012 22:25
> To: users@cxf.apache.org
> 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:dkulp@apache.org]<mailto:[mailto:dkulp@apache.org]>
>
> Sent: dinsdag 21 augustus 2012 22:05
>
> To: users@cxf.apache.org<ma...@cxf.apache.org>
>
> Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
>
>
>
>
>
> On Aug 21, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be>> 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 cegeka.support@cegeka.be<ma...@cegeka.be> 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
>
> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Posted by Daniel Kulp <dk...@apache.org>.
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 <Ge...@cegeka.be> 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:Gert.Driesen@cegeka.be]
> Sent: dinsdag 21 augustus 2012 22:25
> To: users@cxf.apache.org
> 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:dkulp@apache.org]<mailto:[mailto:dkulp@apache.org]>
>
> Sent: dinsdag 21 augustus 2012 22:05
>
> To: users@cxf.apache.org<ma...@cxf.apache.org>
>
> Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
>
>
>
>
>
> On Aug 21, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be>> 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 cegeka.support@cegeka.be<ma...@cegeka.be> 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
>
> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
>
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
RE: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Posted by Driesen Gert <Ge...@cegeka.be>.
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:Gert.Driesen@cegeka.be]
Sent: dinsdag 21 augustus 2012 22:25
To: users@cxf.apache.org
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:dkulp@apache.org]<mailto:[mailto:dkulp@apache.org]>
Sent: dinsdag 21 augustus 2012 22:05
To: users@cxf.apache.org<ma...@cxf.apache.org>
Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
On Aug 21, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be>> 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 cegeka.support@cegeka.be<ma...@cegeka.be> 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
dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
RE: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Posted by Driesen Gert <Ge...@cegeka.be>.
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:dkulp@apache.org]
Sent: dinsdag 21 augustus 2012 22:05
To: users@cxf.apache.org
Subject: Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
On Aug 21, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be> 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 cegeka.support@cegeka.be 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
dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: 2.6.x: TlsClientParameters are reset on JAX-WS proxy
Posted by Daniel Kulp <dk...@apache.org>.
On Aug 21, 2012, at 3:52 PM, Driesen Gert <Ge...@cegeka.be> 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 cegeka.support@cegeka.be 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com