Ah. OK. No <soap:address location=""/> thing in the WSDL. Most likely, if you update the wsdl to just have something like:
<soap:address location="https://localhost:8080"/> or something (even if nothing is there), it would work. The ENDPOITN_ADDRESS_PROPERTY would just override that at runtime. That said, fix should be in last nights snapshots. Would be great if you could test that. Dan On Wednesday, January 04, 2012 10:49:06 AM Johan Karlberg wrote: > Hi, > > The port object is a thin adapter (only providing default values for a > number of overly verbose operations exposed on the generated port) on top > of a port type generated by wsdl2java, if you need the WSDL (around 8k > lines) or generated client (around 500 files, at about 2MB worth of > generated source that I thankfully do not have to poke in) it could be > arranged, but I suspect it is not relevant. > > The code requested is as follows: > > final URL wsdlURL = ClassLoader.getSystemResource("services.wsdl"); > > final ExchangeWebService exchangeWebService = new > ExchangeWebService(wsdlURL, new QName( > "http://schemas.microsoft.com/exchange/services/2006/messages";, > "ExchangeWebService")); > > final ExchangeServicePortType port = > exchangeWebService.getExchangeWebPort(); > > /* > setting these namespaces on the soap envelope > prevents them from being added separately to each new soap header. > */ > final ImmutableMap topLevelNamespaces = ImmutableMap > .of("m", > "http://schemas.microsoft.com/exchange/services/2006/messages";, "t", > "http://schemas.microsoft.com/exchange/services/2006/types";); > > The ExchangeServicePortType and ExchangeWebService are part of the generated > client, and contain no magic or alterations on my part. > > The BindingProvider.ENDPOINT_ADDRESS_PROPERTY is the only point at which my > client provides an endpoint address to CXF. The WSDL for the service (the > service type specifically, there is as previously mentioned a plethora of > operations, messages and types defined) Is as barren as: > > <wsdl:service name="ExchangeWebService"> > <wsdl:port name="ExchangeWebPort" > binding="tns:ExchangeServiceBinding"> </wsdl:port> > </wsdl:service> > > The WSDL needs to be loaded from a local source as it needs significant > modification from what Microsoft exports (on Exchange server 2007 SP1 in > this particular case) in order for CXF to produce a working client. > > The URL once deployed will likely end up looking something like > "jar:file:/C:/installdir/product/lib/module.jar!/services.wsdl", which the > JRE will have no problem with but perhaps CXF does. > > // Johan Karlberg > > > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: den 3 januari 2012 23:00 > To: [email protected] > Cc: Johan Karlberg > Subject: Re: Regression in 2.5.1? > > > It should definitely go into JIRA. I can see the problem and have a fix > for it. However, can I also see the code you are using to create your > "port" object? I'm kind of surprised to see it's letting that be created > without a URL of some sort. > > Dan > > On Tuesday, January 03, 2012 11:55:09 AM Johan Karlberg wrote: > > I was forced to revert back to 2.5.0 after encountering the following: > > (partial stacktrace) > > > > < local code stacktrace removed > > > Caused by: java.lang.NullPointerException > > > > at > > > > org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransp > > ortFa > > ctory.java:203) at > > org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransp > > ortFa > > ctory.java:236) at > > org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(Abs > > tract > > ConduitSelector.java:88) at > > org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontCo > > nduit > > Selector.java:71) at > > org.apache.cxf.endpoint.ClientImpl.getConduit(ClientImpl.java:842) > > <local code stacktrace removed> > > > > At fault seems to be the dereferencing of a null AttributedURIType, > > which previously was a String, at the very top of > > SoapTransportFactory.java's getConduit override. > > > > The calling pattern that triggered it is as follows: > > > > > > ((BindingProvider)port).getRequestContext().put("soap.env.ns.map", > > topLevelNamespaces); > > ((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOI > > NT_AD > > DRESS_PROPERTY, endpoint); > > > > // chunking interferes with NTLM > > final HTTPClientPolicy httpClientPolicy = new > > HTTPClientPolicy(); > > httpClientPolicy.setConnectionTimeout(HTTP_TIMEOUT_IN_MILLIS > > ECONDS); httpClientPolicy.setAllowChunking(false); > > > > final Client client = ClientProxy.getClient(port); > > final HTTPConduit httpConduit = > > > > (HTTPConduit)client.getConduit(); // triggers the stacktrace > > httpConduit.setClient(httpClientPolicy); > > > > The code works well under 2.5.0 and a significant number of earlier > > releases. Is there something I am forgetting to do to make sure said > > Address component is never null (taking into account that the WSDL > > does not declare the endpoint, it is dynamic configuration), or should > > it go into JIRA? > > > > // Johan Karlberg > > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
