Hi Romain,
This is a good goal in general - but we can not solve it at the cost of
CXF Spring users and I'll be adamant they should not be affected.
But I do agree shipping Spring can make it difficult for non-Spring users.
Cristian indicated The SpringNS dependency can be resolved by the
introduction of -spring modules per every CXF module which has a Spring
NS. This is all right I guess. +6/8 simple lightweight modules. May be
we can keep Blueprint in just to minimize a number of new modules.
The common-util classes which can link to Spring would also need to be
moved to a dedicated common-util-spring.
Hmm, may be it will work out quite neatly after all.
Christian - thanks for starting looking at this tricky task :-)
Sergey
On 23/09/16 13:54, Romain Manni-Bucau wrote:
Hello guys,
not sure it "helps" but I'd really love to get rid of all spring facets
coming with CXF in tomee (we dont have spring and it makes user deployments
a bit complicated cause part of spring code/config is in the container and
other in the webapp). The proxying issue is also interesting since ATM we
hack ObjectHelper to handle CDI proxies.
In short a big +1 to clean that up if possible.
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 14:49 GMT+02:00 Sergey Beryozkin <[email protected]>:
FYI CXF core does also provide a Spring namespace.
As for a would be CXF 4.0 dropping Spring namespace completely - I think
we should not go there. Dropping it without really knowing much about what
users do will be a problem. Ex, FYI, few weeks back a CXF JAX-RS SpringBoot
user explained how they import many CXF Spring NS resources into SpringBoot
- which is course can be seen as an annotation-only preferred runtime.
I hear people saying 'WEB developers moved to JSON - no one needs XML',
with similar lines for SOAP and indeed OSGI. CXF needs to support various
combinations well, especially in cases where these combinations are already
in the production. Lots of CXF users with different requirements are around.
I'm sorry, not really sure what to discuss before a plan is presented.
Thanks, Sergey
On 23/09/16 13:31, 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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
