Christian: You were correct in how to work around WSBindingProvider visibility issue. Thx.
It seems I have one remaining issue with using CXF within enRoute, which is specific to wsdl2java instead of enRoute… and is documented here: - http://stackoverflow.com/questions/39543694/apache-cxf-and-xmlelementnamespace-is-invalid I’ll be doing a writeup and publish example code on how I’m using CXF within enRoute after getting this last issue resolved… perhaps helpful to others. Thanks, Randy On Sep 15, 2016, at 3:45 AM, osgi-dev-requ...@mail.osgi.org wrote: > Date: Thu, 15 Sep 2016 11:45:46 +0200 > From: Christian Schneider <ch...@die-schneider.net> > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] > com.sun.xml.internal.ws.developer.WSBindingProvider is not visible > from class loader > Message-ID: <bae7d6dd-be6b-5229-fbd0-8abaa2e89...@die-schneider.net> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Hi Randy, > > the code complains that the interface > com.sun.xml.internal.ws.developer.WSBindingProvider is not visible. > This possibly means that standard JAXWS from the JDK is used to create > the service proxy. > > I think the reason is that the generated code for the client class uses > the JAXWS API. This API by default points to JAXWS from the JDK. It can > be overridden by CXF but this is difficult in OSGi and I would suggest > to rather avoid this. > > So you should try to use the CXF API to create the proxy. Try this: > factory = new JaxWsProxyFactoryBean(); > factory.setServiceClass(ServiceInterface.class); > factory.setAddress("http://where your service is located"); > myService = factory.create(); > > This will make sure CXF is used and also take care of the classloading. > > The disadvantage is that you directly expose your client code to CXF. So > a common pattern is to create a bundle for the client that exports the > service proxy as an OSGi service for internal use. > > CXF-DOSGi can provide exactly the creation of the proxy and internal > OSGi service in a more automatic way. In CXF DOSGi you would do this: > - Install CXF-DOSGi WS provider > - Install your service API bundle with your generated code for the interface > - Install the Aries RSA config based discovery > - Create a config that triggers the creation of the proxy for the remote > service > > I recommend to first use the approach above and then try with CXF-DOSGi. > The nice thing is that from the start your user code will only depend on > the service interface and an OSGi service. So switching to DOSGi later > will not change any of your code that uses the service. > > Many people think DOSGi is just a way to call remote OSGi services while > in fact it is also a great solution for providing or accessing plain > SOAP and REST services. Once CXF-DOSGi 2 is released I plan to write a > tutorial that shows how to use CXF DOSGi to either expose a plain SOAP > and REST service or use external SOAP and REST services. Especially for > Liferay I think this could become the default way of interacting with > the outside world as it matches very well with DS. > > Christian > > On 14.09.2016 19:49, Randy Leonard wrote: >> I have CXF/SOAP services deployed within OSGi enRoute, and can >> successfully connect via SoapUI. Next is to build a simple OSGi gogo >> command to invoke these services, then migrate this to Liferay for >> end-to-end demo. >> >> To this end, am using the following for guidance (but disregarding >> Liferay components until the shell command works): >> http://www.dontesta.it/blog/blog-2/liferay-7-come-realizzare-un-client-soap-apache-cxf-osgi-style/ >> >> The instructions given above state I would need the following runtime >> bundles with my OSGi Command Line Tools bundle: >> ? Apache XmlSchema Core (v. 2.2.1) >> ? Apache CXF Core >> ? Apache CXF Runtime JAXB DataBinding >> ? Apache CXF Runtime XML Binding >> ? Apache CXF Runtime SOAP Binding >> ? Apache CXF Runtime Core for WSDL >> ? Apache CXF Runtime Simple Frontend >> ? Apache CXF Runtime JAX-WS Frontend >> ? Apache CXF Runtime HTTP Transport >> >> >> It seems quite straightforward, but am getting the following exception >> when running the OSGi gogo command: >> interface com.sun.xml.internal.ws.developer.WSBindingProvider is not visible >> from class loader >> >> >> >> My gogo command code appears as follows: >> >> @Component(service = InvolvedPartyFetchCommand.class, property = { >> Debug.COMMAND_SCOPE + "=party", Debug.COMMAND_FUNCTION + "=fetch" }) >> public class InvolvedPartyFetchCommand >> { >> public void fetch() >> { >> try { >> InvolvedPartyService service = new >> InvolvedPartyService(InvolvedPartyService.WSDL_LOCATION, >> InvolvedPartyService.SERVICE); >> InvolvedPartyPortType port = service.getInvolvedPartySoap12Endpoint(); >> >> System.out.println("Invoking involvedPartyFetch..."); >> InvolvedPartyFetchRequest request = new InvolvedPartyFetchRequest(); >> InvolvedPartyFetchResponse response = port.involvedPartyFetch(request); >> System.out.println("involvedPartyFetch.result="+ response); >> } catch (Throwable e) { >> e.printStackTrace(); >> } >> } >> >> } >> >> >> And my bndrun file for the OSGi command project is as follows: >> >> # >> # LAUNCH SPECIFICATION >> # >> >> >> Bundle-Version:1.0.0.${tstamp} >> Bundle-SymbolicName:com.rps.masterdata.party.soapClient.launch >> JPM-Command:sopclnt >> >> >> -runrequires: \ >> osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\ >> osgi.identity;filter:='(osgi.identity=org.apache.cxf.cxf-core)',\ >> osgi.identity;filter:='(osgi.identity=org.apache.cxf.cxf-rt-bindings-soap)',\ >> osgi.identity;filter:='(osgi.identity=org.apache.cxf.cxf-rt-bindings-xml)',\ >> osgi.identity;filter:='(osgi.identity=org.apache.cxf.cxf-rt-databinding-jaxb)',\ >> osgi.identity;filter:='(osgi.identity=org.apache.cxf.cxf-rt-frontend-simple)',\ >> osgi.identity;filter:='(osgi.identity=org.apache.cxf.cxf-rt-frontend-jaxws)',\ >> osgi.identity;filter:='(osgi.identity=org.apache.cxf.cxf-rt-transports-http)',\ >> osgi.identity;filter:='(osgi.identity=org.apache.cxf.cxf-rt-wsdl)',\ >> osgi.identity;filter:='(osgi.identity=org.apache.ws.xmlschema.core)',\ >> osgi.identity;filter:='(osgi.identity=com.rps.masterdata.party.soapClient.provider)',\ >> osgi.identity;filter:='(osgi.identity=com.rps.masterdata.party.soapClient.command)' >> >> -runbundles: \ >> com.rps.foundation.soapClient.provider;version=snapshot,\ >> com.rps.masterdata.party.soapClient.command;version=snapshot,\ >> com.rps.masterdata.party.soapClient.provider;version=snapshot,\ >> org.apache.cxf.cxf-core;version='[3.1.6,3.1.7)',\ >> org.apache.cxf.cxf-rt-bindings-soap;version='[3.1.6,3.1.7)',\ >> org.apache.cxf.cxf-rt-bindings-xml;version='[3.1.6,3.1.7)',\ >> org.apache.cxf.cxf-rt-databinding-jaxb;version='[3.1.6,3.1.7)',\ >> org.apache.cxf.cxf-rt-frontend-jaxws;version='[3.1.6,3.1.7)',\ >> org.apache.cxf.cxf-rt-frontend-simple;version='[3.1.6,3.1.7)',\ >> org.apache.cxf.cxf-rt-transports-http;version='[3.1.6,3.1.7)',\ >> org.apache.cxf.cxf-rt-wsdl;version='[3.1.6,3.1.7)',\ >> org.apache.felix.configadmin;version='[1.8.6,1.8.7)',\ >> org.apache.felix.gogo.runtime;version='[0.16.2,0.16.3)',\ >> org.apache.felix.gogo.shell;version='[0.10.0,0.10.1)',\ >> org.apache.felix.http.servlet-api;version='[1.1.2,1.1.3)',\ >> org.apache.felix.log;version='[1.0.1,1.0.2)',\ >> org.apache.felix.scr;version='[2.0.0,2.0.1)',\ >> org.apache.servicemix.bundles.wsdl4j;version='[1.6.3,1.6.4)',\ >> org.apache.ws.xmlschema.core;version='[2.2.1,2.2.2)',\ >> org.eclipse.equinox.metatype;version='[1.4.100,1.4.101)',\ >> org.osgi.service.metatype;version='[1.3.0,1.3.1)' >> >> >> >> >> I've seen a number of posts on this issue, but I have such a vanilla >> setup that solutions provided elsewhere don't seem applicable here. >> Suggestions are certainly appreciated. >> >> Thanks, Randy >> >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.osgi.org/pipermail/osgi-dev/attachments/20160915/81029ed8/attachment.html> > > ------------------------------ > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > End of osgi-dev Digest, Vol 119, Issue 33 > *****************************************
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
