Yeah, I guess I was over-optimistic with my estimate though if we keep
Blueprint in then it may limit the explosion. Still a problem though.
Sergey
On 23/09/16 14: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:
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
