Raffaele:
I am successfully using Apache CXF with OSGI enRoute. To get this to work,
I’ve created a number of bundles, as follows:
com.xyz.domain.soap.client.api - api for client applications to bootstrap a CXF
connection to service
com.xyz.domain.soap.client.command - command line, for testing, etc
com.xyz.domain.soap.client.provider - code for creating CXF service connections
com.xyz.domain.soap.server.provider - code for providing service implementation
com.xyz.domain.soap.common.shared.api - Just the endpoint definitions that both
client and service must agree upon
com.xyz.domain.soap.common.shared.provider - WSDL files, with maven pom.xml to
auto-generate skeletons to put into com.xyz.domain.soap.server.provider
It may seem like a lot of work, but it’s logical and quite easy… once you get
the bnd and pom.xml files working properly. But once working, you only need to
edit your wsdl files and everything else ‘just works’. Just plug in the client
bundles into your client applications and invoke Java APIs to call your
services. Your service skeletons are auto-generated, you only need to fill in
the empty skeleton methods with your custom code.
The bnd file for the three provider projects contains the following CXF
references:
org.apache.cxf.cxf-core,\
org.apache.cxf.cxf-rt-frontend-jaxws,\
org.apache.cxf.cxf-rt-frontend-simple,\
org.apache.cxf.cxf-rt-transports-http,\
Your pom.xml file in the common.shared.provider file looks like the attached,
and is only used by Eclipse to auto-generate code in response to wsdl file
modifications; it does not replace bndtools for building your OSGI applications.
<project xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
<modelVersion>4.0.0</modelVersion>
<groupId>com.paymentfabric.masterdata.party</groupId>
<artifactId>com.paymentfabric.masterdata.party.soap.shared.provider</artifactId>
<version>1.0.0-SNAPSHOT</version>
<parent>
<groupId>com.paymentfabric.masterdata</groupId>
<artifactId>com.paymentfabric.masterdata</artifactId>
<version>1.0.0-SNAPSHOT</version>
<relativePath>../com.paymentfabric.masterdata</relativePath>
</parent>
<properties>
<src.dir>src</src.dir>
</properties>
<build>
<sourceDirectory>${src.dir}</sourceDirectory>
<testSourceDirectory>test</testSourceDirectory>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<groupId>biz.aQute.bnd</groupId>
<artifactId>bnd-maven-plugin</artifactId>
<version>3.3.0</version>
<executions>
<execution>
<id>default-bnd-process</id>
<goals>
<goal>bnd-process</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<useDefaultManifestFile>true</useDefaultManifestFile>
</configuration>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>CXF</id>
<!-- To use Metro by default, move activation element
to its profile below -->
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>3.1.7</version>
<executions>
<execution>
<configuration>
<sourceRoot>
${basedir}/src
</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>
${basedir}/OSGI-INF/IdentityProviderService.wsdl
</wsdl>
<extraargs>
<!-- extraarg>-impl</extraarg -->
<extraarg>-xjc-npa</extraarg>
<!-- extraarg>-xjc-nv</extraarg -->
<extraarg>-nexclude</extraarg>
<extraarg>http://v1_0_0.datatypes.provider.soap.foundation.paymentfabric.com</extraarg>
</extraargs>
</wsdlOption>
<wsdlOption>
<wsdl>
${basedir}/OSGI-INF/InvolvedPartyService.wsdl
</wsdl>
<extraargs>
<!-- extraarg>-impl</extraarg -->
<extraarg>-xjc-npa</extraarg>
<!-- extraarg>-xjc-nv</extraarg -->
<extraarg>-nexclude</extraarg>
<extraarg>http://v1_0_0.datatypes.provider.soap.foundation.paymentfabric.com</extraarg>
</extraargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.11.0</version>
</dependency>
<dependency>
<groupId>org.apache.cxf.xjcplugins</groupId>
<artifactId>cxf-xjc-ts</artifactId>
<version>3.0.5</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-tools-wsdlto-core</artifactId>
<version>3.1.7</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<dependencies>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.annotation</artifactId>
<version>6.0.0</version>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.service.component.annotations</artifactId>
<version>1.3.0</version>
</dependency>
<dependency>
<groupId>com.paymentfabric.foundation</groupId>
<artifactId>com.paymentfabric.foundation.soap.provider</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.paymentfabric.masterdata.party</groupId>
<artifactId>com.paymentfabric.masterdata.party.soap.shared.api</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
———
There’s a bit more to this, but I am unfortunately traveling today. Send me a
note if you want to explore this further, and I’ll do a complete writeup over
the weekend on how to get this working.
Randy
> On Jun 23, 2017, at 8:39 AM, Raffaele Gambelli
> <[email protected]> wrote:
>
> Hy Christian and thanks for your patient reply.
>
> I've discarded Karaf because of you said it could be too long, I tried with
> DOSGI but onfortunately there is not a DOSGI version with cxf 3.0.6 which is
> the version used anywhere in my Equinox env.
> So I've downloaded 3.0.6 distribution and I took needed bundles, either cxf
> or its dependencies, in this way now I have 7 bundles:
> cxf-core-3.0.6
> cxf-rt-bindings-soap-3.0.6
> cxf-rt-frontend-simple-3.0.6
> cxf-rt-transports-http-3.0.6
> cxf-rt-wsdl-3.0.6
> org.apache.servicemix.bundles.wsdl4j-1.6.3_1
> xmlschema-core-2.2.1
>
> All those are being resolved as showed in felix console, so their
> dependencies are fully satisfied.
>
> Now when I start equinox I have the following error, which is raised from
> another component which it is one of those which embeds cxf in its ambedded
> artifacts:
> 2017.06.23 16:05:58.953 - - - - 127.0.0.1 - *ERROR* [Start Level: Equinox
> Container: c0ad8de7-1c58-0017-1552-eca72b0e1610] ContextLoader: Context
> initialization failed (log in Jdk14Logger.java, line 101)
> java.lang.IllegalAccessError: tried to access class
> org.apache.cxf.BusFactory$BusHolder from class org.apache.cxf.BusFactory
> at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:124)
> ~[cxf-core-3.0.6.jar:3.0.6]
> at
> org.apache.cxf.BusFactory.possiblySetDefaultBus(BusFactory.java:284)
> ~[cxf-core-3.0.6.jar:3.0.6]
> at
> org.apache.cxf.bus.extension.ExtensionManagerBus.<init>(ExtensionManagerBus.java:111)
> ~[cxf-core-3.0.6.jar:3.0.6]
> at
> org.apache.cxf.bus.extension.ExtensionManagerBus.<init>(ExtensionManagerBus.java:191)
> ~[cxf-core-3.0.6.jar:3.0.6]
> at org.apache.cxf.bus.spring.SpringBus.<init>(SpringBus.java:45)
> ~[cxf-core-3.0.6.jar:3.0.6]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) ~[na:1.8.0_121]
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> ~[na:1.8.0_121]
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> ~[na:1.8.0_121]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> ~[na:1.8.0_121]
> at
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:147)
> ~[org.apache.servicemix.bundles.spring-beans-4.2.5.RELEASE_1.jar:na]
> ... 52 common frames omitted
>
> I'm asking if after having added cxf bundle, I should remove all embedded cxf
> from all bundles ?
>
> Thanks again, bye
>
> Raffaele Gambelli
>
>
>
> [email protected] ha scritto: -----
> Per: "[email protected]" <[email protected]>
> Da: Christian Schneider
> Inviato da: [email protected]
> Data: 23/06/2017 10.46AM
> Oggetto: Re: OSGI bundle, best practices
>
> CXF-DOSGi provides a way to create cxf clients and endpoints from OSGi
> services. It might be quite useful for the case you are describing.
> You can also use CXF without DOSGi. CXF provides all jars as bundles.
> Installing it is mainly installing the right bundles and tuning some few
> system package exports.
>
> There is no single bundle that provides all the functionality of CXF. We
> had this in the past but it had lots of drawbacks. Especially as it defeats
> the whole idea of modularity.
>
> So the biggest challenges in using CXF in OSGi is how to install it
> correctly. There are three ways to do this:
> 1. Use Apache karaf. We have CXF features for karaf that allow to install
> CXF easily. This might not be an option for you short term as switching to
> karaf would be a bigger task.
> 2. Use the multi bundle distro of CXF-DOSGi. In this distro there are the
> bundles you need to install into your OSGi framework. This is quite error
> prone though.
> 3. Use bndtools and the bnd resolver to build your system.
>
> For 3 there is an example in the CXF-DOSGi code:
> https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndrun
> Basically you define the -runrequires as a set of top level bundles to
> install and let the resolver figure out the dependencies.
> This requires to have a repository of bundles to choose from. We provide
> this for CXF-DOSGi here:
> https://github.com/apache/cxf-dosgi/tree/master/samples/repository
> https://github.com/apache/cxf-dosgi/tree/master/distribution/repository
>
> I am not sure if you can directly use variant 3 as it depends on how you
> assembly your OSGi runtime at the moment.
> At the very least though you can use the list of runbundles that you get
> from the build and use it for your environment.
>
> If you are not already doing so then you should adopt a method to assemble
> your whole application that uses the OSGi resolver. It makes it easier to
> choose the right bundle and gives you an early warning if your deployment
> is incomplete or inconsistent.
>
> Christian
>
> 2017-06-23 9:45 GMT+02:00 Raffaele Gambelli <
> [email protected]>:
>
>> Hi all,
>>
>> I would like to receive some hints about the correct management of CXF in
>> a OSGI/Equinox environment.
>> As premise I'm just arrived in a company where there is a big application
>> deployed in OSGI, with many bundles, my colleagues have told me about many
>> conflicts in using cxf in the different bundles, so they prefered not using
>> it at all.
>>
>> For what I can see, there was a wrong usage of OSGI paradigm, for example,
>> each bundle who makes use of cxf:
>> - embed all cxf direct and transitive dependencies, so each bundle has all
>> what it needs inside it, but bundles are big
>> - that is, each bundle has <import-package>!*,</import-package>, that it
>> is states that bundle does import nothing, because it embeds everything
>>
>> They use no cxf bundles at all, but there are a couple of bundles
>> embedding it...
>> I would like to know if exist a cxf bundle, I found this
>> http://cxf.apache.org/distributed-osgi.html but I'm not understanding
>> really if it is useful in my scenario of if it is something too big to be
>> simply placed in an already complex system like the our.
>>
>> Otherwise which best practice should we adopt? Does it make sens create
>> our cxf bundle and modifying all the other bundles to import packages from
>> it?
>>
>> Really thanks to all, OSGI seems very difficoult but we believe that it
>> has many strengths
>>
>> Raffaele Gambelli
>>
>>
>
>
> --
> --
> 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>
>
