cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Moquin (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CXF-1058) java.lang.ClassCastException: java.io.BufferedOutputStream during large message transfer
Date Sat, 22 Sep 2007 05:47:50 GMT

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

Ryan Moquin updated CXF-1058:
-----------------------------

    Attachment: junit_test.diff

Junit diff of changes to exercise the fix.  I didn't attempt to make it reuseable since I
wasn't sure what way might work best and also because since there is only one test, why both
do that now.

> 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
>         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.


Mime
View raw message