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 <[email protected]> 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 [[email protected]] on behalf of Christian > Schneider [[email protected]] > Sent: 10 May 2013 18:12 > To: [email protected] > 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
