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 >
