I’ll show you how to add JSON support to the previous JAX-RS project we set up here.
First, we’ll need a JSON serialization library. We’ll use Genson as it has some nice out of the box support for JAX-RS. Go to the Genson website and grab a jar from there. Drag it into your /lib folder. Then right click and click “Add as Library” – then add it as a Project Library in the dialog. This should be the default.
Now we need to add it to our artifact, so our tomcat server deploys it. We do this the same way as we did it last time. Navigate to File->Project Structure and go to the Problems tab and click [Fix] -> Add Genson X.X to the artifact.
Afterwards, let’s make a regular ol’ JavaBean. Mine looks something like this:
Now to make JAX-RS automatically convert this object to JSON, we simply define in our HelloWorld class, that the GET method returns JSON. We do this with the @Provides(“application/json”) annotation. Then as a return type we return our JavaBean, and it is automatically serialized to JSON. In pretty pictures it looks like this:
And when we call the URL we get JSON:
Here I will show you how to make a simple Ajax GET-request, to a locally hosted REST JAX-RS service. The IDE used is IntelliJ 15.0.4
I’m going to take you through setting up a JAX-RS project using Tomcat in IntelliJ 14. Please make sure you have Tomcat installed and configured properly.
I’ll take you through configuring Tomcat for IntelliJ IDEA 14.
I’ll take you through starting a simple web project in IntelliJ.
Today I’m going to walk you through how to set up a JSF project with Tomcat in IntelliJ IDEA.
Recently i had the unfortunate experience of having to find a bug in an android app, that caused a Google Maps fragment to fail intermittently. It had worked previously, though no one was sure quite when it had stopped.
After seven straight hours of debugging, I found that while enabling SSL support, specific API calls sometimes changed the default SSL factory for all https request – effectively causing Google Maps to break, with no error. The first lesson is, don’t change global application state inside some arbitrary API call, because that’s just terrible encapsulation and impossible to find.
The second lesson is, I didn’t need to spend eight hours finding that bug. I knew that it had worked earlier – I really only needed to find out what change broke it. By using git, I could go back to a time where it worked. Then I could skip to the commit between where I am now, and where it worked. If it worked there, I could pick the halfway point between that commit and latest commit, etc. Essentially implementing a manual binary search.
Using that I quickly would have been able to locate the offending lines of code. It shouldn’t have taken more than a couple of hours. Instead it took eight.
Recently we created a placemat and a game for a university project. The goal was to help users eat slower in an engaging way. You can see the video explaining the concept right under this paragraph.
We had five weeks to build it and we ended up with a codebase a little larger than 6000LOC. Reflecting on the project, here’s a few things I wish I had known before I started this project.
Sometimes we’re forced to do things we don’t want to. Most of the time though, we have a choice. A lot of the choices we make are between what we ought to do and what we want to do.I don’t need to grab a chocolate bar while I’m out shopping. But I want to. I don’t really want to go for a run. But I ought to.You might be familiar with the fact that willpower is finite resource. I’ve picked up a simple trick to help conserve it.I use it to make decisions I ought to, even when I don’t want to.