Got to the bottom of this ... changing the test to be tolerant of an extra "\n" in the attachment body.
Cheers, Eoghan > -----Original Message----- > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > Sent: 01 February 2007 15:40 > To: [email protected] > Subject: RE: Patch for JIRA > https://issues.apache.org/jira/browse/CXF-398 > > > Sergey, > > I'm seeing the following failure against this patch. > > Ideas? > > /Eoghan > > [surefire] > testRequestWithAttachment(org.apache.cxf.systest.provider.Atta > chmentProv > iderXMLClientServerTest) Time elapsed: 0.275 sec <<< FAILURE! > junit.framework.AssertionFailedError: No encoded attachment > with id foo found > at junit.framework.Assert.fail(Assert.java:47) > at > org.apache.cxf.systest.provider.AttachmentProviderXMLClientSer > verTest.ve > rifyAttachment(AttachmentProviderXMLClientServerTest.java:118) > at > org.apache.cxf.systest.provider.AttachmentProviderXMLClientSer > verTest.te > stRequestWithAttachment(AttachmentProviderXMLClientServerTest. > java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess > orImpl.jav > a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth > odAccessor > Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at > junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at > junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at > junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess > orImpl.jav > a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth > odAccessor > Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JU > nitBattery > .java:242) > at > org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBa > ttery.java > :216) > at > org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) > at org.apache.maven.surefire.Surefire.run(Surefire.java:126) > at org.apache.maven.surefire.Surefire.run(Surefire.java:87) > at org.apache.maven.surefire.Surefire.run(Surefire.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess > orImpl.jav > a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth > odAccessor > Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785) > > > > Results : > [surefire] Tests run: 1, Failures: 1, Errors: 0 > > > > -----Original Message----- > > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > > Sent: 01 February 2007 15:18 > > To: [email protected] > > Subject: RE: Patch for JIRA > > https://issues.apache.org/jira/browse/CXF-398 > > > > > > Just doing a full test run on Linux against this patch, I'll commit > > when this completes. > > > > Cheers, > > Eoghan > > > > > -----Original Message----- > > > From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] > > > Sent: 01 February 2007 15:09 > > > To: [email protected] > > > Subject: Re: Patch for JIRA > > > https://issues.apache.org/jira/browse/CXF-398 > > > > > > Hi Eoghan > > > > > > Thanks for the comments. Please find a second patch, > > > https://issues.apache.org/jira/secure/attachment/12350140/rt_p > > > rovider_attachment2.patch > > > > > > which includes these updates. > > > > > > On ServletDestination : in copyResponseHeaders() it also > > deals with an > > > optional charset value of the Content-Type header, but I haven't > > > pushed that code into http and http2 codebase. I believe only the > > > application (provider) code can really customize this > > setting (as that > > > code does not/should not do it by setting the charset on > > the message > > > explicitly, as that code assumes) and if so it will be > > properly copied > > > in all 3 cases (JettyHTTPDestination in http.http2, > > > ServletDestination) as a Content-Type optional value... > > > > > > > > > Please let me know if you have any other suggestions/comments > > > > > > Cheers, Sergey > > > > > > > > > > > > Hi Sergey, > > > > > > I can apply this patch. > > > > > > However there is one small issue that needs to be fixed first. > > > > > > Unfortunately our HTTP stacks are reproducing apace, and > we already > > > have three separate stacks with large-scale code > duplication across > > > each :( This oviously needs to be fixed, and I've raised it > > on cxf-dev > > > & in JIRA, but in the meantime all changes to HTTP logic > need to be > > > duplicated across the http, http2 and javaws modules (in > the jaxws > > > case, it's the ServletDestination.java that you'll need > to update). > > > > > > Can you do this for your change to the reponse content-type > > handling > > > and re-submit the patch? > > > > > > Cheers, > > > Eoghan > > > > > > > -----Original Message----- > > > > From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] > > > > Sent: 01 February 2007 09:49 > > > > To: [email protected] > > > > Subject: Patch for JIRA > > > https://issues.apache.org/jira/browse/CXF-398 > > > > > > > > Hi > > > > > > > > Resending the message describibng the patch under the more > > > appropriate > > > > subject > > > > > > > > https://issues.apache.org/jira/browse/CXF-398 > > > > > > > > Summary of changes as listed in that Jira issue : > > > > > > > > * org.apache.cxf.binding.xml.XMLBindingFactory updated to add > > > > AttachmentInInterceptor to created bindings > > > > * org.apache.cxf.jaxws.ProviderChainObserver.onMessage() adds > > > > AttachmentInInterceptor unless Provider's type parameter is > > > DataSource > > > > or SourceMessage > > > > * org.apache.cxf.jaxws.support.ContextPropertiesMappping > > > > converts Message.getAttachments into Map<String, > > > DataHandler> as per > > > > JAXWS spec > > > > * org.apache.cxf.jaxws.interceptors.DispatchInInterceptor > > > > skips GET requets > > > > * org.apache.cxf.jaxws.interceptors.DispatchOutInterceptor > > > > closes DataSource input stream after copying the data to > > > output stream > > > > * org.apache.cxf.jaxws.transports.http.JettyHTTPDestination > > > > updated not to duplicate response Content-Type and honour > > > Content-Type > > > > property if set in Provider implementations > > > > * Updated org.apache.cxf.jaxb.io.XMLMessageDataReader to > > > try to read > > > > even if InputStream.available() shows 0, as it's not a reliable > > > > indication that the stream can not fetch more data > > > > > > > > Tests added > > > > > > > > More details can be found in the issue's comments > > > > > > > > Please apply the patch once it's evaluated > > > > > > > > Thanks, Sergey > > > > > > > > > >
