You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2016/09/23 11:35:19 UTC
[Discuss] Move spring and blueprint support out of cxf-core
Current state
Currently cxf-core has optional dependencies on several spring and
blueprint modules. Especially the spring dependencies are quite problematic.
Problem
Since apache karaf 4 the feature service will refresh bundles if any of
their optional dependencies become available or change. So for example
if you first install the cxf features and then install or change any
spring bundles then cxf-core will have to refresh. As all cxf modules
and most user code that involves services depends on cxf-core this
causes half the bundles in karaf to refresh and restart.
As not all code is able to handle this situation this can lead to some
bundles not starting correctly again or starting but not fully working.
Proposed Solution
A solution could be to put the spring and blueprint dependent classes of
cxf-core and potentially cxf-jaxws and cxf-jaxrs in separate bundles.
Eventually we can keep the optional blueprint dependency as it is not
very common that the blueprint bundles change at runtime.
The result should be that there are less cases when all the bundles have
to refresh. Especially if you do not use spring then refreshs should be
quite rare after the change.
Proof of concept
See the branch https://github.com/apache/cxf/tree/poc-remove-spring-bp
where I simply removed all spring and blueprint related classes. This at
least allows to compile and test cxf-core. The other modules obviously
will not work of course.
What can be seen from the changes is that most spring and blueprint
related classes are already in separate package which
should make it relatively easy to move them into a spearate jar.
The big notable exceptions are some classes in common.util. These would
have to be moved. As the util classes should be internal to cxf I would
not expect that many of our users would have changes in their own code.
This small poc does not yet cover if we can make the extracted code work
in its own bundle and if the result really helps much with the refreshs.
Still I think it looks rather promising.
Btw. I found another branch from Dan which is called split-spring which
might have had a similar scope.
I would be happy about any comments and feedback.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <gn...@apache.org>:
> 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 <bi...@gmail.com>:
>
> > 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 <as...@talend.com>
> > 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:ashakirin@talend.com]
> > >> Sent: Freitag, 23. September 2016 18:09
> > >> To: dev@cxf.apache.org
> > >> 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:cschneider111@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 <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
> > >> > >>> <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
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> 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>
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Guillaume Nodet <gn...@apache.org>.
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 <bi...@gmail.com>:
> 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 <as...@talend.com>
> 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:ashakirin@talend.com]
> >> Sent: Freitag, 23. September 2016 18:09
> >> To: dev@cxf.apache.org
> >> 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:cschneider111@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 <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
> >> > >>> <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
> >
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Christian
I will support whole-heartedly your effort :-). I haven't been
contributing but I'll try to give it a try and find some time later on
to tweak some JAX-RS code, etc;
What I'm trying to say is that users can be quite sensitive to some
changes. But having the alternatives usually works well. +1 to getting
DOSGI to the next level,
Sergey
On 30/09/16 15:28, Christian Schneider wrote:
> 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.
>
> Christian
>
>
> 2016-09-30 14:51 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
>
>> 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 <bi...@gmail.com>:
>>>
>>> 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 <as...@talend.com>
>>>> 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:ashakirin@talend.com]
>>>>>> Sent: Freitag, 23. September 2016 18:09
>>>>>> To: dev@cxf.apache.org
>>>>>> 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:cschneider111@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 <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 \u201cjar explosion\u201d 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\u2019t 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Christian Schneider <ch...@die-schneider.net>.
On 30.09.2016 17:56, Guillaume Nodet wrote:
> 2016-09-30 16:28 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>
>> 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 ?
Exactly. This is why I want to make sure we support it. It will help
other platforms too
and also help people who want to provide specific tooling for a platform.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Guillaume Nodet <gn...@apache.org>.
2016-09-30 16:28 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> 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 <sb...@gmail.com>:
>
> > 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 <bi...@gmail.com>:
> >>
> >> 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 <ashakirin@talend.com
> >
> >>> 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:ashakirin@talend.com]
> >>>>> Sent: Freitag, 23. September 2016 18:09
> >>>>> To: dev@cxf.apache.org
> >>>>> 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:cschneider111@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 <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
> >>>>>>>>> <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
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
>
>
> --
> --
> 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: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Christian Schneider <ch...@die-schneider.net>.
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.
Christian
2016-09-30 14:51 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
> 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 <bi...@gmail.com>:
>>
>> 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 <as...@talend.com>
>>> 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:ashakirin@talend.com]
>>>>> Sent: Freitag, 23. September 2016 18:09
>>>>> To: dev@cxf.apache.org
>>>>> 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:cschneider111@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 <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
>>>>>>>>> <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
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
--
--
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>
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <bi...@gmail.com>:
>
>> 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 <as...@talend.com>
>> 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:ashakirin@talend.com]
>>>> Sent: Freitag, 23. September 2016 18:09
>>>> To: dev@cxf.apache.org
>>>> 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:cschneider111@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 <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 \u201cjar explosion\u201d 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\u2019t 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
>>>
>>
>
>
>
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <bi...@gmail.com>:
> 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 <as...@talend.com>
> 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:ashakirin@talend.com]
> >> Sent: Freitag, 23. September 2016 18:09
> >> To: dev@cxf.apache.org
> >> 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:cschneider111@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 <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
> >> > >>> <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
> >
>
--
--
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>
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Benson Margulies <bi...@gmail.com>.
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 <as...@talend.com> 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:ashakirin@talend.com]
>> Sent: Freitag, 23. September 2016 18:09
>> To: dev@cxf.apache.org
>> 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:cschneider111@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 <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
>> > >>> <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
>
RE: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Andrei Shakirin <as...@talend.com>.
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:ashakirin@talend.com]
> Sent: Freitag, 23. September 2016 18:09
> To: dev@cxf.apache.org
> 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:cschneider111@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 <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
> > >>> <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
RE: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Andrei Shakirin <as...@talend.com>.
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:cschneider111@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
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Christian Schneider <ch...@die-schneider.net>.
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 \u201cjar explosion\u201d 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\u2019t 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
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Guillaume Nodet <gn...@apache.org>.
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
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by 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 \u201cjar explosion\u201d 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\u2019t 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
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
build time filtering? same amount of module physically in the source tree
but let say we have a module "jaxrs" then central would see:
- jaxrs (full)
- jaxrs-core (name is bad but you get it)
- jaxrs-spring
- jaxrs-blueprint
Did it for [jcs] jcache module to include or not cdi with success (from one
module i deploy the bundle, the cdi only part, the "not cdi" part)
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-23 15:47 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
> That would bring unwanted dependencies to either JAX-WS or JAX-RS
> frontends - example, JAX-WS Spring extends non-Spring JAX-WS. Etc
>
> Sergey
> On 23/09/16 14:44, Romain Manni-Bucau wrote:
>
>> why not having a cxf-spring, cxf-blueprint etc... with everything?
>> Shouldnt
>> be a big deal to activate the integration only if classes are there no?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2016-09-23 15:38 GMT+02:00 Daniel Kulp <dk...@apache.org>:
>>
>> 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 <
>>>>
>>> chris@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
>>>>
>>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <
>>> http://dankulp.com/blog>
>>> Talend Community Coder - http://coders.talend.com <
>>> http://coders.talend.com/>
>>>
>>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Sergey Beryozkin <sb...@gmail.com>.
That would bring unwanted dependencies to either JAX-WS or JAX-RS
frontends - example, JAX-WS Spring extends non-Spring JAX-WS. Etc
Sergey
On 23/09/16 14:44, Romain Manni-Bucau wrote:
> why not having a cxf-spring, cxf-blueprint etc... with everything? Shouldnt
> be a big deal to activate the integration only if classes are there no?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-09-23 15:38 GMT+02:00 Daniel Kulp <dk...@apache.org>:
>
>> My biggest concern would be the \u201cjar explosion\u201d 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\u2019t really pursue it much further.
>>
>>
>>
>>
>>> On Sep 23, 2016, at 8:31 AM, Christian Schneider <
>> chris@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
>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <
>> http://dankulp.com/blog>
>> Talend Community Coder - http://coders.talend.com <
>> http://coders.talend.com/>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
why not having a cxf-spring, cxf-blueprint etc... with everything? Shouldnt
be a big deal to activate the integration only if classes are there no?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-23 15:38 GMT+02:00 Daniel Kulp <dk...@apache.org>:
> 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 <
> chris@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
> >
>
> --
> Daniel Kulp
> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://coders.talend.com <
> http://coders.talend.com/>
>
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Sergey Beryozkin <sb...@gmail.com>.
Yeah, I guess I was over-optimistic with my estimate though if we keep
Blueprint in then it may limit the explosion. Still a problem though.
Sergey
On 23/09/16 14:38, Daniel Kulp wrote:
> My biggest concern would be the \u201cjar explosion\u201d 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\u2019t 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
>>
>
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Daniel Kulp <dk...@apache.org>.
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
>
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://coders.talend.com <http://coders.talend.com/>
Re: TomEE CDI and CXF CDI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
We have ATM a tomee "service" doing that and registering a filter for
JAX-RS (to allow to serve plain web resources which was a common error of
users). Having a CDI solution is not an option ATM since we have to work
when CDI is not activated. We can surely check if we can merge more code
but we actually have a light integration, the code mainly only create a
server factory and read our specific configuration and then we delegate in
the filter.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-23 15:41 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
> Hi Christian
>
> FYI, Andriy Redko contributed a lot and later John Ament contributed too
> to the CXF CDI module - but it is very much JAX-RS centric right now.
> Perhaps some of that code can be extracted to help a JAX-WS case too - we
> talked awhile back about supporting both frontends
>
> Sergey
>
>
>
>
> On 23/09/16 14:36, Christian Schneider wrote:
>
>> I also think is would be great to have the CDI support directly in cxf
>> as a portable extension. It could then also be reused in pax-cdi for
>> OSGi and also for standalone CDI cases.
>>
>> Christian
>>
>> On 23.09.2016 15:33, Sergey Beryozkin wrote:
>>
>>> Hi Romain
>>>
>>> What do you think of trying to utilize CXF CDI code for the purpose of
>>> supporting CXF CDI services in TomEE ?
>>>
>>> You mentioned you had to hack ObjectHelper in TomEE so I guess CXF CDI
>>> code 'missed out' :-). We have some CDI experts here on the list so
>>> may be it can make sense...
>>>
>>> Thanks, Sergey
>>>
>>
>>
>>
>
Re: TomEE CDI and CXF CDI
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Christian
FYI, Andriy Redko contributed a lot and later John Ament contributed too
to the CXF CDI module - but it is very much JAX-RS centric right now.
Perhaps some of that code can be extracted to help a JAX-WS case too -
we talked awhile back about supporting both frontends
Sergey
On 23/09/16 14:36, Christian Schneider wrote:
> I also think is would be great to have the CDI support directly in cxf
> as a portable extension. It could then also be reused in pax-cdi for
> OSGi and also for standalone CDI cases.
>
> Christian
>
> On 23.09.2016 15:33, Sergey Beryozkin wrote:
>> Hi Romain
>>
>> What do you think of trying to utilize CXF CDI code for the purpose of
>> supporting CXF CDI services in TomEE ?
>>
>> You mentioned you had to hack ObjectHelper in TomEE so I guess CXF CDI
>> code 'missed out' :-). We have some CDI experts here on the list so
>> may be it can make sense...
>>
>> Thanks, Sergey
>
>
Re: TomEE CDI and CXF CDI
Posted by Christian Schneider <ch...@die-schneider.net>.
I also think is would be great to have the CDI support directly in cxf
as a portable extension. It could then also be reused in pax-cdi for
OSGi and also for standalone CDI cases.
Christian
On 23.09.2016 15:33, Sergey Beryozkin wrote:
> Hi Romain
>
> What do you think of trying to utilize CXF CDI code for the purpose of
> supporting CXF CDI services in TomEE ?
>
> You mentioned you had to hack ObjectHelper in TomEE so I guess CXF CDI
> code 'missed out' :-). We have some CDI experts here on the list so
> may be it can make sense...
>
> Thanks, Sergey
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
TomEE CDI and CXF CDI
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Romain
What do you think of trying to utilize CXF CDI code for the purpose of
supporting CXF CDI services in TomEE ?
You mentioned you had to hack ObjectHelper in TomEE so I guess CXF CDI
code 'missed out' :-). We have some CDI experts here on the list so may
be it can make sense...
Thanks, Sergey
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Romain,
This is a good goal in general - but we can not solve it at the cost of
CXF Spring users and I'll be adamant they should not be affected.
But I do agree shipping Spring can make it difficult for non-Spring users.
Cristian indicated The SpringNS dependency can be resolved by the
introduction of -spring modules per every CXF module which has a Spring
NS. This is all right I guess. +6/8 simple lightweight modules. May be
we can keep Blueprint in just to minimize a number of new modules.
The common-util classes which can link to Spring would also need to be
moved to a dedicated common-util-spring.
Hmm, may be it will work out quite neatly after all.
Christian - thanks for starting looking at this tricky task :-)
Sergey
On 23/09/16 13:54, Romain Manni-Bucau wrote:
> Hello guys,
>
> not sure it "helps" but I'd really love to get rid of all spring facets
> coming with CXF in tomee (we dont have spring and it makes user deployments
> a bit complicated cause part of spring code/config is in the container and
> other in the webapp). The proxying issue is also interesting since ATM we
> hack ObjectHelper to handle CDI proxies.
>
> In short a big +1 to clean that up if possible.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-09-23 14:49 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
>
>> FYI CXF core does also provide a Spring namespace.
>>
>> As for a would be CXF 4.0 dropping Spring namespace completely - I think
>> we should not go there. Dropping it without really knowing much about what
>> users do will be a problem. Ex, FYI, few weeks back a CXF JAX-RS SpringBoot
>> user explained how they import many CXF Spring NS resources into SpringBoot
>> - which is course can be seen as an annotation-only preferred runtime.
>>
>> I hear people saying 'WEB developers moved to JSON - no one needs XML',
>> with similar lines for SOAP and indeed OSGI. CXF needs to support various
>> combinations well, especially in cases where these combinations are already
>> in the production. Lots of CXF users with different requirements are around.
>>
>> I'm sorry, not really sure what to discuss before a plan is presented.
>>
>> Thanks, Sergey
>>
>>
>>
>>
>> On 23/09/16 13:31, Christian Schneider 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
>>>
>>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hello guys,
not sure it "helps" but I'd really love to get rid of all spring facets
coming with CXF in tomee (we dont have spring and it makes user deployments
a bit complicated cause part of spring code/config is in the container and
other in the webapp). The proxying issue is also interesting since ATM we
hack ObjectHelper to handle CDI proxies.
In short a big +1 to clean that up if possible.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-23 14:49 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
> FYI CXF core does also provide a Spring namespace.
>
> As for a would be CXF 4.0 dropping Spring namespace completely - I think
> we should not go there. Dropping it without really knowing much about what
> users do will be a problem. Ex, FYI, few weeks back a CXF JAX-RS SpringBoot
> user explained how they import many CXF Spring NS resources into SpringBoot
> - which is course can be seen as an annotation-only preferred runtime.
>
> I hear people saying 'WEB developers moved to JSON - no one needs XML',
> with similar lines for SOAP and indeed OSGI. CXF needs to support various
> combinations well, especially in cases where these combinations are already
> in the production. Lots of CXF users with different requirements are around.
>
> I'm sorry, not really sure what to discuss before a plan is presented.
>
> Thanks, Sergey
>
>
>
>
> On 23/09/16 13:31, Christian Schneider 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
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Sergey Beryozkin <sb...@gmail.com>.
FYI CXF core does also provide a Spring namespace.
As for a would be CXF 4.0 dropping Spring namespace completely - I think
we should not go there. Dropping it without really knowing much about
what users do will be a problem. Ex, FYI, few weeks back a CXF JAX-RS
SpringBoot user explained how they import many CXF Spring NS resources
into SpringBoot - which is course can be seen as an annotation-only
preferred runtime.
I hear people saying 'WEB developers moved to JSON - no one needs XML',
with similar lines for SOAP and indeed OSGI. CXF needs to support
various combinations well, especially in cases where these combinations
are already in the production. Lots of CXF users with different
requirements are around.
I'm sorry, not really sure what to discuss before a plan is presented.
Thanks, Sergey
On 23/09/16 13:31, Christian Schneider 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
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: [Discuss] Move spring and blueprint support out of cxf-core
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
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
- How to keep CXF Spring user code which depends on Spring Namespace
support (starting from cxf:bus and then for all other modules) operating.
Sergey
On 23/09/16 12:35, Christian Schneider wrote:
>
> Current state
>
> Currently cxf-core has optional dependencies on several spring and
> blueprint modules. Especially the spring dependencies are quite
> problematic.
>
>
> Problem
>
> Since apache karaf 4 the feature service will refresh bundles if any of
> their optional dependencies become available or change. So for example
> if you first install the cxf features and then install or change any
> spring bundles then cxf-core will have to refresh. As all cxf modules
> and most user code that involves services depends on cxf-core this
> causes half the bundles in karaf to refresh and restart.
>
> As not all code is able to handle this situation this can lead to some
> bundles not starting correctly again or starting but not fully working.
>
>
> Proposed Solution
>
> A solution could be to put the spring and blueprint dependent classes of
> cxf-core and potentially cxf-jaxws and cxf-jaxrs in separate bundles.
> Eventually we can keep the optional blueprint dependency as it is not
> very common that the blueprint bundles change at runtime.
>
> The result should be that there are less cases when all the bundles have
> to refresh. Especially if you do not use spring then refreshs should be
> quite rare after the change.
>
>
> Proof of concept
>
> See the branch https://github.com/apache/cxf/tree/poc-remove-spring-bp
> where I simply removed all spring and blueprint related classes. This at
> least allows to compile and test cxf-core. The other modules obviously
> will not work of course.
> What can be seen from the changes is that most spring and blueprint
> related classes are already in separate package which
> should make it relatively easy to move them into a spearate jar.
> The big notable exceptions are some classes in common.util. These would
> have to be moved. As the util classes should be internal to cxf I would
> not expect that many of our users would have changes in their own code.
> This small poc does not yet cover if we can make the extracted code work
> in its own bundle and if the result really helps much with the refreshs.
> Still I think it looks rather promising.
>
> Btw. I found another branch from Dan which is called split-spring which
> might have had a similar scope.
>
> I would be happy about any comments and feedback.
>
> Christian
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/