On Wednesday 09 June 2010 4:03:37 pm Kuhns, John wrote: > Hi, > > I am brand new to CXF, just downloaded about 4 hours ago, but I've got a > lot of experience with SOAP. I've been trying to implement a Java client > for an odd .Net web service served up by an outside company for several > days and found CXF today. I should state up front I am _not_ using Spring. > Also, I am using wsdl2java against the company's WSDL. > > The WS oddities are many, but where my difficulty comes in is that the WS > demands data encoded something like this: > > <dataElement><Element Attribute="Value"/></dataElement> > <objectElement><Element Attribute="Value"/></objectElement> > > Where dataElement is a String and objectElement is a sequence of any. Both > the dataElement and the objectElement are required, are equivalent aside > from the escaped < and > characters. Also they are valid XML document > fragments defined by the company that publishes the WS. > > I can fix the objectElement by creating a local copy of the WSDL and > modifying the sequence of any to match the document fragment I need to > consume, but I'm really stuck on the dataElement piece because the < is > being escaped as &lt;. If I change the dataElement to <Element.../>, > the result is <Element.../>, in other words the greater than doesn't > get escaped. Is there any way around this?
Hmm.. this falls down into the woodstox writers. I'm really not sure WHAT can be done here. One option could be to remove woodstox and see if the Sun parser built into java 6 would behave any differently. Possibly not. Escaping the ">" is not required so most stax impls won't as it's not-needed effort. Looking at: http://woodstox.codehaus.org/ConfiguringStreamWriters I see they have some config entries (P_TEXT_ESCAPER) for writing a custom escaper. You may be able to configure your own XMLOutputFactory using that stuff and set that on the request context. Would be something like: ((BindingProvider)proxy).getRequestContext() .put(XMLOutputFactory.class.getName(), factory); -- Daniel Kulp [email protected] http://dankulp.com/blog
