I am still hoping for better CDI support in OSGi. So that would be really cool.
On the other hand I think DS can do the job in most cases. With CXF-DOSGi for services and JPATemplate or tx-control for db access DS is already quite usable in the enterprise space. I just did an OSGi training at a customer. We chose blueprint with the blueprint-maven-plugin as the customer already knows it but all the code we did would have worked with DS too. Christian 2016-09-29 17:10 GMT+02:00 Guillaume Nodet <[email protected]>: > 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/ > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
