My understanding regarding TomEE (or any Java EE 6 container) is all that i just need to deploy a JAX-RS based application with correct service class annotated.
#Path("/hr")
public class HelloRest {
#GET
#Produces(MediaType.APPLICATION_JSON)
public String getClichedMessage() {
return "Hello World";
}
}
The TomEE container SHOULD take care of converting the "hello world" to proper json format {"hello world"}
I was wondering why TomEE is not converting it to JSON format. Please note I've not used any spring configuration for CXF as I expect this to work with/without CXF configuration.
The certified Web Profile implementation of TomEE does not implement JAX-RS, since JAX-RS is not part of the Web Profile in Java EE 6 (it is in Java EE 7 though).
However, since it appeared that there actually IS very useful stuff in Java EE 6 that goes beyond the Web Profile, TomEE has 2 extra distributions that contains some of this extra stuff.
On the download page you'll find the "JAX-RS" and "Plus" distributions that both contain JAX-RS. With those (or any full profile Java EE AS) you indeed don't need any configuration.
Produces/Consumes doesnt mean convert, it is mainly http headers. String in json is a...string. depend of course of your body writer.
Related
I started using SpringBoot and like it a lot. I see that #RestController automatically serializes POJOs to json. I like that functioonality, but would like to use it outside of a web server context.
Basically I'd like to have all the part of SpringBoot until the point where the response is in JSON format, but then I don't want to deliver it via a web server, but rather my own implementation.
Is there an interface I have to implement in order to get SpringBoot to accept non-web-requests and return non-web-responses.
An example to make clear what I want:
Right now I can access localhost:8080/hello and SpringBoot will return "world".
Is there a way to make this work on console. E.g. I enter "hello" on console and press enter and I get "world" delivered to console by SpringBoot.
So instead of a web interface via tomcat I'd like to implement a console interface but with the same SpringBoot functionality.
UPDATE: The console application was probably not the right example. I am looking for a more general approach. So let's say instead of a console interface I want an Arduino to be able to send "hello" to SpringBoot via a serial bluetooth connection and SpringBoot should return "world" on that same bluetooth serial connection. My question is, whether there is an interface I need to implement in order to tell SpringBoot how to accept REST requests and how to send responses. And I don't want to focus on a particular implementation (like console or BT serial), but instead, once the SpringBoot application is created, I'd like to just replace the tomcat web interface by a BT serial interface or a console interface or any other interface I want to implement, but keep all of the logic (Controllers, Models etc).
Thanks.
Sure! You can create a console application.
You will need to create a class that implements ConsoleRunner. Please find a tutorial here:
https://www.baeldung.com/spring-boot-console-app
If it is the JSON de/serialization that interests you.
You can use Jackson's ObjectMapper .
You don't need the whole spring-boot web stuff.
You can ommit the starter-web dependency and use CommandLineRunner and jackson to have a console application that de/serializes your responses/requests to json.
I'm implementing a REST service using Camel's cxfrs component. Various examples I've seen around the inets say I can get the service to return a JSON serialization of the object in question using a cxf:providers tag, like so
<cxf:rsServer id="rsServer" address="${CXFserver}${service}" serviceClass="org.trinityhealth.esb.PersonService"
loggingFeatureEnabled="true" loggingSizeLimit="20">
<cxf:providers>
<bean id="jsonHandler" class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
</cxf:providers>
</cxf:rsServer>
This compiles and deploys just fine. But no matter what variant of this config I try, the service responds with "No message body writer has been found for response class Person". The Person class has a "#XmlRootElement(name = "Person")" annotation in it, which I guess is great if I wanted XML produced. But I don't - I want JSON. Jackson has a ton of annotations, do I need to add one to the Person class to get my service to realize I want the class serialized by the Jackson writer?
I don't know Camel that well, but typically Jackson does NOT require root annotation, unlike JAXB (partly since JSON structure does not require name for root type), so it seems unlikely you would such annotation.
I am guessing that rather the registration does not succeed for some reason.
I have created a Jersey 2.5 Scala REST API Project.
I have a ResourceConfig file, we will call it MyApplication, that looks similar to this:
class MyApplication extends ResourceConfig {
packages(classOf[MyResource].getPackage().getName())
}
All it does is register the resource: MyResource. How can I configure Jersey (2.5) to provide out-of-the-box style JSON Serialization/Deserialization.
For example, here is what MyResource might look like:
#Path("/")
class MyResource {
#POST
#Produces(Array("application/json"))
#Consumes(Array("application/json"))
def getIt(request:SomeRequestModel) = {
/* Do something with the request, return some response model */
return new SomeResponseModel
}
}
So to reiterate, how can I configure Jersey to automatically deserialize and serialize the request and response models, respectively?
It's not actually Jersey that provides the serialisation, it simply draws on an implementation of JAX-RS to perform that role.
Assuming Jersey is a strict requirement, the easiest solution here is to use jackson with Scala bindings. You can find an example here: https://bitbucket.org/jordipradel/jersey-scala-example
If you're not completely tied to Jersey... Might I suggest trying either Spray or spray2-mini instead for a far more idiomatic Scala solution?
I have used Jersey little when developing Java REST services. However, I would say you appear to be conflating two concepts--registering JAX-RS providers and configuring providers to serialize/deserialize JSON.
To register a provider, you use ResourceConfig as you have done.
As for the second issue of configuring Jersey to "know" how to serialize/deserialize JSON:
"As stated in Section 4.3, “Auto-Discoverable Features” JSON-Processing media module is one of the modules where you don't need to explicitly register it's Features (JsonProcessingFeature) in your client/server Configurable as this feature is automatically discovered and registered when you add jersey-media-json-processing module to your classpath."
To add the Jackson flavor of that module to the classpath, you just manually put it there or do this with Maven:
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>2.5</version>
</dependency>
I chose Jackson because it is in my view the best JSON serializer/deserializer in the Java realm.
Having said all this, I once experimented writing services with my preferred Java REST framework, RESTEasy, in Scala. It was more awkward than my first date. Scala and RESTEasy just don't fit together because of an idiom mismatch, issues with types, and so on.
If you want to write REST services in Scala, please consider frameworks built with the language in mind like Scalatra, Unfiltered, or Spray.
I'm working on a RESTful Web-service using Jersey v1.9.1. Some methods return JSON. When I want to Debug my application I start within a grizzly server, otherwise for production I build a war file and place it in a TomCat v7 installation. My projects are all Maven2 projects.
Now, I noticed that for a method that returns List<CustomObj>, where CustomObj has appropriate JAXB annotations, i.e. #XmlRootElement(name="CustomObj"), and getter/setters for all relevant members:
Using grizzly, I get something like {"CustomObj":[{<fields-of-customObj>},{<fields-of-customObj>},{<fields-of-customObj>}]} (when the list has 3 elements). Parsing this with GSON works fine.
Using TomCat, however, I get this: [{<fields-of-customObj>},{<fields-of-customObj>},{<fields-of-customObj>}] -> so as you can see, the "root" is missing somehow
I have the impression that the jersey-json module (which I included into my Maven2 dependencies) are not used at all in TomCat, even though they should be used (they are used in Grizzly for sure). Also, creating my own #Provider for a ContextResolver<JAXBContext> as described here only works in grizzly, in TomCat the getContext() method will never be called.
Is there anything I need to consider with TomCat?
Cheers!
I'm trying to setup an rpc server so that a blackberry mobile app can make calls to it. Thought of trying out json first.
I've setup a working server side impl using http://jsonrpcphp.org/ .
Couldn't find any direct libs for blackberry/j2me. android-json-rpc looked interesting, but the blackberry SDK complains
"The type java.net.URI cannot be resolved. It is indirectly referenced from required .class files" at this line
HttpPost request = new HttpPost(serviceUri);
I'm using v4.1 of apache http core and client to make android-json-rpc work.
Looks like the URI class isn't bundled with the j2me/blackberry standard lib.
Is there a quick and dirty way to get rpc working on blackberry ? I don't mind xml or any thing else for the encoding, http is the transport I'm interested in.
BlackBerry 6 has built-in the JSON parser and some better APIs for making HTTP requests. Prior to that, though, you have to compile the JSON parser into your app and use the Java ME HttpConnection class to make and get the HTTP requests. So it depends what version you're targeting.
If you are targeting to < BB OS 6.0 devices.
You can also use org.json.me lib in your app.
Here is the sample named Implementing JSON in your application. It's very simple to use.
Good luck