cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: [Discuss] Move spring and blueprint support out of cxf-core
Date Fri, 23 Sep 2016 13:47:56 GMT
That would bring unwanted dependencies to either JAX-WS or JAX-RS 
frontends - example, JAX-WS Spring extends non-Spring JAX-WS. Etc

On 23/09/16 14:44, Romain Manni-Bucau wrote:
> 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 <> |  Blog
> <> | Old Wordpress Blog
> <> | Github <>
> LinkedIn <> | Tomitriber
> <> | JavaEE Factory
> <>
> 2016-09-23 15:38 GMT+02:00 Daniel Kulp <>:
>> 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:
>> <
>> But didn’t really pursue it much further.
>>> On Sep 23, 2016, at 8:31 AM, Christian Schneider <
>>> 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
>>> Open Source Architect
>> --
>> Daniel Kulp
>> <> - <
>> Talend Community Coder - <

Sergey Beryozkin

Talend Community Coders

View raw message