I want to create client-side java from a restful web service, so that I can call the service. Do somebody know if CXF provide such this tools?
Best,
With CXF 2.4.1, CXF does provide a "wadl2java" tool that can be used to create a Java client from a WADL document. If your restful service provides a WADL, that can be used as a starting point.
Related
I have one Eclipse RCP3 project.Now I need to call a rest api|(java) and Post some information using that API. Need Help.
Being a Java application, an Eclipse RCP app can use most existing Java REST client libraries. My opinion is that the easiest way is to use the ECF JAX-RS Jersey Client. I recently wrote an article about how to incorporate this into an Eclipse RCP application:
https://www.modumind.com/2020/05/19/eclipse-rcp-and-rest-an-introduction/
In short, the JAX-RS Jersey Client is an OSGi Remote Services client created as part of the Eclipse Communications Framework (ECF) project. It embeds a Jersey/Jackson JAX-RS implementation that allows you to create REST clients as annotated interfaces that are made available as OSGi services locally. Jackson is used to data bind the REST responses to Java POJOs which require little or no annotation.
This solution allows you to skip most of the scaffolding code that usually has to be written to make REST calls in a Java application. But of course, you can also use Jersey and Jackson directly, those plugins are made available via Eclipse Orbit project.
http://www.eclipse.org/orbit
The GitHub repository for the ECF JAX-RS Jersey Client can be found here:
https://github.com/ECF/JaxRSProviders
We have working GXT (GWT) project.
We want to add new JavaScript frontend to this application.
Can we use current GWT-RPC REST requests from JavaScript?
If yes: How to add Swagger UI for existing GWT-RPC REST requests?
GWT-RPC is NOT a REST service, so it cannot be exposed using OpenAPI Specification.
If your server is a Java server you can use some JAX-RS implementation like jersey to expose REST services. And access to those services on the client side using RestyGWT or AutoREST for example.
At that point, you will be using a REST API. Then you need to create, expose and consume the OpenAPI Specification of your services. Here there is a guide to expose the OpenAPI Specification from your JAX-RS interfaces using jersey.
https://github.com/swagger-api/swagger-core/wiki/Swagger-Core-Jersey-2.X-Project-Setup-1.5
Swagger UI is a standalone app. So you can either access it in a new window or integrate it in your GWT app using an iframe. Loading the Swagger UI using JS into your GWT app is possible, but unnecessary complicated IMO. The jersey-swagger guide includes the Swagger UI exposed as a static resource in your war.
I would like to expose OSGi bundles as SOAP web services or in other words publish web service endpoints which are provided by OSGi bundles.
The architectural model/idea is that there is a host web application which is a normal war file deployed on JBoss (5.1.0 GA) offering a SOAP web service interface (JAX-WS).This host application starts the OSGi framework embedded (via ServletContextListener - currently Equinox) and loads a number of OSGi bundles which function as plugins.
The plugin bundles have a dependency to the host application as part of the request processing is delegated to them via internally defined interfaces.At the same time the plugin bundles should also be able to contribute an own public SOAP web service interface (endpoint implementations and the respective WSDL files to be published and made available by the application server).
The first approach we followed was that the host web application deploys a dispatcher/proxy servlet which delegates the processing to the relevant endpoints provided by the OSGi bundles.
There is the servlet bridge solution in OSGi/Equinox (BridgeServlet/HTTPServiceServlet) which enables the programmatic registration of servlets (for ex. in BundleActivators of the plugin bundles) using the HTTP Service specification.
The problem is that I have SOAP-based web service endpoints and would need to be able to wrap them in a javax.servlet.Servlet implementation.
That's usually an interna of the WS stack implementations of Java EE 5 servers which follow the servlet–based web services approach (endpoints defined as servlets in web.xml) and internally use to install native endpoint servlets for web service endpoints.
I did not find such a public endpoint servlet implementation which could be registered with the HTTP Service (maybe something similar like com.sun.jersey.spi.container.servlet.ServletContainer which can be used to publish REST-based services for JAX-RS applications in OSGi)
I am a little surprised that I did not find as much about registering SOAP-based WS endpoints with the OSGi HTTP Service or may be I do not see the obvious.
I have found something similar, JAX-WS-Commons/Spring (spring support for configuring JAX-WS, http://jax-ws-commons.java.net/spring/), which internally uses the class WSServletDelegate of the JAX-WS RI (metro) to process web requests for the endpoints.
But I am not sure about it, it seems kind of deprecated and I need to provide the metro WS stack jars to JBoss (or in the war file) in order to make it work on JBoss 5.1.0 GA.
Another approach seems to be distributed OSGI, which allows to publish OSGi services for remote access.
However, I could not find clear information about how to provide these services as web services on JBoss.
Other realisation aspects are:
we are bound to JBoss 5.1.0 GA and changes to the JBoss configuration should be as minimal as possible (in order to have minimal constraints to the setup of our customers)
All web services are developed contract-first which means that the original WSDL's are to be used by the providing container.
the plugin components should be as simple as possible concerning dependencies or technologies (in order to have minimal requirements to the skill of the plugin developers)
we use Spring 3 and Gemini Blueprint.
Finally, there are some ambiguities and unclear aspects and unfortunately I could not find reports on projects with similar requirements.
So, I would be eager to hear some suggestions or comments of the experts.
Maybe there are options I don't see, or maybe somebody has realised similar projects before and likes to share experiences.
Thanks a lot.
I am not an expert but another approach I have seen is to put the whole app server with an application into the OSGi container. It is an option in Sling launchpad http://sling.apache.org/documentation/the-sling-engine/architecture.html#launchpad
HTH
I have an OFBiz SOAP-based web service that is exposed (can accept requests) and has a WSDL code generated and a WSDL URL. My Question is, is there a way to consume this web service using a CXF Java client or JAX-WS client?
Overall, i want to be able to add the client in the Mule esb consigeration as part of a Mule FLOW. I can invoke the OFBiz web service using AXIS2, but Mule ESB does not seem to support AXIS2, which brings me to another question - Is there a way i can configure AXIS2 web service client in Mule ESB?
Thanks in Advance
Follow the WSDL-first approach from the Consuming Web Services user guide.
This involves:
generating a CXF client using the WSDL to Java tool from CXF or the Maven plugin,
configuring the client as an outbound endpoint.
And leads to a Mule configuration that looks like:
<cxf:jaxws-client
clientClass="org.apache.hello_world_soap_http.SOAPService"
wsdlPort="SoapPort"
wsdlLocation="classpath:/wsdl/hello_world.wsdl"
operation="greetMe"/>
<outbound-endpoint address="http://localhost:63081/services/greeter"/>
I have implemented a RESTful web service using jersey and deployed it on Tomcat, I have used DAO classes to manipulate database operations, entities to wrap database records. and did the processing in separate package. I want to make this system distributed using EJB. First of all would it be easy to do this change. or i need to rewrite things from scratch. Second, I still need to have the REST WS, so would it be possible to expose the EJB as a REST WS and how? would the REST WS be in the same EJB project or in a different one?
You can definitely do it as an EJB and REST WS. Upgrade your Tomcat install to TomEE Plus, then just add #Stateless or #Singleton to the existing REST service.
You won't need Jersey in there anymore as the Java EE version of Tomcat (TomEE) includes CXF for JAX-RS support.
This example is not well documented, but shows a functional application that combines both EJB and JAX-RS.
http://tomee.apache.org/examples-trunk/rest-on-ejb/README.html