Christian, I'll be happy to see DOSGI getting more attention but this
'simply use DOSGI' will simply not work - the flexibility of Blueprint
(and Spring in or outside of OSGI) is rated highly by the CXF users.
DOSGI has its niche but it has its limitations too.
Cheers, Sergey
On 30/09/16 12:59, Christian Schneider wrote:
Hi Benson,
DS and CXF already work quite well. Simply use CXF-DOSGi to expose and use
services.
The new samples in version 2.0 all use DS.
https://github.com/apache/cxf-dosgi/tree/master/samples
Honestly I think the blueprint / spring namespaces never were such a good
idea. They are much too intrusive.
I plan to point people to using DOSGi as the default way of using CXF in
OSGi.
Christian
2016-09-29 17:07 GMT+02:00 Benson Margulies <[email protected]>:
There's more to OSGi than Blueprint. I'd be very happy to use CXF with
DS and no blueprint.
On Thu, Sep 29, 2016 at 8:13 AM, Andrei Shakirin <[email protected]>
wrote:
Just more detail description:
After removing the optional spring imports packages from CXF jars
Manifests, the users still can use CXF with Spring in Web, JEE and
standalone deployments, but not in OSGi with SpringDM.
Removing can be done for example with maven bundle plugin instruction:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Import-Package>
!org.springframework*,
*
</Import-Package>
</instructions>
</configuration>
</plugin>
CXF reloading issue should be fixed with that.
However the OSGi users using CXF in OSGi with SpringDM wouldn't be
supported anymore.
WDYT?
Regards,
Andrei.
-----Original Message-----
From: Andrei Shakirin [mailto:[email protected]]
Sent: Freitag, 23. September 2016 18:09
To: [email protected]
Subject: RE: [Discuss] Move spring and blueprint support out of cxf-core
Hi Christian,
Regarding Karaf4 and OSGi: as Guillaume says the Spring DM isn't
supported
anymore.
I am not sure how many users still use CXF + Spring in OSGi.
Do you think it will be an option just to remove optional spring
imports from
the Manifest (for example using maven bundle plugin)?
Regards,
Andrei.
-----Original Message-----
From: Christian Schneider [mailto:[email protected]] On Behalf
Of Christian Schneider
Sent: Freitag, 23. September 2016 17:29
To: [email protected]
Subject: Re: [Discuss] Move spring and blueprint support out of
cxf-core
Hmm .. the dynamic imports would be worth a try. The namespaces might
work this way.
The focus is indeed mainly on spring though as blueprint is pre
installed most times and is only present in one version.
Christian
On 23.09.2016 16:38, Guillaume Nodet wrote:
I think we can solve the refresh problem from blueprint :
* remove the bundle activators that registers the blueprint
handlers
* create an extender which will scan for the blueprint.handlers
files in bundles and register the namespaces
* replace the cxf bundles Import-Package
org.apache.aries.blueprint.* and
org.osgi.service.blueprint.* packages with DynamicImport-Package(s)
I think this way, we should be able to deploy cxf-jaxws, then deploy
blueprint, and have blueprint namespaces available without having
any cxf bundle refreshed.
For spring, I'm not sure we can do the same. Though spring-dm is
not supported anymore, so I think at some point, we can safely not
support it anymore. It could be replaced by the spring-dm
compatible support from aries blueprint, in which case, we have a
bit more
room to hack there.
But even with plain spring-dm, the same idea as above should work,
as both spring-dm and the spring support in aries-blueprint do use
an extender and scan for META-INF/spring.handlers.
2016-09-23 16:11 GMT+02:00 Christian Schneider <chris@die-
schneider.net>:
I agree. I would not make sense to have that many additional jars.
On the other hand we could only create the extra modules for the
most important bundles like jaxrs, jaxws, http and http jetty.
These are the ones that people use a lot and that would cause most
of the
refreshs.
Honestly I think we have too many special namespaces anyway. So at
the start I would concentrate on the pain points above.
Another approach might be to have some generic support for
namespaces.
After all the namespaces represent configuration. We could define
the configuration in a neutral form (like pojos) and create the
xsds as well as the spring or blueprint namespace handler
registration centrally. Then there could be one module that
collects and registers the spring namespaces and another for the
blueprint ones. These modules would then also parse the user xml
and return the common pojos. The approach might be a bit difficult
to code but would save a lot of code in the individual modules. So
this is not something I would start
with but it could be a mid term goal.
Christian
On 23.09.2016 15:38, Daniel Kulp wrote:
My biggest concern would be the “jar explosion” that would occur
if you add a -blueprint and -spring jar for each of the jars that
contains
those.
We already have a ton of jars, not sure adding another 30-40 is
the best idea.
Several years ago, I also started experimenting a bit:
https://github.com/apache/cxf/tree/split-spring <
https://github.com/apache/cxf/tree/split-spring>
But didn’t really pursue it much further.
On Sep 23, 2016, at 8:31 AM, Christian Schneider
<[email protected]>
wrote:
On 23.09.2016 14:03, Sergey Beryozkin wrote:
IMHO the most important thing is to preserve the CXF stability.
FYI, CommomUtil helpers which can use Spring are heavily used -
some of them in JAX-WS and a lot in JAX-RS.
For example, JAX-RS SpringBoot starter does depend a lot on the
ClassScanner Spring, and JAX-RS runtime depends in various
places on ClassHelper to help with dealing with Spring
proxified beans.
The code which refers to these helpers can not afford to start
referring to Spring variants because of course not all CXF users
are
Spring users.
One needs to be aware that Spring (and now SpringBoot) is very
much a major platform for many CXF users.
We should definitely keep the good support for spring that we
currently have. What I am not sure of is if we still need the
pretty extensive xml namespaces in the future. The modern spring
platform is now almost completely annotation based. So I can
imagine that cxf 4 might drop xml namespaces in favor of
comprehensive
annotation based spring support.
Personally I'd like see a very clear and concrete plan first:
- How to preserve the runtime code portability which depends on
CommonUtil helpers such that it works as before in/out of Spring
I am not yet at the stage where I have a concrete plan. My first
attempt was just to find out how deeply spring is wired into CXF.
As it seems the unwrapping of proxies seems to be the most
problematic part. So one first task is to find a good way to make
this still work while having a separate module for the spring
support.
- How to keep CXF Spring user code which depends on Spring
Namespace support (starting from cxf:bus and then for all other
modules) operating.
As a first step I would simply add the new cxf-core-spring jar to
all modules that define namespaces. That might then not provide
the full advantage of the separation but it should guarantee that
all modules work as before. This change should make sure that
refreshs only happen to modules that provide namespaces.
As a second step we should then check if we can improve on that.
This all of course depends if we find a feasible solution and if
the changes have the desired effect.
In any case I will make sure that we keep all problematic changes
in a branch so we can decide about them before they reach the
master.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
