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 15:17:32 GMT

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