You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2013/05/07 20:31:28 UTC
Some minor (ok, not so minor) thoughts for CXF 3.0
I'd like to do a couple refactoring things for 3.0 to simplify the class structure a little bit:
1) Bus -> CXFBusImpl -> ExtensionManagerBus -> Spring/BlueprintBus
We originally had Spring and Blueprint subclass CXFBusImpl. However, with the refactorings in the 2.4 timeframe, we made everything extend the ExtensionMangerBus. Thus, CXFBusImpl is pretty much not needed. I'd like to push whatever is left there into ExtensionMangerBus and remove a level of the hierarchy. (alternatively, push the stuff in ExtensionMangerBus down into CXFBusImpl). Thoughts?
2) Interceptor -> PhaseInterceptor and InterceptorChain -> PhaseInterceptorChain
We originally (in 2005) thought about having the interceptor be more independent of the phases. However, that never really worked and pretty much all interceptors used in CXF have to be of the PhaseInterceptor variety. Additionally, the only "chain" we've had is the PhaseInterceptorChain. Almost all the interfaces use "Interceptor<…>" or "InterceptorChain". Thus, I'd like to just push everything down into Interceptor/InterceptorChain and get rid of the others to remove that level and reduce confusion so people know there needs to be a phase there.
3) QueryHandlers -> these were originally used for the ?wsdl processing (and is still used for ?js). However, that stuff is better done directly on the interceptor chains as interceptors to allow user supplied interceptors to also handle them. I'd like to just remove these. (obviously update the ?js stuff) Would simplify the CXFServlet a bit.
4) Merge "PropertiesAwareDatabinding" into DataBinding. The "properties aware" version was introduced just to be able to add a method without breaking binary compatibility. Might as well push it in now.
5) BaseDataReader/DataReader and the same for the writer. Not really sure why they are separated but EVERYTHING uses just "DataReader". Get rid of BaseData*.
6) Remove all the "WSDL" based things from cxf-api and cxf-rt-core. I need to play with this more. Likely rename cxf-rt-frontend-simple to cxf-rt-frontend-wsdl (or similar) and move all of it there as that would be the base for everything that is WSDL related. That would leave api/core free of WSDL stuff to make the JAX-RS stuff lighter. Either that or create a new bundle that would live between rt-core and rt-frontent-simple and the wsdl based bindings/technologies. Likewise, find a way for transports (like http) to not need any WSDL things. This will likely also require some of the interceptors in org.apache.cxf.interceptor to move a bit, but that's probably a good thing as there is too much stuff in there that should be in more specific sub packages or something.
Obviously a lot of that has some compatibility impact, user impact, etc..., but that's why I think doing it for 3.0 is the best option. I'd love peoples thoughts on any of it. Mostly just trying to simplify a few things, clarify things, remove/move some deps around.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Some minor (ok, not so minor) thoughts for CXF 3.0
Posted by Łukasz Dywicki <lu...@code-house.org>.
If we are talking about CXF 3.0 I would like to put something from me. I would love to see some changes in messaging layer as well. The current exchange/message model used by CXF is fine, however I think there are some fields where it might be improved.
For example - support for multipart messages should be built-in into messaging layer - where we could perform operations like [message instanceof MultiPartMessage] to verify if the body of message is List of objects.
Another layer is exchange properties vs message headers - if both could be closed in one interface then processing of both could be done with one code lets say.
Another idea is "chaining" of messages. When CXF receives HTTP message it gets TCP/IP frame with HTTP headers and payload. Then CXF gets HTTP payload and unmarshal it to SOAP headers/message parts. HTTP headers should not be available in SOAP message and vice versa. These should be separated and used at certain moment where they're needed. Of course from developer perspective both headers should be available somehow in every moment of processing. I know this might be done with CXF 2.x, however I would love to see clean API for that. :) Can you imagine PhaseInterceptor<HttpMessage> automatically put and called before PhaseInterceptor<SOAPMessage> ?
Cheers,
Lukasz
Wiadomość napisana przez Oliver Wulff <ow...@talend.com> w dniu 12 maj 2013, o godz. 22:17:
> I think we should also clean up the security code (saml, role, claims) for jax-ws, jax-rs and sts. Probably, move the SAML-P code to fediz.
>
> Oli
> ________________________________________
> From: Christian Schneider [cschneider111@gmail.com] on behalf of Christian Schneider [chris@die-schneider.net]
> Sent: 10 May 2013 18:12
> To: dev@cxf.apache.org
> Subject: Re: Some minor (ok, not so minor) thoughts for CXF 3.0
>
> +1 for all of your points.
>
> We should also take a look at the classes that we pulled into api to
> remove the split package problem in OSGi.
> 3.0 would be a good time to move some of these to a better place. Not
> sure about the effect on compatibility though.
>
> Christian
>
> On 07.05.2013 20:31, Daniel Kulp wrote:
>> I'd like to do a couple refactoring things for 3.0 to simplify the class structure a little bit:
>>
>> 1) Bus -> CXFBusImpl -> ExtensionManagerBus -> Spring/BlueprintBus
>> We originally had Spring and Blueprint subclass CXFBusImpl. However, with the refactorings in the 2.4 timeframe, we made everything extend the ExtensionMangerBus. Thus, CXFBusImpl is pretty much not needed. I'd like to push whatever is left there into ExtensionMangerBus and remove a level of the hierarchy. (alternatively, push the stuff in ExtensionMangerBus down into CXFBusImpl). Thoughts?
>>
>> 2) Interceptor -> PhaseInterceptor and InterceptorChain -> PhaseInterceptorChain
>> We originally (in 2005) thought about having the interceptor be more independent of the phases. However, that never really worked and pretty much all interceptors used in CXF have to be of the PhaseInterceptor variety. Additionally, the only "chain" we've had is the PhaseInterceptorChain. Almost all the interfaces use "Interceptor<…>" or "InterceptorChain". Thus, I'd like to just push everything down into Interceptor/InterceptorChain and get rid of the others to remove that level and reduce confusion so people know there needs to be a phase there.
>>
>> 3) QueryHandlers -> these were originally used for the ?wsdl processing (and is still used for ?js). However, that stuff is better done directly on the interceptor chains as interceptors to allow user supplied interceptors to also handle them. I'd like to just remove these. (obviously update the ?js stuff) Would simplify the CXFServlet a bit.
>>
>> 4) Merge "PropertiesAwareDatabinding" into DataBinding. The "properties aware" version was introduced just to be able to add a method without breaking binary compatibility. Might as well push it in now.
>>
>> 5) BaseDataReader/DataReader and the same for the writer. Not really sure why they are separated but EVERYTHING uses just "DataReader". Get rid of BaseData*.
>>
>> 6) Remove all the "WSDL" based things from cxf-api and cxf-rt-core. I need to play with this more. Likely rename cxf-rt-frontend-simple to cxf-rt-frontend-wsdl (or similar) and move all of it there as that would be the base for everything that is WSDL related. That would leave api/core free of WSDL stuff to make the JAX-RS stuff lighter. Either that or create a new bundle that would live between rt-core and rt-frontent-simple and the wsdl based bindings/technologies. Likewise, find a way for transports (like http) to not need any WSDL things. This will likely also require some of the interceptors in org.apache.cxf.interceptor to move a bit, but that's probably a good thing as there is too much stuff in there that should be in more specific sub packages or something.
>>
>>
>> Obviously a lot of that has some compatibility impact, user impact, etc..., but that's why I think doing it for 3.0 is the best option. I'd love peoples thoughts on any of it. Mostly just trying to simplify a few things, clarify things, remove/move some deps around.
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
RE: Some minor (ok, not so minor) thoughts for CXF 3.0
Posted by Oliver Wulff <ow...@talend.com>.
I think we should also clean up the security code (saml, role, claims) for jax-ws, jax-rs and sts. Probably, move the SAML-P code to fediz.
Oli
________________________________________
From: Christian Schneider [cschneider111@gmail.com] on behalf of Christian Schneider [chris@die-schneider.net]
Sent: 10 May 2013 18:12
To: dev@cxf.apache.org
Subject: Re: Some minor (ok, not so minor) thoughts for CXF 3.0
+1 for all of your points.
We should also take a look at the classes that we pulled into api to
remove the split package problem in OSGi.
3.0 would be a good time to move some of these to a better place. Not
sure about the effect on compatibility though.
Christian
On 07.05.2013 20:31, Daniel Kulp wrote:
> I'd like to do a couple refactoring things for 3.0 to simplify the class structure a little bit:
>
> 1) Bus -> CXFBusImpl -> ExtensionManagerBus -> Spring/BlueprintBus
> We originally had Spring and Blueprint subclass CXFBusImpl. However, with the refactorings in the 2.4 timeframe, we made everything extend the ExtensionMangerBus. Thus, CXFBusImpl is pretty much not needed. I'd like to push whatever is left there into ExtensionMangerBus and remove a level of the hierarchy. (alternatively, push the stuff in ExtensionMangerBus down into CXFBusImpl). Thoughts?
>
> 2) Interceptor -> PhaseInterceptor and InterceptorChain -> PhaseInterceptorChain
> We originally (in 2005) thought about having the interceptor be more independent of the phases. However, that never really worked and pretty much all interceptors used in CXF have to be of the PhaseInterceptor variety. Additionally, the only "chain" we've had is the PhaseInterceptorChain. Almost all the interfaces use "Interceptor<…>" or "InterceptorChain". Thus, I'd like to just push everything down into Interceptor/InterceptorChain and get rid of the others to remove that level and reduce confusion so people know there needs to be a phase there.
>
> 3) QueryHandlers -> these were originally used for the ?wsdl processing (and is still used for ?js). However, that stuff is better done directly on the interceptor chains as interceptors to allow user supplied interceptors to also handle them. I'd like to just remove these. (obviously update the ?js stuff) Would simplify the CXFServlet a bit.
>
> 4) Merge "PropertiesAwareDatabinding" into DataBinding. The "properties aware" version was introduced just to be able to add a method without breaking binary compatibility. Might as well push it in now.
>
> 5) BaseDataReader/DataReader and the same for the writer. Not really sure why they are separated but EVERYTHING uses just "DataReader". Get rid of BaseData*.
>
> 6) Remove all the "WSDL" based things from cxf-api and cxf-rt-core. I need to play with this more. Likely rename cxf-rt-frontend-simple to cxf-rt-frontend-wsdl (or similar) and move all of it there as that would be the base for everything that is WSDL related. That would leave api/core free of WSDL stuff to make the JAX-RS stuff lighter. Either that or create a new bundle that would live between rt-core and rt-frontent-simple and the wsdl based bindings/technologies. Likewise, find a way for transports (like http) to not need any WSDL things. This will likely also require some of the interceptors in org.apache.cxf.interceptor to move a bit, but that's probably a good thing as there is too much stuff in there that should be in more specific sub packages or something.
>
>
> Obviously a lot of that has some compatibility impact, user impact, etc..., but that's why I think doing it for 3.0 is the best option. I'd love peoples thoughts on any of it. Mostly just trying to simplify a few things, clarify things, remove/move some deps around.
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Some minor (ok, not so minor) thoughts for CXF 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
+1 for all of your points.
We should also take a look at the classes that we pulled into api to
remove the split package problem in OSGi.
3.0 would be a good time to move some of these to a better place. Not
sure about the effect on compatibility though.
Christian
On 07.05.2013 20:31, Daniel Kulp wrote:
> I'd like to do a couple refactoring things for 3.0 to simplify the class structure a little bit:
>
> 1) Bus -> CXFBusImpl -> ExtensionManagerBus -> Spring/BlueprintBus
> We originally had Spring and Blueprint subclass CXFBusImpl. However, with the refactorings in the 2.4 timeframe, we made everything extend the ExtensionMangerBus. Thus, CXFBusImpl is pretty much not needed. I'd like to push whatever is left there into ExtensionMangerBus and remove a level of the hierarchy. (alternatively, push the stuff in ExtensionMangerBus down into CXFBusImpl). Thoughts?
>
> 2) Interceptor -> PhaseInterceptor and InterceptorChain -> PhaseInterceptorChain
> We originally (in 2005) thought about having the interceptor be more independent of the phases. However, that never really worked and pretty much all interceptors used in CXF have to be of the PhaseInterceptor variety. Additionally, the only "chain" we've had is the PhaseInterceptorChain. Almost all the interfaces use "Interceptor<…>" or "InterceptorChain". Thus, I'd like to just push everything down into Interceptor/InterceptorChain and get rid of the others to remove that level and reduce confusion so people know there needs to be a phase there.
>
> 3) QueryHandlers -> these were originally used for the ?wsdl processing (and is still used for ?js). However, that stuff is better done directly on the interceptor chains as interceptors to allow user supplied interceptors to also handle them. I'd like to just remove these. (obviously update the ?js stuff) Would simplify the CXFServlet a bit.
>
> 4) Merge "PropertiesAwareDatabinding" into DataBinding. The "properties aware" version was introduced just to be able to add a method without breaking binary compatibility. Might as well push it in now.
>
> 5) BaseDataReader/DataReader and the same for the writer. Not really sure why they are separated but EVERYTHING uses just "DataReader". Get rid of BaseData*.
>
> 6) Remove all the "WSDL" based things from cxf-api and cxf-rt-core. I need to play with this more. Likely rename cxf-rt-frontend-simple to cxf-rt-frontend-wsdl (or similar) and move all of it there as that would be the base for everything that is WSDL related. That would leave api/core free of WSDL stuff to make the JAX-RS stuff lighter. Either that or create a new bundle that would live between rt-core and rt-frontent-simple and the wsdl based bindings/technologies. Likewise, find a way for transports (like http) to not need any WSDL things. This will likely also require some of the interceptors in org.apache.cxf.interceptor to move a bit, but that's probably a good thing as there is too much stuff in there that should be in more specific sub packages or something.
>
>
> Obviously a lot of that has some compatibility impact, user impact, etc..., but that's why I think doing it for 3.0 is the best option. I'd love peoples thoughts on any of it. Mostly just trying to simplify a few things, clarify things, remove/move some deps around.
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
RE: Some minor (ok, not so minor) thoughts for CXF 3.0
Posted by Andrei Shakirin <as...@talend.com>.
Hi Dan,
Definitely +1 for (1), (2), (3), (4), (5).
Regarding (6): +1 for wsdl; I would also suggest to review some other stuff in cxf-api (like StaxTranformFeature and LoggingFeature) that IMO not really belongs to api.
Regards,
Andrei.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Dienstag, 7. Mai 2013 20:31
> To: dev@cxf.apache.org
> Subject: Some minor (ok, not so minor) thoughts for CXF 3.0
>
>
> I'd like to do a couple refactoring things for 3.0 to simplify the class structure a
> little bit:
>
> 1) Bus -> CXFBusImpl -> ExtensionManagerBus -> Spring/BlueprintBus
> We originally had Spring and Blueprint subclass CXFBusImpl. However, with
> the refactorings in the 2.4 timeframe, we made everything extend the
> ExtensionMangerBus. Thus, CXFBusImpl is pretty much not needed. I'd like
> to push whatever is left there into ExtensionMangerBus and remove a level
> of the hierarchy. (alternatively, push the stuff in ExtensionMangerBus down
> into CXFBusImpl). Thoughts?
>
> 2) Interceptor -> PhaseInterceptor and InterceptorChain ->
> PhaseInterceptorChain
> We originally (in 2005) thought about having the interceptor be more
> independent of the phases. However, that never really worked and pretty
> much all interceptors used in CXF have to be of the PhaseInterceptor variety.
> Additionally, the only "chain" we've had is the PhaseInterceptorChain.
> Almost all the interfaces use "Interceptor<...>" or "InterceptorChain". Thus,
> I'd like to just push everything down into Interceptor/InterceptorChain and
> get rid of the others to remove that level and reduce confusion so people
> know there needs to be a phase there.
>
> 3) QueryHandlers -> these were originally used for the ?wsdl processing (and
> is still used for ?js). However, that stuff is better done directly on the
> interceptor chains as interceptors to allow user supplied interceptors to also
> handle them. I'd like to just remove these. (obviously update the ?js stuff)
> Would simplify the CXFServlet a bit.
>
> 4) Merge "PropertiesAwareDatabinding" into DataBinding. The "properties
> aware" version was introduced just to be able to add a method without
> breaking binary compatibility. Might as well push it in now.
>
> 5) BaseDataReader/DataReader and the same for the writer. Not really sure
> why they are separated but EVERYTHING uses just "DataReader". Get rid
> of BaseData*.
>
> 6) Remove all the "WSDL" based things from cxf-api and cxf-rt-core. I need
> to play with this more. Likely rename cxf-rt-frontend-simple to cxf-rt-
> frontend-wsdl (or similar) and move all of it there as that would be the base
> for everything that is WSDL related. That would leave api/core free of WSDL
> stuff to make the JAX-RS stuff lighter. Either that or create a new bundle
> that would live between rt-core and rt-frontent-simple and the wsdl based
> bindings/technologies. Likewise, find a way for transports (like http) to not
> need any WSDL things. This will likely also require some of the interceptors
> in org.apache.cxf.interceptor to move a bit, but that's probably a good thing
> as there is too much stuff in there that should be in more specific sub
> packages or something.
>
>
> Obviously a lot of that has some compatibility impact, user impact, etc..., but
> that's why I think doing it for 3.0 is the best option. I'd love peoples thoughts
> on any of it. Mostly just trying to simplify a few things, clarify things,
> remove/move some deps around.
>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com
Re: Some minor (ok, not so minor) thoughts for CXF 3.0
Posted by Alessio Soldano <as...@redhat.com>.
Fine with me.
I agree on all points; I'm not really sure of the actual impact of 6,
but 3.0 is definitely the proper time for doing this ;-)
Alessio
On 05/07/2013 08:31 PM, Daniel Kulp wrote:
>
> I'd like to do a couple refactoring things for 3.0 to simplify the class structure a little bit:
>
> 1) Bus -> CXFBusImpl -> ExtensionManagerBus -> Spring/BlueprintBus
> We originally had Spring and Blueprint subclass CXFBusImpl. However, with the refactorings in the 2.4 timeframe, we made everything extend the ExtensionMangerBus. Thus, CXFBusImpl is pretty much not needed. I'd like to push whatever is left there into ExtensionMangerBus and remove a level of the hierarchy. (alternatively, push the stuff in ExtensionMangerBus down into CXFBusImpl). Thoughts?
>
> 2) Interceptor -> PhaseInterceptor and InterceptorChain -> PhaseInterceptorChain
> We originally (in 2005) thought about having the interceptor be more independent of the phases. However, that never really worked and pretty much all interceptors used in CXF have to be of the PhaseInterceptor variety. Additionally, the only "chain" we've had is the PhaseInterceptorChain. Almost all the interfaces use "Interceptor<…>" or "InterceptorChain". Thus, I'd like to just push everything down into Interceptor/InterceptorChain and get rid of the others to remove that level and reduce confusion so people know there needs to be a phase there.
>
> 3) QueryHandlers -> these were originally used for the ?wsdl processing (and is still used for ?js). However, that stuff is better done directly on the interceptor chains as interceptors to allow user supplied interceptors to also handle them. I'd like to just remove these. (obviously update the ?js stuff) Would simplify the CXFServlet a bit.
>
> 4) Merge "PropertiesAwareDatabinding" into DataBinding. The "properties aware" version was introduced just to be able to add a method without breaking binary compatibility. Might as well push it in now.
>
> 5) BaseDataReader/DataReader and the same for the writer. Not really sure why they are separated but EVERYTHING uses just "DataReader". Get rid of BaseData*.
>
> 6) Remove all the "WSDL" based things from cxf-api and cxf-rt-core. I need to play with this more. Likely rename cxf-rt-frontend-simple to cxf-rt-frontend-wsdl (or similar) and move all of it there as that would be the base for everything that is WSDL related. That would leave api/core free of WSDL stuff to make the JAX-RS stuff lighter. Either that or create a new bundle that would live between rt-core and rt-frontent-simple and the wsdl based bindings/technologies. Likewise, find a way for transports (like http) to not need any WSDL things. This will likely also require some of the interceptors in org.apache.cxf.interceptor to move a bit, but that's probably a good thing as there is too much stuff in there that should be in more specific sub packages or something.
>
>
> Obviously a lot of that has some compatibility impact, user impact, etc..., but that's why I think doing it for 3.0 is the best option. I'd love peoples thoughts on any of it. Mostly just trying to simplify a few things, clarify things, remove/move some deps around.
>
>
--
Alessio Soldano
Web Service Lead, JBoss