why not having a cxf-spring, cxf-blueprint etc... with everything? Shouldnt be a big deal to activate the integration only if classes are there no?
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-09-23 15:38 GMT+02:00 Daniel Kulp <[email protected]>: > 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/> >
