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 > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
