Hmm .. the dynamic imports would be worth a try. The namespaces might
work this way.
The focus is indeed mainly on spring though as blueprint is pre
installed most times and is only present in one version.
Christian
On 23.09.2016 16:38, Guillaume Nodet wrote:
I think we can solve the refresh problem from blueprint :
* remove the bundle activators that registers the blueprint handlers
* create an extender which will scan for the blueprint.handlers files in
bundles and register the namespaces
* replace the cxf bundles Import-Package org.apache.aries.blueprint.* and
org.osgi.service.blueprint.* packages with DynamicImport-Package(s)
I think this way, we should be able to deploy cxf-jaxws, then deploy
blueprint, and have blueprint namespaces available without having any cxf
bundle refreshed.
For spring, I'm not sure we can do the same. Though spring-dm is not
supported anymore, so I think at some point, we can safely not support it
anymore. It could be replaced by the spring-dm compatible support from
aries blueprint, in which case, we have a bit more room to hack there.
But even with plain spring-dm, the same idea as above should work, as both
spring-dm and the spring support in aries-blueprint do use an extender and
scan for META-INF/spring.handlers.
2016-09-23 16:11 GMT+02:00 Christian Schneider <[email protected]>:
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.
Christian
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:
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
