To create REST web services, I usually just use com.sun.jersey; but now, I keep seeing org.glassfish.jersey.core as well. So, I was wondering what is org.glassfish.jersey.core? Is this another implementation of JAX-RS?
The com.sun.jersey packages are Jersey 1.x (which is included in Glassfish 3.x).
The org.glassfish.jersey.core packages are Jersey 2.x (which is included in Glassfish 4.x).
You shouldn't mix both versions in a web application.
Related
I'm using WebSphere 9.0.5.3 and after migrating CXF-core lib from 3.1.x to 3.2.x I'm facing this problem :
AbstractJAXRS E No resource classes found
with CXF 3.1.x everything works fine my server is working and my rest services are working as well.
ps1: I have already disabled JAXRSEngine of WebSphere and working with my own libraries ( in the shared isolated package ) and as I said it was working fine with the previous version
ps2: I have already modified the class loader policy ( Multiple -
single )
with some debugging, I figured out that WebSphere is not even loading my classes ( annotated with #path)
ps3: have already upgraded jaxrs-ws-rs to 2.1.1 because CXF 3.2.x
supports JAX-RS latest 2.1 spec even though this spec is backward
compatible with jaxrs 2.0
and i have already upgraded also all the CXF JAXRS related jars and still have
the same problem
PS4: my application is working fine with tomcat 8 and Wildfly/JBoss so
i don't think i have a problem with my resources classes
PS5: in the same jar, the other classes are loaded so WebSphere is filtering the resources classes and not loading them
the main problem here is why websphere is not loading my resouruce classes i have just upgraded the jar and I kept the old configurations ?
The IBM WebSphere Application Server does not provide direct support for JAXRS 2.1. However, what you are attempting may still be possible. Beyond setting the "com.ibm.websphere.jaxrs.server.DisableIBMJAXRS20Engine" property to "true" you should also set the JAXRS provider to "2.0 spec" via the command prompt or administrative console, see the following for details: https://www.ibm.com/support/knowledgecenter/SSEQTP_9.0.5/com.ibm.websphere.base.doc/ae/rwbs_jaxrs_coexist.html
Beyond this, if you need the JAX-RS 2.1 APIs, then you will need to package the APIs with your application. You might also need to use parent-last classloading or package them in an isolated shared library associated with your application. Either approach poses some classloading risk.
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
it seems jboss AS 7.1 supports ejb 2.1.Our ejb 2.1 based application is deployed on jboss 5 AS. We are migrating it to jboss7.1. but i want to know what are the additional configurations required to run ejb 2.1 without any errors?
EJB2 is still supported in AS7.x, the issue might be that AS7 is a new implementation and some of the tuning options and configuations are not available for AS7 - especially the EntityBean CMP.
There are some added for EAP6 (based on AS7) you might download the unsupported version.
Wildfly (the successor of JBossAS) will not continue to support EJB2 EntityBeans because EJB3.2 declare it as optional.
Note EJB2 session beans are still supported but I recommend to upgrade it to EJB3 this should faily simple.
You might keep the EJB2 interfaces to provide an interface for EJB2 clients, but I expect effort for the client as well as the lookup Strings changed.
If the appliation should be kept for the future I would recommend to migrate to EJB3
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.
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.