You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Scott Oster <sc...@osumc.edu> on 2009/09/01 20:54:07 UTC
Issue with wsdl2java "-allowElementReferences"
I have run into a problem I believe is caused by the capability introduced
to close issue CXF-1079 (https://issues.apache.org/jira/browse/CXF-1079).
I am using CXF 2.2.3, and when I use this behavior (via the
allowElementReferences flag to wsdl2java), I see the error below when
invoking (via any client) my service running in jetty.
WARNING: Application has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: null while invoking <null> with params
[null].
at
org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.j
ava:152)
at
org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMet
hodInvoker.java:83)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:1
26)
at
org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:55)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:6
8)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInt
erceptor.java:58)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.jav
a:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceIn
vokerInterceptor.java:98)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain
.java:236)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationOb
server.java:104)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(Jett
yHTTPDestination.java:302)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTP
Destination.java:266)
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler
.java:70)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerColl
ection.java:230)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:
879)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520
)
Caused by: java.lang.NullPointerException
at
org.apache.cxf.service.invoker.AbstractInvoker.insertExchange(AbstractInvoke
r.java:171)
at
org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInv
oker.java:160)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:8
2)
... 24 more
The error is very non-descript, but by debugging the server, I have found
that the null pointer is caused by the lookup of the method to invoke for
the given soap message in JAXWSMethodInvoker. It looks up the method (via
SimpleMethodDispatcher) in this Map<OperationInfo, Method> opToMethod, and
despite there being an entry for the operation being invoked (mapped to the
³right² method in my implementation), it is not found in the map as the
³equals² method fails on the OperationInfo key. The reason is the
messageparts of the inputmessage from the bindingoperation in the map are
null, when they should not be (compared to what is being looked for from the
exchange). Here¹s the information from the debugger, showing this
difference:
o1={}
o2={{http://mms.cagrid.org/MetadataModelService}parameters=[MessagePartInfo
name={http://mms.cagrid.org/MetadataModelService}parameters,
ConcreteName={http://mms.cagrid.org/MetadataModelService}getModelSourceMetad
ata}
AbstractPropertiesHolder.equals(Object, Object) line: 168
MessageInfo(AbstractMessageContainer).equals(Object) line: 236
AbstractPropertiesHolder.equals(Object, Object) line: 168
UnwrappedOperationInfo(OperationInfo).equals(Object) line: 229
ConcurrentHashMap$Segment<K,V>.get(Object, int) line: 327
ConcurrentHashMap<K,V>.get(Object) line: 731
JAXWSMethodDispatcher(SimpleMethodDispatcher).getMethod(BindingOperationInfo
) line: 96
...
It took me a long time to figure out this flag was the cause, but walking
down this path on server initialization (
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.InitializeClassI
nfo()) keyed me in on the issue:
if (o.getUnwrappedOperation() == null) {
//the "normal" algorithm didn't allow for unwrapping,
//but the annotations say unwrap this. We'll need to
//make it.
WSDLServiceBuilder.checkForWrapped(o, true);
}
I believe the code that initializes the Operation to Method map is not in
sync with the code that puts the OperationInfo on the exchange. That is,
when you walk down the path of not being ³normal² unwrapping, the
information that is being cached (no input message parts) is not the same
was what is being looked for when the operation is looked up in the map (an
empty request object).
I¹m not very familiar with how this is supposed to work, but I would like to
leverage this allowElementReferences flag, but I¹m fairly certain it is not
working correctly (I believe I did have it working from trunk at one point).
Scott
Scott Oster
Co-Director
Software Research Institute
Center for IT Innovations in Healthcare
Senior Researcher
Department of Biomedical Informatics
The Ohio State University
Phone: (614) 293-9590
Re: Issue with wsdl2java "-allowElementReferences"
Posted by Daniel Kulp <dk...@apache.org>.
On Thu September 3 2009 6:26:11 pm Oster, Scott wrote:
> That's great. If you send me a patch I can test against my more
> elaborate example as well.
>
I've include below. Definitely nothing big.
The SNAPSHOTs should be deployed tonight with the fix in it.
Dan
Index:
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/support/JaxWsServiceFactoryBean.java
===================================================================
---
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/support/JaxWsServiceFactoryBean.java
(revision 811150)
+++
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/support/JaxWsServiceFactoryBean.java
(working copy)
@@ -196,13 +196,13 @@
o.setProperty(METHOD, method);
initializeWrapping(o, method);
- bindOperation(o, method);
-
// rpc out-message-part-info class mapping
Operation op =
(Operation)o.getProperty(WSDLServiceBuilder.WSDL_OPERATION);
initializeClassInfo(o, method, op == null ? null
: CastUtils.cast(op.getParameterOrdering(), String.class));
+
+ bindOperation(o, method);
}
protected void bindOperation(OperationInfo op, Method method) {
> Scott
>
> * Sent from my phone.
>
> On Sep 3, 2009, at 5:32 PM, "Daniel Kulp" <dk...@apache.org> wrote:
> > Just FYI: I have a (2 line) fix for this I'm testing now. We were
> > binding the
> > operation to the method prior to checking if we have to go back and
> > re-check
> > for the "extra rules" such as the element references. Just moved
> > the bind
> > line down a bit and it works.
> >
> > Dan
> >
> > On Tue September 1 2009 2:54:07 pm Scott Oster wrote:
> >> I have run into a problem I believe is caused by the capability
> >> introduced
> >> to close issue CXF-1079 (https://issues.apache.org/jira/browse/CXF-1079
> >> ).
> >>
> >> I am using CXF 2.2.3, and when I use this behavior (via the
> >> allowElementReferences flag to wsdl2java), I see the error below when
> >> invoking (via any client) my service running in jetty.
> >>
> >> WARNING: Application has thrown exception, unwinding now
> >> org.apache.cxf.interceptor.Fault: null while invoking <null> with
> >> params
> >> [null].
> >> at
> >> org.apache.cxf.service.invoker.AbstractInvoker.createFault
> >> (AbstractInvoker.
> >> j ava:152)
> >> at
> >> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault
> >> (AbstractJAXWSMe
> >> t hodInvoker.java:83)
> >> at
> >> org.apache.cxf.service.invoker.AbstractInvoker.invoke
> >> (AbstractInvoker.java:
> >> 1 26)
> >> at
> >> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke
> >> (JAXWSMethodInvoker.java:55)
> >> at
> >> org.apache.cxf.service.invoker.AbstractInvoker.invoke
> >> (AbstractInvoker.java:
> >> 6 8)
> >> at
> >> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run
> >> (ServiceInvokerIn
> >> t erceptor.java:58)
> >> at
> >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
> >> 417)
> >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:
> >> 269)
> >> at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> >> at
> >> org.apache.cxf.workqueue.SynchronousExecutor.execute
> >> (SynchronousExecutor.ja
> >> v a:37)
> >> at
> >> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage
> >> (ServiceI
> >> n vokerInterceptor.java:98)
> >> at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept
> >> (PhaseInterceptorChai
> >> n .java:236)
> >> at
> >> org.apache.cxf.transport.ChainInitiationObserver.onMessage
> >> (ChainInitiationO
> >> b server.java:104)
> >> at
> >> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(
> >> Jet
> >> t yHTTPDestination.java:302)
> >> at
> >> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService
> >> (JettyHTT
> >> P Destination.java:266)
> >> at
> >> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle
> >> (JettyHTTPHandle
> >> r .java:70)
> >> at
> >> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:
> >> 765)
> >> at
> >> org.mortbay.jetty.handler.ContextHandlerCollection.handle
> >> (ContextHandlerCol
> >> l ection.java:230)
> >> at
> >> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:
> >> 152)
> >> at org.mortbay.jetty.Server.handle(Server.java:326)
> >> at
> >> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
> >> 534)
> >> at
> >> org.mortbay.jetty.HttpConnection$RequestHandler.content
> >> (HttpConnection.java
> >>
> >> : 879)
> >>
> >> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
> >> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:
> >> 218)
> >> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:
> >> 404)
> >> at
> >> org.mortbay.io.nio.SelectChannelEndPoint.run
> >> (SelectChannelEndPoint.java:409
> >> ) at
> >> org.mortbay.thread.QueuedThreadPool$PoolThread.run
> >> (QueuedThreadPool.java:52
> >> 0 )
> >> Caused by: java.lang.NullPointerException
> >> at
> >> org.apache.cxf.service.invoker.AbstractInvoker.insertExchange
> >> (AbstractInvok
> >> e r.java:171)
> >> at
> >> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation
> >> (AbstractIn
> >> v oker.java:160)
> >> at
> >> org.apache.cxf.service.invoker.AbstractInvoker.invoke
> >> (AbstractInvoker.java:
> >> 8 2)
> >> ... 24 more
> >>
> >> The error is very non-descript, but by debugging the server, I have
> >> found
> >> that the null pointer is caused by the lookup of the method to
> >> invoke for
> >> the given soap message in JAXWSMethodInvoker. It looks up the
> >> method (via
> >> SimpleMethodDispatcher) in this Map<OperationInfo, Method>
> >> opToMethod, and
> >> despite there being an entry for the operation being invoked
> >> (mapped to the
> >> ³right² method in my implementation), it is not found in the map a
> >> s the
> >> ³equals² method fails on the OperationInfo key. The reason is the
> >> messageparts of the inputmessage from the bindingoperation in the
> >> map are
> >> null, when they should not be (compared to what is being looked for
> >> from
> >> the exchange). Here¹s the information from the debugger, showing
> >> this
> >> difference:
> >>
> >> o1={}
> >> o2={{http://mms.cagrid.org/MetadataModelService}parameters=
> >> [MessagePartInfo
> >> name={http://mms.cagrid.org/MetadataModelService}parameters,
> >> ConcreteName={http://mms.cagrid.org/MetadataModelService}
> >> getModelSourceMeta
> >> d ata}
> >>
> >> AbstractPropertiesHolder.equals(Object, Object) line: 168
> >> MessageInfo(AbstractMessageContainer).equals(Object) line: 236
> >> AbstractPropertiesHolder.equals(Object, Object) line: 168
> >> UnwrappedOperationInfo(OperationInfo).equals(Object) line: 229
> >> ConcurrentHashMap$Segment<K,V>.get(Object, int) line: 327
> >> ConcurrentHashMap<K,V>.get(Object) line: 731
> >> JAXWSMethodDispatcher(SimpleMethodDispatcher).getMethod
> >> (BindingOperationInf
> >> o ) line: 96
> >> ...
> >>
> >> It took me a long time to figure out this flag was the cause, but
> >> walking
> >> down this path on server initialization (
> >> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.InitializeCl
> >>ass
> >>
> >>
> >> I nfo()) keyed me in on the issue:
> >> if (o.getUnwrappedOperation() == null) {
> >> //the "normal" algorithm didn't allow for unwrapping,
> >> //but the annotations say unwrap this. We'll need to
> >> //make it.
> >> WSDLServiceBuilder.checkForWrapped(o, true);
> >> }
> >>
> >> I believe the code that initializes the Operation to Method map is
> >> not in
> >> sync with the code that puts the OperationInfo on the exchange.
> >> That is,
> >> when you walk down the path of not being ³normal² unwrapping, the
> >> information that is being cached (no input message parts) is not
> >> the same
> >> was what is being looked for when the operation is looked up in the
> >> map (an
> >> empty request object).
> >>
> >> I¹m not very familiar with how this is supposed to work, but I wou
> >> ld like
> >> to leverage this allowElementReferences flag, but I¹m fairly cert
> >> ain it
> >> is not working correctly (I believe I did have it working from
> >> trunk at
> >> one point).
> >>
> >> Scott
> >>
> >> Scott Oster
> >>
> >> Co-Director
> >> Software Research Institute
> >> Center for IT Innovations in Healthcare
> >>
> >> Senior Researcher
> >> Department of Biomedical Informatics
> >>
> >> The Ohio State University
> >> Phone: (614) 293-9590
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Issue with wsdl2java "-allowElementReferences"
Posted by "Oster, Scott " <Sc...@osumc.edu>.
That's great. If you send me a patch I can test against my more
elaborate example as well.
Scott
* Sent from my phone.
On Sep 3, 2009, at 5:32 PM, "Daniel Kulp" <dk...@apache.org> wrote:
>
> Just FYI: I have a (2 line) fix for this I'm testing now. We were
> binding the
> operation to the method prior to checking if we have to go back and
> re-check
> for the "extra rules" such as the element references. Just moved
> the bind
> line down a bit and it works.
>
> Dan
>
>
> On Tue September 1 2009 2:54:07 pm Scott Oster wrote:
>> I have run into a problem I believe is caused by the capability
>> introduced
>> to close issue CXF-1079 (https://issues.apache.org/jira/browse/CXF-1079
>> ).
>>
>> I am using CXF 2.2.3, and when I use this behavior (via the
>> allowElementReferences flag to wsdl2java), I see the error below when
>> invoking (via any client) my service running in jetty.
>>
>> WARNING: Application has thrown exception, unwinding now
>> org.apache.cxf.interceptor.Fault: null while invoking <null> with
>> params
>> [null].
>> at
>> org.apache.cxf.service.invoker.AbstractInvoker.createFault
>> (AbstractInvoker.
>> j ava:152)
>> at
>> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault
>> (AbstractJAXWSMe
>> t hodInvoker.java:83)
>> at
>> org.apache.cxf.service.invoker.AbstractInvoker.invoke
>> (AbstractInvoker.java:
>> 1 26)
>> at
>> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke
>> (JAXWSMethodInvoker.java:55)
>> at
>> org.apache.cxf.service.invoker.AbstractInvoker.invoke
>> (AbstractInvoker.java:
>> 6 8)
>> at
>> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run
>> (ServiceInvokerIn
>> t erceptor.java:58)
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
>> 417)
>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:
>> 269)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:123)
>> at
>> org.apache.cxf.workqueue.SynchronousExecutor.execute
>> (SynchronousExecutor.ja
>> v a:37)
>> at
>> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage
>> (ServiceI
>> n vokerInterceptor.java:98)
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept
>> (PhaseInterceptorChai
>> n .java:236)
>> at
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage
>> (ChainInitiationO
>> b server.java:104)
>> at
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(
>> Jet
>> t yHTTPDestination.java:302)
>> at
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService
>> (JettyHTT
>> P Destination.java:266)
>> at
>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle
>> (JettyHTTPHandle
>> r .java:70)
>> at
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:
>> 765)
>> at
>> org.mortbay.jetty.handler.ContextHandlerCollection.handle
>> (ContextHandlerCol
>> l ection.java:230)
>> at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:
>> 152)
>> at org.mortbay.jetty.Server.handle(Server.java:326)
>> at
>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
>> 534)
>> at
>> org.mortbay.jetty.HttpConnection$RequestHandler.content
>> (HttpConnection.java
>> : 879)
>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:
>> 218)
>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:
>> 404)
>> at
>> org.mortbay.io.nio.SelectChannelEndPoint.run
>> (SelectChannelEndPoint.java:409
>> ) at
>> org.mortbay.thread.QueuedThreadPool$PoolThread.run
>> (QueuedThreadPool.java:52
>> 0 )
>> Caused by: java.lang.NullPointerException
>> at
>> org.apache.cxf.service.invoker.AbstractInvoker.insertExchange
>> (AbstractInvok
>> e r.java:171)
>> at
>> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation
>> (AbstractIn
>> v oker.java:160)
>> at
>> org.apache.cxf.service.invoker.AbstractInvoker.invoke
>> (AbstractInvoker.java:
>> 8 2)
>> ... 24 more
>>
>> The error is very non-descript, but by debugging the server, I have
>> found
>> that the null pointer is caused by the lookup of the method to
>> invoke for
>> the given soap message in JAXWSMethodInvoker. It looks up the
>> method (via
>> SimpleMethodDispatcher) in this Map<OperationInfo, Method>
>> opToMethod, and
>> despite there being an entry for the operation being invoked
>> (mapped to the
>> ³right² method in my implementation), it is not found in the map a
>> s the
>> ³equals² method fails on the OperationInfo key. The reason is the
>> messageparts of the inputmessage from the bindingoperation in the
>> map are
>> null, when they should not be (compared to what is being looked for
>> from
>> the exchange). Here¹s the information from the debugger, showing
>> this
>> difference:
>>
>> o1={}
>> o2={{http://mms.cagrid.org/MetadataModelService}parameters=
>> [MessagePartInfo
>> name={http://mms.cagrid.org/MetadataModelService}parameters,
>> ConcreteName={http://mms.cagrid.org/MetadataModelService}
>> getModelSourceMeta
>> d ata}
>>
>> AbstractPropertiesHolder.equals(Object, Object) line: 168
>> MessageInfo(AbstractMessageContainer).equals(Object) line: 236
>> AbstractPropertiesHolder.equals(Object, Object) line: 168
>> UnwrappedOperationInfo(OperationInfo).equals(Object) line: 229
>> ConcurrentHashMap$Segment<K,V>.get(Object, int) line: 327
>> ConcurrentHashMap<K,V>.get(Object) line: 731
>> JAXWSMethodDispatcher(SimpleMethodDispatcher).getMethod
>> (BindingOperationInf
>> o ) line: 96
>> ...
>>
>> It took me a long time to figure out this flag was the cause, but
>> walking
>> down this path on server initialization (
>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.InitializeClass
>> I nfo()) keyed me in on the issue:
>> if (o.getUnwrappedOperation() == null) {
>> //the "normal" algorithm didn't allow for unwrapping,
>> //but the annotations say unwrap this. We'll need to
>> //make it.
>> WSDLServiceBuilder.checkForWrapped(o, true);
>> }
>>
>> I believe the code that initializes the Operation to Method map is
>> not in
>> sync with the code that puts the OperationInfo on the exchange.
>> That is,
>> when you walk down the path of not being ³normal² unwrapping, the
>> information that is being cached (no input message parts) is not
>> the same
>> was what is being looked for when the operation is looked up in the
>> map (an
>> empty request object).
>>
>> I¹m not very familiar with how this is supposed to work, but I wou
>> ld like
>> to leverage this allowElementReferences flag, but I¹m fairly cert
>> ain it
>> is not working correctly (I believe I did have it working from
>> trunk at
>> one point).
>>
>> Scott
>>
>> Scott Oster
>>
>> Co-Director
>> Software Research Institute
>> Center for IT Innovations in Healthcare
>>
>> Senior Researcher
>> Department of Biomedical Informatics
>>
>> The Ohio State University
>> Phone: (614) 293-9590
>>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
Re: Issue with wsdl2java "-allowElementReferences"
Posted by Daniel Kulp <dk...@apache.org>.
Just FYI: I have a (2 line) fix for this I'm testing now. We were binding the
operation to the method prior to checking if we have to go back and re-check
for the "extra rules" such as the element references. Just moved the bind
line down a bit and it works.
Dan
On Tue September 1 2009 2:54:07 pm Scott Oster wrote:
> I have run into a problem I believe is caused by the capability introduced
> to close issue CXF-1079 (https://issues.apache.org/jira/browse/CXF-1079).
>
> I am using CXF 2.2.3, and when I use this behavior (via the
> allowElementReferences flag to wsdl2java), I see the error below when
> invoking (via any client) my service running in jetty.
>
> WARNING: Application has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: null while invoking <null> with params
> [null].
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.
> j ava:152)
> at
> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMe
> t hodInvoker.java:83)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:
> 1 26)
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:55)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:
> 6 8)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerIn
> t erceptor.java:58)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.ja
> v a:37)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceI
> n vokerInterceptor.java:98)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n .java:236)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationO
> b server.java:104)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(Jet
> t yHTTPDestination.java:302)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTT
> P Destination.java:266)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandle
> r .java:70)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCol
> l ection.java:230)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:326)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java
> : 879)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409
> ) at
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:52
> 0 )
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.service.invoker.AbstractInvoker.insertExchange(AbstractInvok
> e r.java:171)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractIn
> v oker.java:160)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:
> 8 2)
> ... 24 more
>
> The error is very non-descript, but by debugging the server, I have found
> that the null pointer is caused by the lookup of the method to invoke for
> the given soap message in JAXWSMethodInvoker. It looks up the method (via
> SimpleMethodDispatcher) in this Map<OperationInfo, Method> opToMethod, and
> despite there being an entry for the operation being invoked (mapped to the
> ³right² method in my implementation), it is not found in the map as the
> ³equals² method fails on the OperationInfo key. The reason is the
> messageparts of the inputmessage from the bindingoperation in the map are
> null, when they should not be (compared to what is being looked for from
> the exchange). Here¹s the information from the debugger, showing this
> difference:
>
> o1={}
> o2={{http://mms.cagrid.org/MetadataModelService}parameters=[MessagePartInfo
> name={http://mms.cagrid.org/MetadataModelService}parameters,
> ConcreteName={http://mms.cagrid.org/MetadataModelService}getModelSourceMeta
> d ata}
>
> AbstractPropertiesHolder.equals(Object, Object) line: 168
> MessageInfo(AbstractMessageContainer).equals(Object) line: 236
> AbstractPropertiesHolder.equals(Object, Object) line: 168
> UnwrappedOperationInfo(OperationInfo).equals(Object) line: 229
> ConcurrentHashMap$Segment<K,V>.get(Object, int) line: 327
> ConcurrentHashMap<K,V>.get(Object) line: 731
> JAXWSMethodDispatcher(SimpleMethodDispatcher).getMethod(BindingOperationInf
> o ) line: 96
> ...
>
> It took me a long time to figure out this flag was the cause, but walking
> down this path on server initialization (
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.InitializeClass
> I nfo()) keyed me in on the issue:
> if (o.getUnwrappedOperation() == null) {
> //the "normal" algorithm didn't allow for unwrapping,
> //but the annotations say unwrap this. We'll need to
> //make it.
> WSDLServiceBuilder.checkForWrapped(o, true);
> }
>
> I believe the code that initializes the Operation to Method map is not in
> sync with the code that puts the OperationInfo on the exchange. That is,
> when you walk down the path of not being ³normal² unwrapping, the
> information that is being cached (no input message parts) is not the same
> was what is being looked for when the operation is looked up in the map (an
> empty request object).
>
> I¹m not very familiar with how this is supposed to work, but I would like
> to leverage this allowElementReferences flag, but I¹m fairly certain it
> is not working correctly (I believe I did have it working from trunk at
> one point).
>
> Scott
>
> Scott Oster
>
> Co-Director
> Software Research Institute
> Center for IT Innovations in Healthcare
>
> Senior Researcher
> Department of Biomedical Informatics
>
> The Ohio State University
> Phone: (614) 293-9590
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog