Ten Things You Can Do With Spring Security

One

You can specify the authorisation provider of your choice in your Spring XML config file. You do this by configuring an authentication-manager as defined in Spring’s http://www.springframework.org/schema/security/spring-security-3.1.xsd schema. The simplified authentication-manager element definition looks something like this:

<xs:element name="authentication-manager">
 <xs:complexType>
  <xs:choice minOccurs="0" maxOccurs="unbounded">
   <xs:element name="authentication-provider">
    <xs:complexType>
     <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:element ref="security:any-user-service"/>
      <xs:element name="password-encoder">...</xs:element>
     </xs:choice>
     <xs:attributeGroup ref="security:ap.attlist"/>
    </xs:complexType>
   </xs:element>
   <!-- This is BIG -->
   <xs:element name="ldap-authentication-provider">...</xs:element>
  </xs:choice>
  <xs:attributeGroup ref="security:authman.attlist"/>
 </xs:complexType>
</xs:element>

This means that, for example, you can use any number of authentication providers including basic authentication and JDBC authentication as shown in the snippet below:

CaptainDebug Wins an Award

Yes, you heard it here first, I’ve won an award for a program that I’ve written. I can safely say that I’ve never won an award for any program I’ve ever written in my life, in fact this is the only competition in which any of my code has been nominated

What, you may ask what have I won?

Is Programming the Art of Making the Right Decision?

If you’ve read my previous blog on using Explicit Locking, you may remember that I wrote some sample code that transferred cash between two random bank accounts using the following algorithm:

IF fromAccount is locked THEN
    IF toAccount is locked THEN
        withDraw money from the fromAccount
        deposit money into the toAccount
    END IF
END IF

You may also remember that this was multithreaded code originally written to create a deadlock. In order to demonstrate Explicit Locking’s Lock interface and ReentrantLock implementation I needed to add a thread locking mechanism to my straight-forward Account POJO and so, the question was: how should I do this?

Investigating Deadlocks – Part 5: Using Explicit Locking

In my last Investigating Deadlocks blog I looked at fixing my broken, deadlocking balance transfer sample code using both Java’s traditional synchronized keyword and lock ordering. There is, however, an alternative method known as explicit locking.

The idea here of calling a locking mechanism explicit rather than implicit is that the explicit means that it is not part of the Java language and that classes have been written to fulfill the locking functionality. Implicit locking, on the other hand, can be defined as locking that is part of the language and is implemented in the background using the language keyword synchronchized.

You could argue as to whether or not explicit locking is a good idea. Shouldn’t the Java language be improved to include the features of explicit locking rather than adding yet another set of classes to the already enormous API? For example: trysynchronized().

Explicit locking is based around the Lock interface and its ReentrantLock implementation. Lock contains a bunch of methods that give you lots more control over locking than the traditional synchronized keyword.