It is very well possible that the embedded cxf conflicts with the normally installed CXF. So indeed it makes sense to remove all embedding once cxf is installed in a regular way.
I suggest you first create a small demo project with a cxf client and service to prove your installation of cxf is complete. Then as soon as you know cxf is working fine you can remove the embedding of cxf in your current bundles and get them working one after another. Christian 2017-06-23 16:39 GMT+02:00 Raffaele Gambelli < [email protected]>: > 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=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> > > -- -- 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>
