cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Patch for JIRA https://issues.apache.org/jira/browse/CXF-398
Date Thu, 01 Feb 2007 16:44:02 GMT

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:eoghan.glynn@iona.com] 
> Sent: 01 February 2007 15:40
> To: cxf-dev@incubator.apache.org
> 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:eoghan.glynn@iona.com]
> > Sent: 01 February 2007 15:18
> > To: cxf-dev@incubator.apache.org
> > 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:sergey.beryozkin@iona.com]
> > > Sent: 01 February 2007 15:09
> > > To: cxf-dev@incubator.apache.org
> > > 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:sergey.beryozkin@iona.com]
> > > > Sent: 01 February 2007 09:49
> > > > To: cxf-dev@incubator.apache.org
> > > > 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
> > > >
> > > 
> > 
> 

Mime
View raw message