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:dk...@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 > dk...@apache.org - http://dankulp.com/blog Talend Community Coder - > http://coders.talend.com
