Majority of the modern Java EE developers appreciate and hug the concept of IoC (Inversion of Control), popularized by Spring Framework. It is not just due to the hype, but because of pragmatic benefits that are achievable through the concept. With IoC, developers can easily swap in and out implementations behind an interface at deployment, without having to compile and re-build the entire project.
However, there are situations where existing IoC frameworks cannot be used. One such situation I recently faced was with JAAS Login Modules.
When authentication is considered, it is a common and secure practice to encrypt (ideally to one way hash) stored passwords. There are dizzillions of different algorithms out there for encryption. Actual algorithm to use for this purpose usually differs from situation to situation, depending on requirements / choices of clients, etc. So this is an ideal situation where the “strategy” design pattern can be applied, and application IoC would rise and shine.
Nevertheless, instantiation of a login module is normally done by the Application Server (JBoss in this example). So it is not straight-forward to utilize a IoC framework at this point. However, the good news is that LoginModules come out with a handy feature which could be easily exploited to facilitate the IoC concept.
The well known module-option feature provides the ground-work for adding up some IoC magic to our old login modules. When mixed up with Java Reflection API, this is more than enough to decouple the login module from implementation details of various encryption algorithms.