Sergey,
I'm seeing the following failure against this patch.
Ideas?
/Eoghan
[surefire]
testRequestWithAttachment(org.apache.cxf.systest.provider.AttachmentProv
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.AttachmentProviderXMLClientServerTest.ve
rifyAttachment(AttachmentProviderXMLClientServerTest.java:118)
at
org.apache.cxf.systest.provider.AttachmentProviderXMLClientServerTest.te
stRequestWithAttachment(AttachmentProviderXMLClientServerTest.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
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(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery
.java:242)
at
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.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(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
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
> > >
> >
>
