I just committed a possible fix for this to trunk. Is there any
chance you could checkout the code and give it a quick try?
A very simple query to strikeiron returned OK, but I'm not a "power
user" type thing so if you have more complex cases, I'd love to make
sure they work as well.
Thanks!
Dan
On May 20, 2008, at 10:54 AM, JSP wrote:
I just ran through the debugger and the problem is the same as when
I was
using 2.0.5. Everything I mentioned previously is still the same -
that is,
the MessagePartInfo.getTypeClass() method returns null which causes
the
JAXBEncoderDecoder to attempt to unmarshal a Node without a class.
Then it
goes into the bowels of JAXB which throws this exception:
unexpected element (uri:"http://ws.strikeiron.com";,
local:"SubscriptionInfo"). Expected elements are
<{http://www.strikeiron.com}GetAllStatuses>,<{http://www.strikeiron.com
}GetAllStatusesResponse>,<{http://
www.strikeiron.com}GetAllTeamNicknames>,<{http://
www.strikeiron.com}GetAllTeamNicknamesResponse>,<{http://www.strikeiron.com
}GetRemainingHits>,<{http://
www.strikeiron.com}GetRemainingHitsResponse>,<{http://www.strikeiron.com
}GetServiceInfo>,<{http://
www.strikeiron.com}GetServiceInfoResponse>,<{http://
www.strikeiron.com}GetTeamInfoByCity>,<{http://
www.strikeiron.com}GetTeamInfoByCityResponse>,<{http://www.strikeiron.com
}GetTeamInfoByNickname>,<{http://
www.strikeiron.com}GetTeamInfoByNicknameResponse>
Again, it does not have a stack trace.
Is the MessagePartInfo.getTypeClass() supposed to be set to the
appropriate
class for a soap output header? Maybe there is some annotation that
would
cause this to happen? Or should JAXB be able to unmarshall the output
header without the class? It has the correct element.
Let me know if I can provide any more information.
dkulp wrote:
Well, unfortunately, that's a pretty useless stack trace. That NPE
is occuring while trying to create the Fault to represent the real
error. Thus, the real error from JAXB is lost. :-(
I've committed a fix to the JAXBEncoderDecoder that will hopefully
fix
that so we can see what the real error is. I'll get a new snapshot
deployed later today, but if you can checkout the code and build/test
with that, maybe we can at least see the real error.
Dan
On May 19, 2008, at 11:17 PM, JSP wrote:
We are now using 2.1 and I am still getting the same error, although
the line
numbers have changed. I haven't done any debugging of it yet, just
wanted
to see if you had any ideas first?
Here is the updated stack trace:
May 19, 2008 11:14:07 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
at
org
.apache
.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:642)
at
org
.apache
.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:555)
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:
64)
at
org
.apache
.cxf
.binding
.soap
.interceptor
.SoapHeaderInterceptor.handleMessage(SoapHeaderInterceptor.java:101)
at
org
.apache
.cxf
.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
221)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:
429)
at
org.apache.cxf.transport.http.HTTPConduit
$WrappedOutputStream.handleResponse(HTTPConduit.java:1988)
at
org.apache.cxf.transport.http.HTTPConduit
$WrappedOutputStream.close(HTTPConduit.java:1824)
at
org
.apache
.cxf
.io
.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:
47)
at
org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:
159)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:
66)
at
org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:
583)
at
org.apache.cxf.interceptor.MessageSenderInterceptor
$
MessageSenderEndingInterceptor
.handleMessage(MessageSenderInterceptor.java:62)
at
org
.apache
.cxf
.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
221)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:
73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
177)
Let me know if I can provide any additional information.
JSP wrote:
I'll try 2.0.6 and let you know.
dkulp wrote:
Can you try with 2.0.6 or 2.1? I added checks for
MessagePartInfo.getTypeClass() == null in several areas for
2.1/2.0.6. That may have taken care of this.
Dan
On May 14, 2008, at 3:32 PM, JSP wrote:
I am trying to consume one of the strikeiron web services which
take
an input
soap header and return an output soap header. When I execute a
request that
has an input soap header and an output soap header I get a null
pointer
exception. The request is sent successfully and the response is
recieved
but it cannot be unmarshalled. The null pointer exception is
misleading
because it occurs when handling another exception. This is the
null
pointer
exception:
Caused by: java.lang.NullPointerException
at
org
.apache
.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:
592)
at
org
.apache
.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:
498)
at
org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:
40)
at
org
.apache
.cxf
.binding
.soap
.interceptor
.SoapHeaderInterceptor.handleMessage(SoapHeaderInterceptor.java:
101)
This is the actual exception (unfortunately no stack trace):
javax.xml.bind.UnmarshalException: unexpected element
(uri:"http://ws.strikeiron.com";, local:"SubscriptionInfo").
Expected
elements are
<{http://www.strikeiron.com}GetAllStatuses>,<{http://www.strikeiron.com
}GetAllStatusesResponse>,<{http://
www.strikeiron.com}GetAllTeamNicknames>,<{http://
www.strikeiron.com}GetAllTeamNicknamesResponse>,<{http://www.strikeiron.com
}GetRemainingHits>,<{http://
www.strikeiron.com}GetRemainingHitsResponse>,<{http://www.strikeiron.com
}GetServiceInfo>,<{http://
www.strikeiron.com}GetServiceInfoResponse>,<{http://
www.strikeiron.com}GetTeamInfoByCity>,<{http://
www.strikeiron.com}GetTeamInfoByCityResponse>,<{http://www.strikeiron.com
}GetTeamInfoByNickname>,<{http://
www.strikeiron.com}GetTeamInfoByNicknameResponse>
I have traced through the code and it looks like cxf is trying to
unmarshal
a Node without a class.
Snippet of code from JAXBEncoderDecoder (unmarshalWithClass is
false):
if (source instanceof Node) {
obj = unmarshalWithClass ? u.unmarshal((Node)source,
clazz)
: u.unmarshal((Node)source);
} else if (source instanceof XMLStreamReader) {
And that is because the MessagePartInfo.getTypeClass() method
returns null.
I cannot find a place where the type class is set for the
MessagePartInfo
for the output soap header.
I have included a snippet of my interface if that helps - I'm
thinking I
must have something annotated incorrectly.
@ResponseWrapper(className =
"data
.footballws
.sdpnflteamssoap.com.strikeiron.www.GetAllTeamNicknamesResponse",
targetNamespace = "http://www.strikeiron.com";, localName =
"GetAllTeamNicknamesResponse")
@RequestWrapper(className =
"data
.footballws
.sdpnflteamssoap.com.strikeiron.www.GetAllTeamNicknames",
targetNamespace = "http://www.strikeiron.com";, localName =
"GetAllTeamNicknames")
@WebMethod(action = "http://www.strikeiron.com/
GetAllTeamNicknames",
operationName = "GetAllTeamNicknames")
public void _GetAllTeamNicknames(@WebParam(partName =
"LicenseInfoPart",
header = true, mode = WebParam.Mode.IN, targetNamespace =
"http://www.strikeiron.com";, name = "LicenseInfo")
LicenseInfo LicenseInfo, @WebParam(partName =
"GetAllTeamNicknamesResultPart", mode = WebParam.Mode.OUT,
targetNamespace =
"http://www.strikeiron.com";, name = "GetAllTeamNicknamesResult")
Holder<NFLTeamOutput> GetAllTeamNicknamesResult,
@WebParam(partName =
"SubscriptionInfoPart", header = true, mode = WebParam.Mode.OUT,
targetNamespace = "http://www.strikeiron.com";, name =
"SubscriptionInfo")
Holder<SubscriptionInfo> SubscriptionInfo);
Does anybody have an idea what I might be doing wrong?
BTW - I am using 2.0.5.
--
View this message in context:
http://www.nabble.com/NullPointerException-decoding-response-with-SOAP-header-tp17239110p17239110.html
Sent from the cxf-user mailing list archive at Nabble.com.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--
View this message in context:
http://www.nabble.com/NullPointerException-decoding-response-with-SOAP-header-tp17239110p17332466.html
Sent from the cxf-user mailing list archive at Nabble.com.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--
View this message in context:
http://www.nabble.com/NullPointerException-decoding-response-with-SOAP-header-tp17239110p17342443.html
Sent from the cxf-user mailing list archive at Nabble.com.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
