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 https://github.com/apache/cxf/tree/poc-remove-spring-bp
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com