I'm using Spring Boot with Jersey 2. The only media provider is org.glassfish.jersey.media:jersey-media-json-jackson (checked the runtime classpath) so I guess I'm using it for JSON serialization. However, I don't configure it explicitly, but I noticed in JerseyAutoConfiguration#addInitParameters that scanning for SPIs is explicitly disabled with the following line:
registration.addInitParameter(CommonProperties.METAINF_SERVICES_LOOKUP_DISABLE, "true");
The Jackson feature is defined in jersey-media-json-jackson.jar/!META-INF/services/..., but scanning it is disabled.
How does Jackson get configured for Jersey in Spring Boot?
According to the docs, Jackson gets automatically configured in Spring Boot (it just need to find Jackson lib in your classpath).
There are a lot of ways to configuring Jackson as you can see here in the docs.
If you want to see in details the configuration of Jackson in Spring Boot, take a look at JacksonAutoConfiguration class.
Related
The major problem description is below
[a bean of type 'org.springframework.web.context.WebApplicationContext' that could not be found]
I try many times,and guess adding a spring-boot-web-starter may works,but when i do that,another problem occured.
You can't use servlet based solutions with Spring Cloud Gateway since it's reactor based. Please use WebFlux starter instead of spring-boot-web-starter.
I'm trying to get rid of XML in my project.
I already tried to add this:
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(CustomerService.class);
sf.setAddress("http://localhost:9000/");
sf.create();
to my Activator class, but my bundle wont start with this.
So, how usually people configuring endpoints?
(Sorry, no code, just some high level insights from my experience/projects)
I use jersey and its integration into the OSGi environment. I.e. org.glassfish.jersey.servlet.ServletContainer to which I register all jax-rs resources. This way, I can use whatever HTTP server implementation is available (for example, jetty) and configure it via the OSGi system environment properties.
For simplicity, I re-register annotated OSGi (declarative) services as singleton resources/endpoints into that ServletContainer.
Maybe, CXF has also a similar approach.
is it possible to use a CXF ResourceComparator in OpenLiberty or WASLiberty?
http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-Customselectionbetweenmultipleresourcesoroperations
Must the cxf dependencies be supplied in the WEB-INF/lib or is enough to modify the apiVisibility of the app? And how can be declared to CXF? with a cxf.xml?
TIA
PacoG
There are multiple ways to use CXF in OpenLiberty/WebSphere Liberty:
* You can use the built-in jaxrs-2.0 feature, or
* You can package the CXF modules you need with your app (or in a shared library associated with your app)
If you use the first approach (jaxrs-2.0 feature), then you will only have the JAX-RS 2.0 APIs available - which does not include CXF ResourceComparators. There are a few IBM-specific APIs that go above and beyond the spec (for example, integration with CDI, security, attachment processing, etc.) - you can find more information on those APIs at:
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_dep_jaxrs.html
If you use the second approach, then you have the full feature set of the CXF modules in your application, but they will not be fully integrated with other Liberty features like the jaxrs-2.0 feature is. For usage instructions, I would suggest the Apache CXF documentation - like the page you referenced in the initial question.
Hope this helps, Andy
I am getting an exception as given below.
I want Response class to be loaded from jawax-ws-rs.api.jar.
but its getting loaded from the j2ee.jar and throwing the below error:-
java.lang.NoSuchMethodError: javax/ws/rs/core/Response.readEntity(Ljava/lang/Class;)Ljava/lang/Object
Is there any way we can skip loading of j2ee.jar at startup of WebSphere?
Your question is incorrect, probably what you really want is to replace JAX-RS engine provided with WAS with some third part. And you should never pack j2ee.jar with your application as all required classes are already loaded by the server.
Check the following posts and links:
JAX-RS Jersey 2.10 support in Websphere 8
Disabling the JAX-RS runtime environment
I've found conflicting answers to this question and I've failed to successfully run an example.
Can JAX-RS be implemented using Servlet 3.0 (in particular, Tomcat 7) with annotations, only, without having to implement another Servlet Container?
If no, please explain why the following quote from this book is either, incorrect or I'm interpreting it, wrong.
Because this example deploys within a Java EE application server or
standalone Servlet 3.x container, all we need is an empty web.xml
file. The server will detect that an Application class is within your
WAR and automatically deploy it. (RESTful Java with JAX-RS 2.0, Bill Burke)
To clarify what I don't need help with... I've, successfully, implemented JAX-RS in Tomcat 7 with Jersey using a web.xml, so, I don't need any explanation of how to do so. Also, I'm fully aware that other Java EE/Servlet Containers (TomEE, Glassfish, Jersey, Websphere, etc...) are all JAX-RS aware out of the box. I just need to know if I'm chasing my tail trying to get Tomcat 7 (Servlet 3.0) to work with JAX-RS without adding a Servlet Container and without web.xml entries.
In a Servlet environment, Jersey runs as a servlet or servlet filter. No way around that. So how does it work without declaring it in the web.xml? Two main components to this functionality
Programmatic registration of Servlet components (i.e. servlets and fitlers). You can do a Google search, and you should find some hits of examples.
Servlet pluggability introduced in Servlet 3.x. How it works is you implement a ServletContainerInitializer, list that implementation in a file named javax.servlet.ServletContainerInitializer, and put that file in the META-INF/services directory of the jar. The servlet container should scan jars looking for this file. When it finds on, it sees the implementation, finds the implementation, instantiates it, then calls it onStartup method.
Jersey has such an implementation of the SevletContainerInitializer in the JerseyServletContainerInitializer. This class is located in the jersey-container-servlet jar. So you need this jar for this to work. If you look at this method, this is where you will see the programmatic registration of the ServletContainer (the same one that yo would declare in the web.xml
But that's not all. We still need some way of configuring our application, at the least declare the servlet mapping. That's where the Application class and the #ApplicationPath annotation come in. We would extend the Application class and and annotate the #ApplicationPath("/path") where "path" is the same as the servlet mapping in the web.xml
#ApplicationPath("/api")
public class MyApplication extends Application {}
This is standard JAX-RS. With Jersey normally instead of an Application class, we use a ResourceConfig class (which is a subclass of Application)
#ApplicationPath("/api")
public class MyApplication extends ResourceConfig {
public MyApplication() {
packages("package.to.scan");
}
}
You can see more about Jersey deployment options in a Servlet 3.x environment, here.
It should also be noted, that a Java EE server has the JAX-RS implementation, so we only need to add the javaee-api jar to our application as provided dependency. But in a servlet container, we need to provide our own implementation, Jersey being such an implementation.
If you are using Maven, the main dependency you'll need is this one
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey2.version}</version>
</dependency>
This will pull a bunch of other jars in. You you aren't using Maven, then you can download all the jars here (the JAX-RS 2.0 RI bundle), and put all those into your application.
See Also:
How to use Jersey as JAX-RS implementation without web.xml?