cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [Discuss] Move spring and blueprint support out of cxf-core
Date Fri, 30 Sep 2016 15:56:21 GMT
2016-09-30 16:28 GMT+02:00 Christian Schneider <chris@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 <sberyozkin@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 <bimargulies@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
> >>>>>>>>> <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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>> 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message