cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Issue with wsdl2java "-allowElementReferences"
Date Thu, 03 Sep 2009 21:32:47 GMT

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

Mime
View raw message