You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Sean O'Callaghan (JIRA)" <ji...@apache.org> on 2008/04/10 12:24:08 UTC

[jira] Assigned: (CXF-1058) java.lang.ClassCastException: java.io.BufferedOutputStream during large message transfer

     [ https://issues.apache.org/jira/browse/CXF-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sean O'Callaghan reassigned CXF-1058:
-------------------------------------

    Assignee: Sean O'Callaghan

> java.lang.ClassCastException: java.io.BufferedOutputStream during large message transfer
> ----------------------------------------------------------------------------------------
>
>                 Key: CXF-1058
>                 URL: https://issues.apache.org/jira/browse/CXF-1058
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-WS Runtime
>    Affects Versions: 2.0.1
>         Environment: Windows XP, Servicemix 3.2, CXF 2.0.1
>            Reporter: Ryan Moquin
>            Assignee: Sean O'Callaghan
>         Attachments: cxf.patch, junit_test.diff
>
>
> Returning a large amount of data from a CXF webservice causes the following error:
> Sep 21, 2007 12:00:29 PM org.apache.cxf.transport.jbi.JBIDestinationOutputStream commitOutputMessage
> SEVERE: error sending Out message
> java.lang.ClassCastException: java.io.BufferedOutputStream
>         at org.apache.cxf.transport.jbi.JBIDestinationOutputStream.commitOutputMessage(JBIDestinationOutputStream.java:76
> )
>         at org.apache.cxf.transport.jbi.JBIDestinationOutputStream.doClose(JBIDestinationOutputStream.java :62)
>         at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:119)
>         at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>         at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage (MessageSender
> Interceptor.java:62)
>         at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
>         at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage( OutgoingChainInterceptor.java :73)
>         at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
>         at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73)
>         at org.apache.cxf.transport.jbi.JBIDispatcherUtil.dispatch(JBIDispatcherUtil.java:148)
>         at org.apache.servicemix.cxfse.CxfSeEndpoint.process(CxfSeEndpoint.java:167)
>         at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess (AsyncBaseLifeCycle.java:538)
> This line of code causes the exception in JBIDestinationOutputStream:
> ByteArrayOutputStream baos = (ByteArrayOutputStream)getOut();
> Guillaume Nodet has given me an untested patch that he thought might fix the issue.  I have written a unittest which performs a write with a large amount of data and then attempts to close the stream.  Without the attached patch applied, the unit test will fail, but with it applied, the test passes.
> The CachedOutputStream class is really a haven for this sort of error since it seems that subclasses and invokers of this class seem to be assuming that the getOut() method will magically return the correct type of class that they need, but there are 3 types that could possibly be returned.  I would also suggest that to eliminate future errors, that this class use a ByteBuffer internally instead of dynamically manipulating OutputStreams (this would also make more sense if this class is meant to cache the data to be written).  It would be much easier to use one type consistently in this class rather than several.  The only problem I can see which this approach (which is why I haven't tried to implement it) is the constructor that allows a PipedInputStream.  If you guys are interested, I can implement a ByteBuffer internally, change getOut() to return a concrete OutputStream class (to eliminate ClassCastExceptions, or it could return the DataBuffer) and then write the DataBuffer to a stream when the data is to be committed.  This would be easy depending on the PipedInputStream in the constructor.  Using a directbuffer would probably make it pretty fast as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.