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

Reply via email to