I know it's not in CXF, but for what it's worth in case someone stumbles across this thread via Google. The problem was namespace related.
The problematic query looked like this (note the "xmlns" bits): <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <findContacts xmlns="http://ourdns.com"> <RequestTransaction> <queryInfo xmlns=""> ...stuff </queryInfo> </RequestTransaction> </findContacts> </soap:Body> </soap:Envelope> CXF (or JAXB underneath) threw the error unless the "xmlns" bits designated a namespace, such as "xmlns:ns1". A successful request looked like: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns1:findContacts xmlns:ns1="http://ourdns.com"> <ns2:RequestTransaction xmlns:ns2="http://ourdns.com"> <queryInfo> ...stuff </queryInfo> </ns2:RequestTransaction> </ns1:findContacts> </soap:Body> </soap:Envelope> I don't know much about name spaces, so I don't really know if that means JAXB is being overly picky or if the customer end wasn't honoring the specs around name spaces. FYI, Chris -----Original Message----- From: Sergey Beryozkin [mailto:[email protected]] Sent: Friday, November 19, 2010 2:03 AM To: [email protected] Subject: Re: "Namespace URIs and local names to the unmarshaller needs to be interned" I've seen this exception before and I've been able to reproduce it this morning in rt/frontend/jaxrs/.../JAXBElementProviderTest. Look at AbstractJaxbProvider.InTransformReader#getProperty. It overrides it with the only purpose : return false for "org.codehaus.stax2.internNames" and "org.codehaus.stax2.internNsUris". If you disable this code then you'll see a couple of JAXBElementProviderTest tests failing. As far as I remember, JAXB queries for the values of these properties and when say Woodstox is used without custom readers/writers being introduced, it probably returns 'true' and then does some sort of interning. So in my case I can only make sure the custom reader returns false. I think that not all custom XMLStreamReaders should have to deal with these properties - it probably depends on how do they go in customizing the reading process. Hope it helps a bit Sergey On Thu, Nov 18, 2010 at 11:10 PM, Kessel, Christopher < [email protected]> wrote: > I appreciate the pointers. I'm baffled too. We use the SOAP interface > heavily (our servers use it to talk internally) so I know it works, or can > work anyway. I can even get it to work just fine with a direct command line > "curl". > > The fellow on the other end is much like me, but using C#. The wsdl creates > code and it's all black box stuff on the actual underlying communication :) > > Thanks, > Chris > > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Thursday, November 18, 2010 1:29 PM > To: [email protected] > Cc: Kessel, Christopher > Subject: Re: "Namespace URIs and local names to the unmarshaller needs to > be interned" > > On Thursday 18 November 2010 4:18:11 pm Kessel, Christopher wrote: > > We're in production with it and headed in a 2-month change moratorium for > > the holiday season, so I can't swap anything out for probably 3 months > > unless failure to do so will activate a tactical nuke somewhere. Even > > then, there'd be a risk analysis study. > > > > Any suggestions on what to look for in their input that'd be causing it? > > It's a customer writing their integration with our SOAP server, so even > > though I can't change anything right now, they might be able to change > > something on their end. > > Honestly, I have NO idea. IMO, this is something that would pretty much > always occur (aka: for all customers) or for none of them. I really don't > know what would trigger this for just SOME messages and not others. :-( > > The only thing I can think of would be to capture the raw soap messages and > try and compare them with messages that do work. I don't THINK an extra > child element that isn't in the schema would cause this, but it might. > > You could TRY turning on schema validation as well. That may change things > or > maybe give an error message if that is what the problem is. > > Dan > > > > > > Thanks, > > Chris > > > > -----Original Message----- > > From: Daniel Kulp [mailto:[email protected]] > > Sent: Thursday, November 18, 2010 12:54 PM > > To: [email protected] > > Cc: Kessel, Christopher > > Subject: Re: "Namespace URIs and local names to the unmarshaller needs to > > be interned" > > > > On Thursday 18 November 2010 2:31:05 pm Kessel, Christopher wrote: > > > Any idea what this error means? A customer is trying to access our SOAP > > > interface, we're using CXF (2.2.6 I think), and I can see the exception > > > in the log. I can't duplicate it. > > > > I saw some similar issues like this when doing some work on the > FastInfoset > > stuff. My recommendations: > > > > 1) Try with CXF 2.2.10 or 2.3.0. We've done a bit of work to make sure > > the original XMLStreamReaders are passed into JAXB and JAXB usually can > > then reconfigure them a bit better to make sure things are interned > > correctly and such. > > > > 2) Make sure Woodstox is picked up and not the parser built into the JDK. > > > > Dan > > > > > I suspect it has nothing to do with CXF itself, but I really have no > idea > > > what it means. > > > > > > Thanks, > > > Chris > > > > > > DefaultValidationEventHandler: [ERROR]: Namespace URIs and local names > to > > > the unmarshaller needs to be interned. > org.apache.cxf.interceptor.Fault: > > > Unmarshalling Error: Namespace URIs and local names to the unmarshaller > > > needs to be interned. at > > > > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java > > > : 764) at > > > > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java > > > : 623) at > > > org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:128) at > > > > org.apache.cxf.interceptor.DocLiteralInInterceptor.getPara(DocLiteralInIn > > > t erceptor.java:248) at > > > > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiter > > > a lInInterceptor.java:124) at > > > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCh > > > a in.java:243) at > > > > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiatio > > > n Observer.java:109) at > > > > org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestina > > > t ion.java:98) at > > > > org.apache.cxf.transport.servlet.ServletController.invokeDestination(Serv > > > l etController.java:406) at > > > > org.apache.cxf.transport.servlet.ServletController.invoke(ServletControll > > > e r.java:178) at > > > > org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFSer > > > v let.java:142) at > > > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(Abstra > > > c tHTTPServlet.java:179) at > > > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPS > > > e rvlet.java:103) at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at > > > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTP > > > S ervlet.java:159) at > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicat > > > i onFilterChain.java:290) at > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilte > > > r Chain.java:206) at > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve > > > . java:233) at > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve > > > . java:191) at > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java: > > > 1 28) at > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: > > > 1 02) at > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.j > > > a va:109) at > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:29 > > > 3 ) at > > > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849 > > > ) at > > > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(H > > > t tp11Protocol.java:583) at > > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) > > > at java.lang.Thread.run(Thread.java:619) > > > Caused by: javax.xml.bind.UnmarshalException > > > > > > - with linked exception: > > > [javax.xml.bind.UnmarshalException: Namespace URIs and local names to > the > > > unmarshaller needs to be interned.] at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamExc > > > e ption(UnmarshallerImpl.java:425) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(Unma > > > r shallerImpl.java:362) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(Unmar > > > s hallerImpl.java:339) at > > > > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java > > > : 749) ... 26 more > > > Caused by: javax.xml.bind.UnmarshalException: Namespace URIs and local > > > names to the unmarshaller needs to be interned. at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent > > > ( UnmarshallingContext.java:642) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:2 > > > 5 4) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:2 > > > 4 9) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElem > > > e nt(Loader.java:114) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java: > > > 1 01) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(Str > > > u ctureLoader.java:245) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startEleme > > > n t(UnmarshallingContext.java:478) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElemen > > > t (UnmarshallingContext.java:459) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartE > > > l ement(StAXStreamConnector.java:242) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXS > > > t reamConnector.java:176) at > > > > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(Unma > > > r shallerImpl.java:360) ... 28 more > > > Caused by: javax.xml.bind.UnmarshalException: Namespace URIs and local > > > names to the unmarshaller needs to be interned. ... 39 more > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog >
