cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Shakirin <ashaki...@talend.com>
Subject RE: Some minor (ok, not so minor) thoughts for CXF 3.0
Date Fri, 10 May 2013 15:44:19 GMT
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


Mime
View raw message