Hi Christian, Regarding Karaf4 and OSGi: as Guillaume says the Spring DM isn't supported anymore. I am not sure how many users still use CXF + Spring in OSGi. Do you think it will be an option just to remove optional spring imports from the Manifest (for example using maven bundle plugin)?
Regards, Andrei. > -----Original Message----- > From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of > Christian Schneider > Sent: Freitag, 23. September 2016 17:29 > To: dev@cxf.apache.org > Subject: Re: [Discuss] Move spring and blueprint support out of cxf-core > > 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 <ch...@die-schneider.net>: > > > >> 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 > >>> <ch...@die-schneider.net> > >>>> 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
