I am thinking to develop a custom Operation to be executed in an automation chain that needs to execute calls to external rest services.
I do not want to add dependencies if not necessary and before starting to use one of the many java implementations available, I would like to know if there is a library that Nuxeo itself already uses.
I know that CXF is used in Nuxeo but I do not think that the library for rest clients is already a dependency.
Nuxeo already uses Apache Commons HttpClient 3.1, Apache HttpComponents 4.3.3 and Jersey 1.17, any of which can be used to make REST client calls. There are probably others you can use, just look at the dependencies in the master POM to see if your favorite library is here.
All third-party libraries used by Nuxeo are listed in the dependencyManagement section of the Nuxeo root POM org.nuxeo:nuxeo-ecm.
You should indeed make your choice picking in that list first, if it contains a library fulfilling your needs.
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
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 am currently developing an application which has a server part based on JavaEE 6.0 on JBoss 7.1 and a client based on Eclipse RCP 3.7.
For a simple OSGi package for a shared API I already run into trouble due to some differences in versions and depdencenies. The API requires "org.osgi.framework." for the bundle activator and "org.slf4j." for the slf4j logging API.
Currently my client is working very well, but JBoss tells me that the expected version of the OSGi import and the also the imports for slf4j do not fit...
I there a best practice to share OSGi bundles between Eclipse and JBoss? Do I need to get back to simple import and export declarations or can I used Require-Bundle somehow? Do I need to create some compatibility bundles for JBoss to get it running? What is the best way to proceed here?
UPDATE
I solved the issue by using Import-Package exclusively. For the dependency like org.osgi.framework is use version="0.0" to explain it does not matter. :-( It is not very safe, but currently I do not see another option. Is there a better way?
UPDATE 2
One also needs to pay attention to implement the correct verion of the OSGi Framework. JBoss 7.1.x only has OSGi 4.2 implemented, which has no support for typesafe service retrieval.
The best practice would be to use an import package statement with a range from the minimum version which you're using to the next major increment.
For example, if RCP expects version 1.5 of a package and JBoss expects 1.3.6, import version="[1.3.6,2)".
The Semantic Versioning whitepaper (pdf) explains why this style of import is safe and wise.
I myself haven't tried JBoss Errai at all, but I am thinking of migrating the server-side services of my current GWT project into a new project that will be now treated as a platform.
The services in the currect project that are accessed via RPC can be commonly used with other projects as "base platform."
So, I am thinking of using using JBoss Errai for this scenario. And so, the new "base" platform project will be non-GWT and that Ajax apps built with GWT will just call into this platform for authentication, storage, etc.
Is this a good approach anyway?
If your project actually runs fine, why would you want to change it? you can instead, integrate the errai framework and when you want to add a new component, you can take advantage of the features of errai ;-)
I've setup a project in Netbeans 6.5 with some web services that I've created myself and some web services that I've imported from WSDL files. I've setup a couple of desktop application through Netbeans in order to consume these web services. I'm not too sure where to go from here.
I have the GUI setup but not sure how to reference the web services so they can be consumed. I was wondering would anybody be able to guide me through this process or point me in the direction of a relevant tutorial. I'd also like to learn how to consume a web service through a JSP (also created in Netbeans) if possible.
Thanks.
You may find this tutorial useful:
http://netbeans.org/kb/docs/websvc/client.html, but since you are using Netbean 6.5 this may be the correct version:
http://netbeans.org/kb/61/websvc/client.html. As the steps show, it isn't difficult to build a jax-ws client using Netbeans.
But, it depends on what version of Java you are using also, most likely. You may want to download the latest version of jax-ws, if you get errors with your wsdl.
For a JSP, just create a custom tag to call the client.