Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of eoghan.glynn@iona.com
 designates 62.221.12.33 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Patch for JIRA https://issues.apache.org/jira/browse/CXF-398
Date: Thu, 1 Feb 2007 16:44:02 -0000
Message-ID: <FA1787F64A095C4090E76EBAF8B183E071FBBF@owa-emea.iona.com>
Thread-Topic: Patch for JIRA https://issues.apache.org/jira/browse/CXF-398
Thread-Index: AcdGErbBTScQqUf/TUiRcUji05gtmQAATONgAADU3ZAAAjdVwA==
From: "Glynn, Eoghan" <eoghan.glynn@iona.com>
To: <cxf-dev@incubator.apache.org>


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]=20
> Sent: 01 February 2007 15:40
> To: cxf-dev@incubator.apache.org
> Subject: RE: Patch for JIRA=20
> https://issues.apache.org/jira/browse/CXF-398
>=20
>=20
> Sergey,
>=20
> I'm seeing the following failure against this patch.
>=20
> Ideas?
>=20
> /Eoghan
>=20
> [surefire]
> testRequestWithAttachment(org.apache.cxf.systest.provider.Atta
> chmentProv
> iderXMLClientServerTest)  Time elapsed: 0.275 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: No encoded attachment=20
> 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=20
> 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=20
> 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)
>=20
>=20
>=20
> Results :
> [surefire] Tests run: 1, Failures: 1, Errors: 0
> =20
>=20
> > -----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
> >=20
> >=20
> > Just doing a full test run on Linux against this patch, I'll commit=20
> > when this completes.
> >=20
> > Cheers,
> > Eoghan
> >=20
> > > -----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
> > >=20
> > > Hi Eoghan
> > >=20
> > > Thanks for the comments. Please find a second patch,=20
> > > https://issues.apache.org/jira/secure/attachment/12350140/rt_p
> > > rovider_attachment2.patch
> > >=20
> > > which includes these updates.
> > >=20
> > > On ServletDestination : in copyResponseHeaders() it also
> > deals with an
> > > optional charset value of the Content-Type header, but I haven't=20
> > > pushed that code into http and http2 codebase. I believe only the=20
> > > 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...
> > >=20
> > >=20
> > > Please let me know if you have any other suggestions/comments
> > >=20
> > > Cheers, Sergey
> > >=20
> > >=20
> > >=20
> > > Hi Sergey,
> > >=20
> > > I can apply this patch.
> > >=20
> > > However there is one small issue that needs to be fixed first.=20
> > >=20
> > > Unfortunately our HTTP stacks are reproducing apace, and=20
> we already=20
> > > have three separate stacks with large-scale code=20
> duplication across=20
> > > 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=20
> need to be=20
> > > duplicated across the http, http2 and javaws modules (in=20
> the jaxws=20
> > > case, it's the ServletDestination.java that you'll need=20
> to update).
> > >=20
> > > Can you do this for your change to the reponse content-type
> > handling
> > > and re-submit the patch?
> > >=20
> > > Cheers,
> > > Eoghan
> > >=20
> > > > -----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
> > > >=20
> > > > Hi
> > > >=20
> > > > Resending the message describibng the patch under the more
> > > appropriate
> > > > subject
> > > >=20
> > > > https://issues.apache.org/jira/browse/CXF-398
> > > >=20
> > > > Summary of changes as listed in that Jira issue :
> > > >=20
> > > > * org.apache.cxf.binding.xml.XMLBindingFactory updated to add=20
> > > > AttachmentInInterceptor to created bindings
> > > > * org.apache.cxf.jaxws.ProviderChainObserver.onMessage() adds=20
> > > > 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=20
> > > > indication that the stream can not fetch more data
> > > >=20
> > > > Tests added
> > > >=20
> > > > More details can be found in the issue's comments
> > > >=20
> > > > Please apply the patch once it's evaluated
> > > >=20
> > > > Thanks, Sergey
> > > >
> > >=20
> >=20
>=20