Month: June 2009

The Key to Maintenance is Compartmentalisation

Over the last couple of large projects I have noticed a trend in the way software developers/engineers/architects like to come out with statements like "that code is shit". I'm not just talking about me saying it, or how they react to the code that I write (come on, I write great code!). But general sweeping statements like this crop up all the time on these projects, related to everyones code. And managers then perpetuate these statements. I think the reason is easy to understand. When a developer takes over responsibility for some code they want to make it clear that any problems with that code are unrelated to them. They don't want to take responsibility for the code which someone else has written. Because writing code is inherently creative and the same functionality can be written many different ways, you are almost guaranteed that a developer taking over some code "would have written it differently". What I have also noticed is that the developers coming out with statements like this do not know or do not want to understand the conditions under which the code was originally written. As an architect, I realise there are many many factors which influence the creation of code, budget being a major one. What some developers also do not fully appreciate is that the perfect implementation not only doesn't exist (because every developer would do it differently) but that it often isn't required. The perfect solution considers many cases which don't need to be…

Read more

Java EE Security and Spring

Spring Security (originally ACEGI) does not seem to work out of the box with Java EE security (see here). I guess the reason is clear, namely that the people from Spring don't want you to be tied into Java EE and that makes sense because Spring something that you can use without Java EE. But instead of having to learn something new and instead of having to configure my security in a non-standard way, I wanted a way to ensure my services are only called by someone with the right authorization, exactly when they are deployed in a Java EE environment. Since a standard web application running in a Java EE container can be configured to have security, I expected to be able to configure Spring to use the web request to check the Principal for its security roles before calling a service, but that isn't possible. So, I set to work to quickly create a little library to help me out. The first step was to implement a Filter in the web application so that it could intercept every call and insert the web request (containing the Principal) into a ThreadLocal variable. The idea was that the ThreadLocal variable could then be used further up the call stack to query the security roles of the authenticated user. The filter implementation looks like this:     public void doFilter(             ServletRequest request,             ServletResponse response,             FilterChain chain)             throws IOException, ServletException {          //set the request in the security…

Read more