I'm using Spring Integration with AMQP-backed messages and I'd prefer to use JSON instead of the default Java serialization for messages. This preference is due in part to serialization exceptions encountered when using Kotlin objects.
While researching the issue, I came across this post:
Spring integration - AMQP backed message channels and message conversion
So it seems the ability to use JSON serialization with AMQP-backed messages has only recently been supported. Moreover, I believe Spring Cloud Stream project provides support for this approach out-of-the-box but I haven't been able to figure out how to achieve something similar with SI.
I came across a post that provides a means to do this channel-by-channel but it seems tedious to configure it this way for each channel when I really just want to use it across the board.
Is there something preventing you from upgrading to 4.3?
<int-amqp:channel id="withEP"
extract-payload="true" message-converter="jackson" />
There's currently no way to globally set options for all channels of a particular type.
Related
I want to build a RESTful service/API. I used some framework like play to build it but I want to try other more efficient ways. I heard that Jersey is a common library for building a REST API, and Spring is also a good framework. But I also saw some solutions like Spring+Jersey. Thus, I am a little confused about those REST API solutions.
Can anyone tell me what is the difference among those? Jersey REST, Spring REST and Spring+Jersey REST?
My goal is building a couple of REST APIs that take JSON as input/output. I have jar file as the backend process logic to process the input a JSON/object and return a JSON/object.
Jersey is the JAX-RS API example implementation provided by Sun, while Spring REST is of course Spring's implementation of the same API/JSRs. The major difference is that Spring REST easily integrates into other Spring APIs (if you wish) such as Spring Data Rest.
There are a few noteworthy differences between them - you can "embed" Jersey Resources (known in Spring as Controllers) within each other, to enable a separate class that is responsible for the sub-path of a certain path, while this doesn't appear to be available in Spring right now (you have to define the full path). Also, in my opinion Jersey gives better "out of the box" error responses (such as why it can not map a JSON payload to a Java bean using Jackson) while Spring is a bit more configurable but plainer without some additional work.
In the end the difference in choosing between them usually comes down to - are you already or do you plan to integrate any other Spring libraries into your application? If so Spring REST is the way to go as you'll have a much easier time integrating it, otherwise it is really just personal preference which you'd prefer to use. Personally I like Jersey but the power of other related Spring projects (such as Spring HATEOAS which I highly recommend) makes Spring the better choice. I don't think there will be a real determining factor in your case.
As your "gold" target is a simple API with JSON input/output, I'd recommend you follow the Spring REST guide.
One major difference is in the area of unit testing support.
Jersey Test Framework does not lend itself for mocking server side code - For example, if your REST Resource depended on a Service, you would like to mock the service when testing resource methods. However, Jersey Tests run a separate container and unit tests sort of make calls to the running instance of your REST resource - at this point of time, I have not found any documentation or way for mocking server side code.
On the contrary, Spring MVC tests do not require any containers - and are more well integrated with its controllers. Dependency Injection can be used to inject mock services / DAOs to have better unit tests.
I also find that documentation on Spring projects are more mature when compared to Jersey.
One subtle difference is in the instantiation of the resource (Jersey) or controller (Spring) objects.
Jersey new's a resource object for each request. Whereas, by default Spring treats controllers as beans with default scope of singleton. This can be overridden with a #Scope annotation (although if you do that it will get flagged by Sonar).
This default behavior of Spring has bitten our application several times. With the controller class being a singleton, all class members are effectively static. So values set handling one request will still be there for the next.
This is something to be aware of if your using Spring. My suggestion is to #Scope the controller class as prototype, even though that will earn you a warning if you do Sonar scans.
Our RESTful application need to support 'partial responses' to limit bandwith.
By this I mean that the REST client tells the URI service which fields of the resource it is interested in.
For instance: api/v1/users/123/fields=firstName,lastName,birthDate
We're using Jackson parser to convert our DTO's to a JSON structure.
The problem is that we cannot tell at runtime to 'skip' some properties.
We should need to create a class at runtime with a variable amount of properties to accomplish this. But I don't think this is possible in Java, it is a static language after all.
While searching the internet we found some semi-solutions by just returning a java.util.Map containing the requested properties or filtering out properties by the Jackson parser.
Especially the latter seems a 'hacking solution' to me. It seems that Spring MVC doesn't provide an out-of-the-box solution for this issue...
Is there any alternative in the Java world we can use to solve this issue?
How about Yoga
Yoga extends JAX-RS and SpringMVC RESTful servers to provide GData and LinkedIn style field selectors.
Choose which fields you want to see at call-time
Navigate entity relationships in a single call for complex views
Much faster speeds in high-latency (e.g. mobile) apps
Streamline client development
Browsable APIs
this seems pretty basic, but I am rather new to web development so I am a bit stuck here. I have MongoDB running on the backend, which contains geo-spatial objects that in the front end should be displayed on a map. The communication between backend and web frontend is where I have knowledge gaps.
The user should be able to zoom to an area on a map that he is interested in, then press "Search". The backend would then find every entry in the database that has coordinates that are on the users current screen. It would transmit these to the frontend, ideally as a list of JSON objects. The frontend displays these on a map.
I have a front end mock up, code that puts data into MongoDB and code that queries MongoDB. I know that I am missing a server that can be queried from the frontend. I thought I use Jetty. But what do I need to do then? I guess I need Jetty to provide a JSON API that I can query from JavaScript. Could someone point me to the Jetty class or interface that I need to implement and maybe give a few lines of code on how to query this from JavaScript?
You have a very open question here.
To start with, Jetty is merely a Java Web Container (following a subset of the Java EE Web Profile), while it does have some AJAX/JSON capabilities, it is extremely fundamental and not hooked up into any sort of query API.
You would do better do use Jetty along with a proper REST/JSON API library for your project.
Some examples (these are not the only choices available):
jersey - Jersey - an Open Source JAX-RS (JSR 311) implementation for RESTful web services, with JSON Support - Here's Lars Vogel's Tutorial on JAX-RS using Jersey.
restlet - Restlet - another RESTful web API, with a JSON extension
resteasy - RESTEasy - another JAX-RS implementation for RESTful web services, with JSON marshalling.
Also note that there are many flavors of Java based JSON APIs and Libraries, you should probably be aware of them as you will encounter them in your journey to success.
In the end I found the Dropwizard framework (there might be others), which does a lot of the work that is necessary to get a simple JSON API up out of the box:
http://dropwizard.io/
We have a system built on MarkLogic, Java / GlassFish. We need some kind of system that could capture thrown exceptions from any of those three subsystems, and then provide a nice web-based reporting interface where exceptions could be viewed, prioritized, marked done. We use JIRA.com in the cloud so if there was any way to integrate with that, it would be nice. Prefer open source or inexpensive.
I'm not sure whether a Java-based system would accomodate our MarkLogic errors, so I believe we need something that is language-agnostic.
Thanks.
If you are communicating with MarkLogic using a MarkLogic "HTTP appserver" (as opposed to XCC or WebDAV), then you can use the error handler configuration as a choke point for catching unhandled exceptions. I've never tried this, but, in theory, in the error handler, you could make an http request and send them anywhere you want.
See http://docs.marklogic.com/5.0doc/docapp.xqy#display.xqy?fname=http://pubs/5.0doc/xml/dev_guide/appserver-control.xml%2387072
If you are using XCC, then there are other places to put choke points in your Java code.
MarkLogic writes exceptions by default to the Data/Logs/ErrorLog.txt file. Application code within MarkLogic can use xdmp:log, or trace() to log messages to the same file. The file can be accessed quite easily through file-system if GlassFish is running on the same host., It can also be disclosed through an App Server within MarkLogic with some custom XQuery code.
GlassFish itself appears to be a Java EE platform. I expect it to do logging using something like Log4J. The logging messages in the ErrorLog and the Log4J log will likely not be formatted identically, but basic properties should be there, like date/time, and error message. Log4J logging can be set to write to a log file as well. You could consume it in a similar way as the ErrorLog.
I am not aware of any error reporting web-interface for such logging, but I believe JIRA provides an HTTP API, which can be used to push information into it.
I used xml services for post and retrieving data from webservices. I dont know about JSON parsing, whether JSON is easy than xml.
That depends, do you plan on supporting other platforms?
The .Net based platforms have more than ample resources for easily consuming services that are hosted with a variety of serialization methods (and many other variances). If you only plan on supporting Windows Phone or other .Net based platforms than you may find that XML Serialization is easy and can stick with it. When you start to consider other platforms then you may find that Xml serialization can at times be a pain and JSON is the preferred way.
If you want to go with JSON parsing in addition to the JSON serializer that comes with the .Net platforms you may also want to check out JSON.Net (which is much more flexible than what comes with the .Net libraries) and RestSharp for consuming REST based services with JSON serialization.