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

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to