Is there any way that I can make it work for cxf 2.1.7 latest version also?
Please let me know. Thanks, Deepika On Wed, Oct 28, 2009 at 5:28 PM, deepika vadapalli < [email protected]> wrote: > *The most important thing is it is working with CXF 2.0.4 incubator > version.* > ** > I have upgraded to CXF 2.1.x because it ahs latest updates/patches. I do > not want to use such old incubtor version. > > Yes...This is the code where I set that. > > > Client httpClient = factory.getClientFactoryBean().getClient(); > > HTTPConduit conduit = (HTTPConduit) httpClient.getConduit(); > > HTTPClientPolicy httpClientPolicy = *new* HTTPClientPolicy(); > > httpClientPolicy.setConnection(ConnectionType.*KEEP_ALIVE*); > > httpClientPolicy.setAllowChunking(*false*); > > httpClientPolicy.setReceiveTimeout(300000); > > conduit.setClient(httpClientPolicy); > > > > But even I tried the same with making chunking as true. That also didn't > work. > > ** > > I just tried now. > > > > Thanks, > > Deepika > > > > > On Wed, Oct 28, 2009 at 5:17 PM, Daniel Kulp <[email protected]> wrote: > >> >> Now we might be getting someplace..... >> >> Do you have configuration or something on the http conduit that would turn >> off >> streaming on the sending side? Authentication things? Redirect? >> Chunking? >> Etc.... >> >> How large is the SENT message? >> >> Dan >> >> >> On Wed October 28 2009 5:01:14 pm deepika vadapalli wrote: >> > But the problem is with CXF 2.1.7, its not going into my interceptor >> code >> > second time. >> > It goes through my interceptor code fine, but then it fails with null >> > pointer exception at >> > * >> > >> > java.lang.NullPointerException >> > * >> > >> > at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(* >> > HTTPConduit.java:1935*) >> > >> > at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(* >> > CacheAndWriteOutputStream.java:47*) >> > >> > at >> > >> org.apache.cxf.io.CachedOutputStream.close(*CachedOutputStream.java:188*) >> > >> > at >> > >> org.apache.cxf.transport.AbstractConduit.close(*AbstractConduit.java:66*) >> > >> > at >> org.apache.cxf.transport.http.HTTPConduit.close(*HTTPConduit.java:627*) >> > >> > at >> > >> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte >> > rceptor.handleMessage( *MessageSenderInterceptor.java:62*) >> > >> > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(* >> > PhaseInterceptorChain.java:236*) >> > >> > at org.apache.cxf.endpoint.ClientImpl.invoke(*ClientImpl.java:478*) >> > >> > at org.apache.cxf.endpoint.ClientImpl.invoke(*ClientImpl.java:308*) >> > >> > at org.apache.cxf.endpoint.ClientImpl.invoke(*ClientImpl.java:260*) >> > >> > at org.apache.cxf.frontend.ClientProxy.invokeSync(*ClientProxy.java:73*) >> > >> > at >> > >> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(*JaxWsClientProxy.java:127*) >> > >> > On Wed, Oct 28, 2009 at 4:03 PM, Daniel Kulp <[email protected]> wrote: >> > > On Wed October 28 2009 3:47:07 pm deepika vadapalli wrote: >> > > > No.the request is huge but the resposne is just confirmation number. >> > > > I get the resposne, log it once and then I get Null pointer >> Exception. >> > > > >> > > > This happens in a composite. >> > > > I do not know how to provide a test case. >> > > >> > > Without a testcase that I can run, I really don't think there is >> anything >> > > I can do to fix it. The best I can suggest is a workaround for you. >> > > >> > > In your loggers handleMessage, do something like: >> > > if (message.containsKey("logging was done")) { >> > > return; >> > > } >> > > message.put("logging was done", Boolean.TRUE); >> > > >> > > >> > > That should prevent the second logging from triggering. >> > > >> > > I'd really like to know why it's even occurring. No idea on that and >> > > without >> > > a test case, not much I can do. >> > > >> > > Dan >> > > >> > > > Thanks, >> > > > Laxmi >> > > > >> > > > On Wed, Oct 28, 2009 at 3:36 PM, Daniel Kulp <[email protected]> >> wrote: >> > > > > Without a reproducible test case, I'm not sure if there is >> anything >> > > > > I'm going >> > > > > to be able to do. >> > > > > >> > > > > One thought: is the message coming back a fault? (hard to >> imagine >> > > > > a fault >> > > > > that big, but I suppose it's possible) >> > > > > >> > > > > Dan >> > > >> > > -- >> > > Daniel Kulp >> > > [email protected] >> > > http://www.dankulp.com/blog >> > >> >> -- >> Daniel Kulp >> [email protected] >> http://www.dankulp.com/blog >> > >
