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
