cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: [Discuss] Move gzip feature to core
Date Mon, 30 Jan 2012 22:33:03 GMT
On 30/01/12 19:29, Daniel Kulp wrote:
> On Monday, January 30, 2012 11:56:06 AM Christian Schneider wrote:
>> We could of course also have a spearate module for gzip.
>> The reason why I think about moving it to core is that it just contains
>> 3 classes and does not have additional dependencies.
>> Basically I like the idea to separate modules on the architecture level.
>> On the runtime level I doubt though that any user would mind having
>> these classes
>> available every time.
>> About a prefix for the gzip classes. I also thought about what could be
>> suitable. Of course gzip is kind of on the transport level but it is no
>> transport. So perhaps it is a kind of a transformation or encoding.
> I really have some mixed opinions on this.    In "API" we have some similar
> features similar to the gzip feature that really could be grouped into this,
> but we have that split-package issue.   For example, the FastInfosetFeature
> kind of falls into the same basic idea and could likely be grouped into a
> separate "features" bundle, but because we stuck it in org.apache.cxf.feature,
> I have to leave it API.  :-(   (and the fact that the implementation of the
> feature lives in org.apache.cxf.interceptor, also in API)

One positive from dropping this module is that we will have 1 less 
module, and as Christian pointed out it won't affect users directly.
I guess it means the simpler config of features too...

Possible cons is that rt/core will start accumulating some more or less 
common transport-specific code - but may be indeed some more material is 
needed before getting a transport-specific module created for good...

Not sure :-). Whatever makes it better for 2.6 is good for me :-)

Cheers, Sergey

> Dan
>> Christian
>> Am 30.01.2012 11:43, schrieb Sergey Beryozkin:
>>> Hi Christian
>>> On 30/01/12 10:34, Christian Schneider wrote:
>>>> We currently have a transports/common project that only contains the
>>>> gzip feature.
>>>> As this feature is even used from core I propose we move it there and
>>>> remove the whole transports/common module.
>>> As far as I recall the gzip feature was in transports/http originally
>>> and then there was a demand for GZIP be supported at the JMS level...
>>> I proposed to move it to transports/common as opposed to rt/core, it
>>> does not seem to belong to the core really, as it's a very transport
>>> specific feature
>>>> I would like to change the package name from
>>>> org.apache.cxf.transport.common.gzip to org.apache.cxf.gzip. To remain
>>>> compatible I would leave a copy of the classes
>>>> in the old package with @Deprecated annotation.
>>> I'd still propose to scope 'gzip', may be not with 'common' but with
>>> something else
>>> Cheers, Sergey
>>>> Christian

View raw message