cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
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

Sergey
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 <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 <dkulp@apache.org>:
>
>> 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 <
>> chris@die-schneider.net> 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
>> dkulp@apache.org <mailto:dkulp@apache.org> - http://dankulp.com/blog <
>> http://dankulp.com/blog>
>> Talend Community Coder - http://coders.talend.com <
>> http://coders.talend.com/>
>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Mime
View raw message