My biggest concern would be the “jar explosion” that would occur if you add a -blueprint and -spring jar for each of the jars that contains those. We already have a ton of jars, not sure adding another 30-40 is the best idea.
Several years ago, I also started experimenting a bit: https://github.com/apache/cxf/tree/split-spring <https://github.com/apache/cxf/tree/split-spring> But didn’t really pursue it much further. > On Sep 23, 2016, at 8:31 AM, Christian Schneider <[email protected]> > wrote: > > 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 > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > -- Daniel Kulp [email protected] <mailto:[email protected]> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://coders.talend.com <http://coders.talend.com/>
