Will look into it today.... Could be a flushing problem?
On 12/1/06, Andrea Smyth <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote: >Author: dandiep >Date: Thu Nov 30 11:19:29 2006 >New Revision: 481043 > >URL: http://svn.apache.org/viewvc?view=rev&rev=481043 >Log: >o Rewrite MTOM support to be completely streamed based. If attachments > are accessed out of order, they are cached. This is done through a > LazyAttachmentCollection. The iterator will iterate over attachments > as they are accessed, loading them one at a time until the correct > one is found. On the outgoing side the AttachmentSerializer allows > us to write out the attachments in steps. >o Move MTOM interceptors into core as they are dependent on SOAP and > some people would like to use it with XML over HTTP. >o Unify handling of Message.CONTENT_TYPE, transports are now expected > to deal with it correctly and we shouldn't have to muck with the protocol > headers to set the content type (like we were doing in > OutgoingChainSetupInterceptor). >o Rename some message properties to make it easier for configuration. >o Rewrite server side mtom test to not use the client to make it easy > to test and debug. >o Remove ugly Message.getAttachmentMimeType() method >o Try to use IOUtils.copy() in more places to reduce duplication >o This has not been interop tested. I think there may be an issue or two > when using with .NET 2.0, but I need to test and track down the issue > (will do so soon). > > > I am seeing the ClientMtomXopTest failing now on Windows: [surefire] Running org.apache.cxf.systest.mtom.ClientMtomXopTest [surefire] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 7.13 sec [surefire] [surefire] testMtomXop(org.apache.cxf.systest.mtom.ClientMtomXopTest) Time elap sed: 1.463 sec <<< FAILURE! junit.framework.ComparisonFailure: attachinfo changed expected:<... > but was:<...> at junit.framework.Assert.assertEquals(Assert.java:81) at org.apache.cxf.systest.mtom.ClientMtomXopTest.testMtomXop( ClientMtomXopTest.java:155) .... Any ideas? Andrea.
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
