security servlet

New declarative security features in Servlet 3.0

Servlet 3.0 is not only about the replacement of the web.xml deployment descriptor by annotations. In this article, we’ll see what improvement it makes in the realm of security. In Servlet 2.5 (and before that), declarative security was about the following features: authentication method (BASIC, FORM, etc)authorization to differents parts of the application (web application resources)data confidentiality and integritysession time-out Servlet 3.0 adds standardized ways regarding two conf

blackbelt vaadin

Vaadin courses on JavaBlackBelt

For those of you who haven’t heard of JavaBlackBelt, it’s an e-learning community site. Once registered, users can use the site in a variety of ways: First, one can take courses on a variety of programming-related subjects.Then, one can pass exams on these subjects. Each exam is made of questions one has to anwser in a limited time frame. Passing an exam gives you knowledge points; with enough knowledge points, you get the next belt, until the fabled black belt!One can also contribut

code coverage test

100% code coverage!

The basis of this article is a sequences of tweets betwen me and M. Robert Martin, on April 8th 2011: If you have 100% coverage you don’t know if your system works, but you do know that every line you wrote does what you thought it should.@unclebobmartin 100% code coverage doesn’t achieve anything, save making you safer while nothing could be further from the truth.@nicolas_frankel 100% code coverage isn’t an achievement, it’s a minimum requirement. If you write a line o

test

Cons of custom assertion matchers

Ten years ago, the only tests we knew of were users acceptance tests. The last decade saw a gigantic leap forward: it brought unit testing. Unit testing was made popular with JUnit. In turn, TestNG added annotations to the test classes, making them ever easier. Then, EasyMock provided the means to mock our class dependencies in a test context while Mockito streamlined the process of doing so. One could think everything has been said and done for unit testing and we should move forward to a more w

twitter

Java Twitter integration

During the writing of Learning Vaadin, I create a sample application step-by-step. This application is in fact a Twitter client. Twitter provides a nice API along with its related documentation in order to interact with their site. However, I’d rather deal with a Java API that shields me from all the griity details of the how to let me focus on the what. Hunting for such a component gave me Twitter4j. During my development with Twitter4j, I was stuck with the authentication process. This

identity openid

Identity federation and OpenId

Identity federation is a hot subject at this moment, at least for my customer. It began innocently enough: someone who did not belong to the organization needed to access an application. Not a problem, let’s register him. Some year later, needs number in thousands of users, and the identity management has outgrown its capacities: the software was sized for the organization, not for the myriad of third-party users around it. And yet, partners, customers and providers, they all have very va

quality sonar

Cost of correcting rule breaks

Last week, Simon Brandhof and Freddy Mallet of Sonar team and me were discussing Vaadin uses. At the end of our meeting, and although Vaadin finally did not fit their particular needs regarding Sonar, the talk disgressed toward quality. As regular Sonar users know, the former includes a very interesting plugin aptly named Technical Debt plugin. As a reminder: Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite