2016-09-30 16:28 GMT+02:00 Christian Schneider <[email protected]>:
> I hope we can get DOSGi on the same level as CXF + blueprint. Basically we > just need to make sure we provide a programmatic way to configure all > aspects of CXF (e.g. using Features). The big advantage is that this will > bring first class CXF support to all other platforms too. > > So my first goal is to get the most important CXF features configureable. I > think with CXF DOSGi 2 we should already cover the need of most users. > Maybe not yet as convenient as possible but at least possible. > Having a programmatic way to configure CXF is not really specific to DOSGi, is it ? > > Christian > > > 2016-09-30 14:51 GMT+02:00 Sergey Beryozkin <[email protected]>: > > > Christian, I'll be happy to see DOSGI getting more attention but this > > 'simply use DOSGI' will simply not work - the flexibility of Blueprint > (and > > Spring in or outside of OSGI) is rated highly by the CXF users. > > DOSGI has its niche but it has its limitations too. > > > > Cheers, Sergey > > > > > > > > > > On 30/09/16 12:59, Christian Schneider wrote: > > > >> Hi Benson, > >> > >> DS and CXF already work quite well. Simply use CXF-DOSGi to expose and > use > >> services. > >> The new samples in version 2.0 all use DS. > >> > >> https://github.com/apache/cxf-dosgi/tree/master/samples > >> > >> Honestly I think the blueprint / spring namespaces never were such a > good > >> idea. They are much too intrusive. > >> I plan to point people to using DOSGi as the default way of using CXF in > >> OSGi. > >> > >> Christian > >> > >> > >> > >> 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 > >>>>>> > >>>>> > >>>> > >>> > >> > >> > >> > > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e > 46&URL=http%3a%2f%2fwww.liquid-reality.de> > > Open Source Architect > http://www.talend.com > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e > 46&URL=http%3a%2f%2fwww.talend.com> > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
