cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: [Discuss] Move spring and blueprint support out of cxf-core
Date Fri, 23 Sep 2016 12:03:42 GMT
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.

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
- How to keep CXF Spring user code which depends on Spring Namespace 
support (starting from cxf:bus and then for all other modules) operating.


On 23/09/16 12:35, Christian Schneider wrote:
>    Current state
> Currently cxf-core has optional dependencies on several spring and
> blueprint modules. Especially the spring dependencies are quite
> problematic.
>    Problem
> Since apache karaf 4 the feature service will refresh bundles if any of
> their optional dependencies become available or change. So for example
> if you first install the cxf features and then install or change any
> spring bundles then cxf-core will have to refresh. As all cxf modules
> and most user code that involves services depends on cxf-core this
> causes half the bundles in karaf to refresh and restart.
> As not all code is able to handle this situation this can lead to some
> bundles not starting correctly again or starting but not fully working.
>    Proposed Solution
> A solution could be to put the spring and blueprint dependent classes of
> cxf-core and potentially cxf-jaxws and cxf-jaxrs in separate bundles.
> Eventually we can keep the optional blueprint dependency as it is not
> very common that the blueprint bundles change at runtime.
> The result should be that there are less cases when all the bundles have
> to refresh. Especially if you do not use spring then refreshs should be
> quite rare after the change.
>    Proof of concept
> See the branch
> where I simply removed all spring and blueprint related classes. This at
> least allows to compile and test cxf-core. The other modules obviously
> will not work of course.
> What can be seen from the changes is that most spring and blueprint
> related classes are already in separate package which
> should make it relatively easy to move them into a spearate jar.
> The big notable exceptions are some classes in common.util. These would
> have to be moved. As the util classes should be internal to cxf I would
> not expect that many of our users would have changes in their own code.
> This small poc does not yet cover if we can make the extracted code work
> in its own bundle and if the result really helps much with the refreshs.
> Still I think it looks rather promising.
> Btw. I found another branch from Dan which is called split-spring which
> might have had a similar scope.
> I would be happy about any comments and feedback.
> Christian

Sergey Beryozkin

Talend Community Coders

View raw message