A couple of months ago, we were tasked with creating an API to expose some functions in our system to third party developers. We chose to expose these functions as a series of REST web services. I got to play with Jersey, the reference implementation of JSR 311 (Java API for Restful Services); this turned out to be a nice surprise, as it proved to be extremely powerful and elegant. In this post, we’ll create a very simple REST web service using Jersey.
Whatever kind application you’re working on, you will probably need to create some sort of message more complex than “Hello World!” at some point. Whether it’s a log message, or some text to plonk into your nice UI, you will probably also need to format it in some way to include some variable values, and maybe some embellishments like using the correct words for plural and singular values.
Java provides a number of ways to do this. In this post, we’ll look at a few of them.
It’s been some time since I started off in the world of software development, but I have found myself looking for a good way to schedule tasks more than once, and I’m sure you have too. You know the sort. Run this report every third Friday of the month, clean out this table at the end of every day, sacrifice a goat every summer and winter solstice, and so on.
Some tasks can happily run in Cron, provided that your operating system has Cron. However, some tasks require a bit more flexibility than this old workhorse can provide. You may need to run the task in the context of your application, for instance, or your requirements might dictate that the scheduling of certain tasks must be controlled by the users. In the case of a Java application, you might not want to start and stop the JVM every time a small task needs to execute.
Enter Quartz, OpenSymphony’s enterprise job scheduler. This API allows you to schedule tasks within your own application, which means that you’re more or less free to control the scheduling your way. In this post, we’ll look at some of the most basic tools which this API brings to the table.
In a project I was working on recently, we were building up a web page by loading up its template, content hierarchy and other information dynamically. This is a common setup, and a very flexible one since it allows sweeping changes to be made very easily. Unfortunately, this flexibility comes with a cost; pulling everything through EJB calls can give you a speed not unlike that of a slightly stunned tortoise trying to sprint up a treacle covered hill.
One way of mitigating this problem is to use a Facade pattern to load as much as possible with as few calls as possible. However, this is not always the best approach, especially if most of the content is not likely to change very often. In these cases, it’s preferable to store the content at the end where it’s being used, avoiding the remote call completely.
This can be implemented quickly and easily with a Map, but that would leave us with a lot of work to do when it comes to managing the cached content. For example, what if we wanted to make sure that the cache does not continue to fill up indefinitely, or that it gets backed to disk when it goes idle for some time to preserve memory?
Since we were already using Hibernate in the data layer, we were already using a cache at that level in the form of EHCache. It made sense to try and see if it was possible to use this in our controller layer, and it turned out to be extremely elegant to use. Continue reading
Today I was writing some interceptors in Java, and I wanted to be able to filter the input based on whether it implemented a given interface or otherwise. Class<?> exposes a very handy isAssignableFrom method for this, but it doesn’t look very nice, so I tried to go for something a bit neater, like:
Neat, and much more readable. I didn’t quite make it there, but got close enough for my purposes, and had some (very little) deeper knowledge of generics inflicted upon me for my sins.