cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: [Discuss] Move spring and blueprint support out of cxf-core
Date Fri, 30 Sep 2016 14:54:22 GMT
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 <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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>


Mime
View raw message