cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [Discuss] Move spring and blueprint support out of cxf-core
Date Fri, 23 Sep 2016 13:53:33 GMT
build time filtering? same amount of module physically in the source tree
but let say we have a module "jaxrs" then central would see:

- jaxrs (full)
- jaxrs-core (name is bad but you get it)
- jaxrs-spring
- jaxrs-blueprint

Did it for [jcs] jcache module to include or not cdi with success (from one
module i deploy the bundle, the cdi only part, the "not cdi" part)



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:47 GMT+02:00 Sergey Beryozkin <sberyozkin@gmail.com>:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message