Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of owulff@talend.com designates
 64.95.72.252 as permitted sender)
From: Oliver Wulff <owulff@talend.com>
To: "dev@cxf.apache.org" <dev@cxf.apache.org>
Subject: RE: Some minor (ok, not so minor) thoughts for CXF 3.0
Thread-Topic: Some minor (ok, not so minor) thoughts for CXF 3.0
Thread-Index: AQHOS1E5MZAXPw+rzkuFD+2gS6xWYpj+3qOAgAMlTsk=
Date: Sun, 12 May 2013 20:17:12 +0000
Message-ID: <79AB4452999C844D9920E036353327311133A9AC@S10BE002.SH10.lan>
References: 
 <D87DD826-91A1-48FF-8D34-46B23CF6F076@apache.org>,<518D1C53.8050902@die-schneider.net>
In-Reply-To: <518D1C53.8050902@die-schneider.net>
Accept-Language: en-GB, de-DE, en-US
Content-Language: en-GB
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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, wit=
h the refactorings in the 2.4 timeframe, we made everything extend the Exte=
nsionMangerBus.  Thus, CXFBusImpl is pretty much not needed.   I'd like to =
push whatever is left there into ExtensionMangerBus and remove a level of t=
he hierarchy. (alternatively, push the stuff in ExtensionMangerBus down int=
o CXFBusImpl).   Thoughts?
>
> 2) Interceptor ->  PhaseInterceptor and InterceptorChain -> PhaseIntercep=
torChain
> We originally (in 2005) thought about having the interceptor be more inde=
pendent of the phases.  However, that never really worked and pretty much a=
ll interceptors used in CXF have to be of the PhaseInterceptor variety.   A=
dditionally, the only "chain" we've had is the PhaseInterceptorChain.   Alm=
ost all the interfaces use "Interceptor<=85>" or "InterceptorChain".   Thus=
, I'd like to just push everything down into Interceptor/InterceptorChain a=
nd get rid of the others to remove that level and reduce  confusion so peop=
le 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 t=
he ?js stuff)   Would simplify the CXFServlet a bit.
>
> 4) Merge "PropertiesAwareDatabinding"  into DataBinding.   The "propertie=
s aware" version was introduced just to be able to add a method without bre=
aking binary compatibility.  Might as well push it in now.
>
> 5) BaseDataReader/DataReader and the same for the writer.   Not really su=
re why they are separated but EVERYTHING uses just "DataReader".     Get ri=
d of BaseData*.
>
> 6) Remove all the "WSDL" based things from cxf-api and cxf-rt-core.   I n=
eed 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 b=
ase for everything that is WSDL related.   That would leave api/core free o=
f WSDL stuff to make the JAX-RS stuff lighter.   Either that or create a ne=
w bundle that would live between rt-core and rt-frontent-simple and the wsd=
l 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 p=
robably 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 p=
eoples thoughts on any of it.     Mostly just trying to simplify a few thin=
gs, clarify things, remove/move some deps around.
>
>


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com=