cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: Some minor (ok, not so minor) thoughts for CXF 3.0
Date Mon, 13 May 2013 09:00:43 GMT
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 <owulff@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


Mime
View raw message