cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject [Discuss] Move spring and blueprint support out of cxf-core
Date Fri, 23 Sep 2016 11:35:19 GMT

    Current state

Currently cxf-core has optional dependencies on several spring and 
blueprint modules. Especially the spring dependencies are quite problematic.


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 Schneider

Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message