cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oster, Scott " <Scott.Os...@osumc.edu>
Subject Re: Issue with wsdl2java "-allowElementReferences"
Date Thu, 03 Sep 2009 22:26:11 GMT
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" <dkulp@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
Mime
View raw message