cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: DOSGI JAX-RS and Gzip
Date Wed, 02 Jun 2010 17:26:38 GMT
Hi

On Tue, Jun 1, 2010 at 10:32 PM, kdog <jon_keep@koppedomain.com> wrote:

>
> Yeah, the gzip filter thing doesn't seem to work... Doesn't look like
> anything is in the response to gzip, so it probably wasn't intended for
> such
> a thing.
>
> As for the intent map, sounds promising. Docs on the intent-map are kind of
> sparse, so I didn't know what that was :) Anyway, it seems maybe I can use
> the existing GzipFeature... no? Just define it in my bundle's intent-map.
> Seems like that is how the "logging" intent is used anyway... I'll give it
> a
> shot tommorrow.
>
>
Going with a gzip intent would really be a DOSGI way - I think CXF DSW
should support it OTB; this would be especially handy if you were to use a
proxy-based api on the client side and a discovery service, which would
result in GZIP be supported seamlessly on the client side. That said, the
incoming 2.2.9 should have @Feature and @In/OutInterceptor annotations
supported for a jaxrs, a minor update was needed (thanks to Dan for helping
me to  apply it) - so you may want to try a multibundle DOSGI 1.1
distribution and replace CXF 2.2.5 (?) with CXF 2.2.9 once it is released.

Still thinking of making sure interceptors can also be registered as OSGI
services or through properties, not sure when I'll do it though

thanks, Sergey

Thanks again...
>
>
> Sergey Beryozkin-5 wrote:
> >
> > Hi
> >
> > I'm not sure it can help in your case, though may be it is worth trying.
> > Another thing you might want to experiment with is to try to define your
> > own
> > custom intent, 'GZIP' , please check the archives (I recall Eoghan Glynn
> > sending some feedback...)
> >
> > Sergey
> >
> > [1]
> >
> http://svn.apache.org/repos/asf/cxf/dosgi/trunk/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/SecurityDelegatingHttpContext.java
> >
> > On Tue, Jun 1, 2010 at 3:29 PM, kdog <jon_keep@koppedomain.com> wrote:
> >
> >>
> >> Actually, it looks like in 1.2 snapshot the ability to add custom
> servlet
> >> filters to your endpoints have been added
> >> (https://issues.apache.org/jira/browse/DOSGI-67). I will probably go
> this
> >> route for now. Thanks for your reply.
> >>
> >>
> >> Sergey Beryozkin-5 wrote:
> >> >
> >> > Looks like a blocker all right...
> >> > I'm not sure when DOSGI 1.2 is planned for, but if it will include
> >> 2.2.9
> >> > then I'll try to find some time and do some work around @Features...Or
> >> > perhaps another option is to introduce
> >> > org.apache.cxf.(rs).in(out).interceptor properties as well as support
> >> the
> >> > explicit registration of CXF interceptors from custom bundles.
> >> > Any help with implementing either of the above will be appreciated
> >> given
> >> > my
> >> > time is limited now...
> >> >
> >> > cheers, Sergey
> >> >
> >> > On Wed, May 26, 2010 at 3:13 PM, kdog <jon_keep@koppedomain.com>
> wrote:
> >> >
> >> >>
> >> >> So I have a requirement to Gzip the response from a JAX-RS request
in
> >> >> DOSGI.
> >> >> I noticed that there are GZIP features and GZIP interceptors, but I
> >> don't
> >> >> know how to apply this a DOSGI JAX-RS service endpoint. I have tried
> >> the
> >> >> @Features annotation, but this only seems to apply to soap web
> >> services
> >> >> (jaxws).
> >> >> --
> >> >> View this message in context:
> >> >> http://old.nabble.com/DOSGI-JAX-RS-and-Gzip-tp28681367p28681367.html
> >> >> Sent from the cxf-user mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://old.nabble.com/DOSGI-JAX-RS-and-Gzip-tp28681367p28742677.html
> >>  Sent from the cxf-user mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/DOSGI-JAX-RS-and-Gzip-tp28681367p28747712.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>

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