cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Discuss] Move spring and blueprint support out of cxf-core
Date Fri, 30 Sep 2016 14:28:07 GMT
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 <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=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>

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