But DS provides no extension point and can't really be used to do pure dependency injection. I'd think CDI might be a better goal if we want to support a new framework.
Guillaume 2016-09-29 17:07 GMT+02:00 Benson Margulies <[email protected]>: > There's more to OSGi than Blueprint. I'd be very happy to use CXF with > DS and no blueprint. > > On Thu, Sep 29, 2016 at 8:13 AM, Andrei Shakirin <[email protected]> > wrote: > > Just more detail description: > > > > After removing the optional spring imports packages from CXF jars > Manifests, the users still can use CXF with Spring in Web, JEE and > standalone deployments, but not in OSGi with SpringDM. > > > > Removing can be done for example with maven bundle plugin instruction: > > <plugin> > > <groupId>org.apache.felix</groupId> > > <artifactId>maven-bundle-plugin</artifactId> > > <extensions>true</extensions> > > <configuration> > > <instructions> > > <Import-Package> > > !org.springframework*, > > * > > </Import-Package> > > </instructions> > > </configuration> > > </plugin> > > > > CXF reloading issue should be fixed with that. > > > > However the OSGi users using CXF in OSGi with SpringDM wouldn't be > supported anymore. > > > > WDYT? > > > > Regards, > > Andrei. > > > >> -----Original Message----- > >> From: Andrei Shakirin [mailto:[email protected]] > >> Sent: Freitag, 23. September 2016 18:09 > >> To: [email protected] > >> Subject: RE: [Discuss] Move spring and blueprint support out of cxf-core > >> > >> 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:[email protected]] On Behalf > >> > Of Christian Schneider > >> > Sent: Freitag, 23. September 2016 17:29 > >> > To: [email protected] > >> > 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 <chris@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 > >> > >>> <[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 > > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
