tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From EQd ninetyeight <eqd...@yahoo.com.INVALID>
Subject Re: JAX-WS supporting POSTs with "Content-Encoding: gzip"
Date Fri, 02 Jan 2015 23:32:14 GMT
If that can be ruled out then we're left with only a few likely contenders:CXF has a defect
with gzip that's undocumentedCXF is being prevented from fully functioningMy example project
is flawed
While the latter is by far the most probable, it's also the easiest to rule out.  
Maybe this is an academic discussion at this point: we've established gzip is 1 way only for
tomcat out of the box and there are 2-way servlet solutions available.  So from a practical
standpoint, there are easy pathways around this.  My only lingering question is if gzip doesn't
work, what else also might not.  Having an answer to gzip might help inform that wider question.
 But I can live with not knowing :)
      From: Romain Manni-Bucau <rmannibucau@gmail.com>
 To: EQd ninetyeight <eqd_98@yahoo.com> 
Cc: "users@tomee.apache.org" <users@tomee.apache.org> 
 Sent: Monday, December 29, 2014 3:09 AM
 Subject: Re: JAX-WS supporting POSTs with "Content-Encoding: gzip"
   
while it is a theory it is quite useless :(. You can proove or infirm
it trivially with a Filter. If the filter has the headers then cxf has
them.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau




2014-12-29 10:07 GMT+01:00 EQd ninetyeight <eqd_98@yahoo.com>:
> In looking around I'd seen previous mention, possibly from Apache Camel,
> where CXF didn't have access to the headers because they'd been stripped off
> lower down in the software stack.  That's certainly one possible/probable
> theory fitting the observable data points so far.
>
> I did test with larger payloads, so minimum thresholds shouldn't be a
> factor.  Also, for the inbound encoding (primarily what I was testing), the
> headers set by the client would need to be respected by the server
> regardless of payload size or it wouldn't really work.
>
> ________________________________
> From: Romain Manni-Bucau <rmannibucau@gmail.com>
> To: EQd ninetyeight <eqd_98@yahoo.com>
> Cc: "users@tomee.apache.org" <users@tomee.apache.org>
> Sent: Sunday, December 28, 2014 1:37 PM
>
> Subject: Re: JAX-WS supporting POSTs with "Content-Encoding: gzip"
>
> Well I dont see why cxf stuff wouldnt work.
>
> Are your messages payload < 1k? in such a case cxf (tomcat has a
> similar mecanism) skips gzip process.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
>
>
> 2014-12-27 1:47 GMT+01:00 EQd ninetyeight <eqd_98@yahoo.com>:
>> It seems the native Tomcat implementation is 1 way: server outbound only.
>> So there's no support for compressed HTTP requests.  Maybe that's not too
>> surprising considering the typical browser use case it was likely
>> developed
>> for (light upstream, heavy down).
>>
>> With some more investigation, I found it's both possible and pretty easy
>> to
>> add a 3rd party 2 way servlet filter into your project to support
>> symmetrical gzip, so that seems like the path of least resistance here.
>> The
>> other take away is that CXF within TomEE Plus likely doesn't see the HTTP
>> headers, so any functionality dependent on them probably won't work as
>> expected.
>>
>> Thanks,
>> Alex
>>
>> ________________________________
>> From: Romain Manni-Bucau <rmannibucau@gmail.com>
>> To: "users@tomee.apache.org" <users@tomee.apache.org>; EQd ninetyeight
>> <eqd_98@yahoo.com>
>> Sent: Friday, December 26, 2014 5:22 AM
>>
>> Subject: Re: JAX-WS supporting POSTs with "Content-Encoding: gzip"
>>
>> and keeping it in server.xml and ignoring any cxf config?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>>
>>
>> 2014-12-26 11:59 GMT+01:00 EQd ninetyeight <eqd_98@yahoo.com.invalid>:
>>> Ah that does change the landscape.  Removing the server.xml settings
>>> makes
>>> CXF reject gzip for both inbound and outbound.  Two scenarios come to
>>> mind:
>>> the Accept-Encoding and Content-Type headers get stripped before reaching
>>> CXF or the GZIP interceptors aren't really being added.  I'm not sure I
>>> know
>>> of a test that would differentiate between the two cases.
>>>      From: Romain Manni-Bucau <rmannibucau@gmail.com>
>>>  To: EQd ninetyeight <eqd_98@yahoo.com>; users@tomee.apache.org
>>>  Sent: Friday, December 26, 2014 12:23 AM
>>>  Subject: Re: JAX-WS supporting POSTs with "Content-Encoding: gzip"
>>>
>>> Hmm
>>>
>>> If you put it in server.xml, tomcat handles it and then cxf doesnt see
>>> gzip
>>> at all.
>>> Le 26 déc. 2014 03:00, "EQd ninetyeight" <eqd_98@yahoo.com.invalid> a
>>> écrit
>>>
>>>
>>> :
>>>
>>>> Hi Romain,
>>>>
>>>>
>>>> Thank you for the response and happy holidays!
>>>>
>>>>
>>>> It’s TomEE plus 1.7.1.  Packaging is a basic export to war from
>>>> theeclipse
>>>> project.  Here’s a simple serverproject that illustrates the exception
>>>> when
>>>> posting to the service with gzipcontent:
>>>>
>>>>
>>>> https://www.dropbox.com/s/9ufgu2w210jfbhv/gzip_test.zip?dl=0
>>>>
>>>>
>>>> The only configuration change to TomEE needed to run theproject is the
>>>> addition of compression settings in server.xml.  (Example within zip:
>>>> Catalina/conf/server.xml)
>>>>
>>>>
>>>> Also included is the war file and some SoapUI screen shots of
>>>> invokingthe
>>>> service with and without gzip enabled on the client.
>>>>
>>>>
>>>> I’m currently using SoapUI 5.0.0 as the client, but couldcreate a Java
>>>> SE
>>>> client project if that’s more useful.
>>>>
>>>> Thanks,
>>>>
>>>> Alex
>>>>
>>>>
>>>>      From: Romain Manni-Bucau <rmannibucau@gmail.com>
>>>>  To: EQd ninetyeight <eqd_98@yahoo.com>; users@tomee.apache.org
>>>>  Sent: Thursday, December 25, 2014 2:30 PM
>>>>  Subject: Re: JAX-WS supporting POSTs with "Content-Encoding: gzip"
>>>>
>>>> Hi
>>>>
>>>> openejbjar should work. What s your versions? How do you package? Any
>>>> sample - client and server - to let us check?
>>>> Le 25 déc. 2014 14:37, "EQd ninetyeight" <eqd_98@yahoo.com.invalid>
a
>>>> écrit
>>>>
>>>>
>>>> :
>>>>
>>>> > Hi,
>>>> > Configuring gzip compression for response messages seems
>>>> > straightforward:
>>>> > Annotating the @WebService endpoint with @GZIP and configuring
>>>> > server.xml
>>>> >
>>>> >    compression="on"    compressionMinSize="1"
>>>> compressableMimeType="text/html,text/xml,text/plain,text"
>>>> > I've had less luck with getting CXF to accept "Content-Encoding: gzip"
>>>> > POSTs (via SOAPUI).  CXF throws the "Couldn't parse stream."
>>>> > exception,
>>>> > suggestive that the GZIPInInterceptor isn't being invoked.
>>>> > It is expected that the @GZIP annotation should take care of
>>>> decompression
>>>> > of inbound requests to TomEE as well as outbound responses, or is
>>>> > there
>>>> > additional configuration necessary?
>>>> > I tried a couple of things but neither fixed it:
>>>> >
>>>> > 1) Added to the endpoint:@org.apache.cxf.interceptor.InInterceptors
>>>> > (interceptors =
>>>> {"org.apache.cxf.transport.common.gzip.GZIPInInterceptor"})
>>>> >
>>>> > 2) openejb-jar.xml:
>>>> > <openejb-jar xmlns="http://www.openejb.org/openejb-jar/1.1">
>>>> > <ejb-deployment ejb-name="DataPut">    <properties>
>>>> > cxf.jaxws.in-interceptors =
>>>> > org.apache.cxf.transport.common.gzip.GZIPInInterceptor
>>>> > </properties>
>>>> > </ejb-deployment></openejb-jar>
>>>> > Any pointers are much appreciated.
>>>> >
>>>> > Thanks,Alex
>>>> >
>>>>
>>>>
>>>
>>>
>>
>>
>
>

  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message