Almost all of the web apps we build nowadays (at least on the circles I usually move around) rely on the beloved and hated session. This artifact, providing a stateful user wide storage, allows us to relate several HTTP requests together and thus implement the concept of authenticated and secure web applications, that “know” who is using them several requests after they authenticated, despite the root stateless characteristic of the HTTP protocol itself.
To provide a very brief recap, sessions are usually implemented using a hash like memory structure on the server, where each session is stored using a unique identifier string. This string is stored also on the users web browser, typically via a cookie or by sending it back and forth on each request as a POST or GET parameter.
I believe it’s time to move away from this approach and start building session-less web applications that still provide the same feature set and security.
Up until today I was convinced that developing with a Java IDE under Linux was synonym of looking all day at a really ugly and disturbing set of widgets thrown on my screen by a 6 year old. But after upgrading my Netbeans installation to 7.2 I decided to do another Google search about it and voila…
We have an internal Maven repo/mirror in my company, we use it to host the releases of our internal apps and libraries, as well as to mirror all the external packages we use (this speeds up build times, new environments set-ups and reduces bandwidth use).
Our internal repository requires authentication to both read/download packages and to publish new releases.
Play 2.0 provides built-in support for Maven repositories, and it’s quite straightforward to add new ones, but how to configure and use an authenticated one wasn’t documented (at least as far as I could see on the official Play website).
A friend recently recommended I take a look at the Mustache templating engine. It’s clean, simple and designer friendly, and promotes logic minimization on the template side (I don’t like the term “logic-less”, I don’t think you can get away with absolutely zero logic).
To try it out I decided to build a simple Struts 2 based web app, but I found that there was no out-of-the-box integration between the two. Thankfully both frameworks are easily extendable so I managed to get them playing along quite easily.
As the first candidate of our evaluation series we reviewed the Play Framework v2.0.
The tutorial and reference documentation used for this article is all available from the Play documentation site.
The first part of the article will go over the set of tasks we proposed to do with each framework, then moving on to evaluate each criteria item.
At my company we are evaluating which web development framework we will use for the next few years.
Since our last evaluation we have been using Java application servers powered by Struts 2 as MVC, Tiles as templating engine, jQuery for Javascript awesomennes, DWR for AJAX calls and MyBatis as ORM.
But we think it’s time to re-evaluate and move on to a newer/better/friendlier framework.
In this post I’ll present you with our candidates and the criteria we are evaluating each framework with. Over the next weeks I’ll post the actual evaluation of each framework and finally what our choice is and why.
Cross-site request forgery attacks (CSRF) are very common in web applications and can cause significant harm if allowed. If you have never heard of CSRF I recommend you check out OWASPs page about it.
Luckily preventing CSRF attacks is quite simple, I’ll try to show you how they work and how we can defend from them in the least obtrusive way possible in Java based web apps.
Object-relational mapping (in the JPA compliant sense) is so ubiquitous nowadays in the Java development scene, that we rarely question ourselves if we really need it, and if not using it may be a better option.
In my experience, some systems benefit from using JPA technology (most systems actually), but some do not, in fact I think some systems become unnecessarily complicated and bigger because of it.
In the previous posts about the java.util.concurrent framework, I introduced what for me is the core of the package and what you will use the most on real-world applications.
Going further with the topic, it’s worth to know the new fork/join framework introduced in Java 7. The pros and cons of this framework over the usage of thread pools or regular thread/runnable development has been subject of a lot of debate, but I think it is still a nice tool to have in your arsenal.
I’ll use a more classic approach to show you the basic structure of the fork/join framework and code a version of the Quicksort algorithm using it.
Picking up from where I left off in my last post about the java.util.concurrent package, it’s interesting and sometimes mandatory to get feedback from concurrent tasks after they are started.
For example imagine an application that has to send email batches, besides from using a multi-threaded mechanism, you want to know how many of the intended emails were successfully dispatched, and during the actual sending process, the real-time progress of the whole batch.