cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [Discuss] Move spring and blueprint support out of cxf-core
Date Fri, 23 Sep 2016 14:11:45 GMT
I agree. I would not make sense to have that many additional jars.  On 
the other hand we could only create the extra modules for the most 
important bundles like jaxrs, jaxws, http and http jetty. These are the 
ones that people use a lot and that would cause most of the refreshs.

Honestly I think we have too many special namespaces anyway.  So at the 
start I would concentrate on the pain points above.

Another approach might be to have some generic support for namespaces. 
After all the namespaces represent configuration. We could define the 
configuration in a neutral form (like pojos) and create the xsds as well 
as the spring or blueprint namespace handler registration centrally. 
Then there could be one module that collects and registers the spring 
namespaces and another for the blueprint ones. These modules would then 
also parse the user xml and return the common pojos. The approach might 
be a bit difficult to code but would save a lot of code in the 
individual modules. So this is not something I would start with but it 
could be a mid term goal.


On 23.09.2016 15:38, Daniel Kulp wrote:
> 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 <>
>> 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

Christian Schneider

Open Source Architect

View raw message