You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2012/01/30 11:34:25 UTC
[Discuss] Move gzip feature to core
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.
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.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [Discuss] Move gzip feature to core
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, January 31, 2012 8:07:34 AM Christian Schneider wrote:
> I think I will move it to core for now but not yet change the package name.
> So we stay compatible and still have one less module. For 3.0 I plan to
> move many of the Features to a new position.
> We can then decide how to group them into jars.
>
> For compatibility and the architecture the package name is more
> important than the jar anyway. A good design of the packages will allow
> us the freedom to arrrange them into jars as we need. So we should
> discuss that soon to make a good decision for 3.0.
Can you add this idea to the list at:
http://cxf.apache.org/docs/30-migration-guide.html
That list is now a bit out of date. Was able to accomplish much of it for
2.6. :-)
Dan
>
> What is already really good with the gzip feature is that feature and
> interceptors are in the same package. I will try to do that for all
> features.
> Currently many of the basic features are in the feature package while
> their interceptors are in the interceptor package. This is not so good
> as it does not allow
> us to move them anywhere without breaking compatiblity or having split
> packages.
>
> Christian
>
> Am 30.01.2012 23:33, schrieb Sergey Beryozkin:
> > Hi
> >
> > 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
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [Discuss] Move gzip feature to core
Posted by Christian Schneider <ch...@die-schneider.net>.
I think I will move it to core for now but not yet change the package name.
So we stay compatible and still have one less module. For 3.0 I plan to
move many of the Features to a new position.
We can then decide how to group them into jars.
For compatibility and the architecture the package name is more
important than the jar anyway. A good design of the packages will allow
us the freedom to arrrange them into jars as we need. So we should
discuss that soon to make a good decision for 3.0.
What is already really good with the gzip feature is that feature and
interceptors are in the same package. I will try to do that for all
features.
Currently many of the basic features are in the feature package while
their interceptors are in the interceptor package. This is not so good
as it does not allow
us to move them anywhere without breaking compatiblity or having split
packages.
Christian
Am 30.01.2012 23:33, schrieb Sergey Beryozkin:
> Hi
> 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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [Discuss] Move gzip feature to core
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
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
Re: [Discuss] Move gzip feature to core
Posted by Daniel Kulp <dk...@apache.org>.
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)
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
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [Discuss] Move gzip feature to core
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 30/01/12 10:56, Christian Schneider wrote:
> We could of course also have a spearate module for gzip.
At a time we talked about moving some more HTTP-centric interceptors
from rt/core to transports/common, may be fastinfoset ones.
Dan may have more ideas, I recall him referring to this common module.
> The reason why I think about moving it to core is that it just contains
> 3 classes and does not have additional dependencies.
I've just moved a cors code from the jaxrs module, it does have 3
classes at the moment only but it does not quite belong to the main
jaxrs module.
rt/core can become quite lumpy, not a big issue probably...
>
> 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.
>
'encoding' or 'common.encoding' sounds good to me
thanks, Sergey
> 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
>>>
>
>
Re: [Discuss] Move gzip feature to core
Posted by Christian Schneider <ch...@die-schneider.net>.
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.
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
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [Discuss] Move gzip feature to core
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>