cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [Discuss] Move spring and blueprint support out of cxf-core
Date Fri, 23 Sep 2016 12:31:44 GMT
On 23.09.2016 14:03, Sergey Beryozkin wrote:
> IMHO the most important thing is to preserve the CXF stability.
> FYI, CommomUtil helpers which can use Spring are heavily used - some 
> of them in JAX-WS and a lot in JAX-RS.
> For example, JAX-RS SpringBoot starter does depend a lot on the 
> ClassScanner Spring, and JAX-RS runtime depends in various places on 
> ClassHelper to help with dealing with Spring proxified beans. The code 
> which refers to these helpers can not afford to start referring to 
> Spring variants because of course not all CXF users are Spring users.
> One needs to be aware that Spring (and now SpringBoot) is very much a 
> major platform for many CXF users.
We should definitely keep the good support for spring that we currently 
have. What I am not sure of is if we still need the pretty extensive xml 
namespaces in the future. The modern spring platform is now almost 
completely annotation based. So I can imagine that cxf 4 might drop xml 
namespaces in favor of comprehensive annotation based spring support.
> Personally I'd like see a very clear and concrete plan first:
> - How to preserve the runtime code portability which depends on 
> CommonUtil helpers such that it works as before in/out of Spring
I am not yet at the stage where I have a concrete plan. My first attempt 
was just to find out how deeply spring is wired into CXF. As it seems 
the unwrapping of proxies seems to be the most problematic part. So one 
first task is to find a good way to make this still work while having a 
separate module for the spring support.
> - How to keep CXF Spring user code which depends on Spring Namespace 
> support (starting from cxf:bus and then for all other modules) operating.
As a first step I would simply add the new cxf-core-spring jar to all 
modules that define namespaces. That might then not provide the full 
advantage of the separation but it should guarantee that all modules 
work as before. This change should make sure that refreshs only happen 
to modules that provide namespaces.
As a second step we should then check if we can improve on that. This 
all of course depends if we find a feasible solution and if the changes 
have the desired effect.
In any case I will make sure that we keep all problematic changes in a 
branch so we can decide about them before they reach the master.


Christian Schneider

Open Source Architect

View raw message