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
