It's difficult to unit test classes that call directly to SecurityContextHolder.getContext(). I would rather have a SecurityContextHolderStrategy property in my POJO that is injected. Since SCHS is an interface, unit testing the POJO would be much simpler because a mock SCHS can be used to test with (and therefore a mock SecurityContext, a mock Authentication, etc).
A static getter method would allow me to pull the call to SecurityContextHolder.getContext() into spring config using 'factory-method' attribute, something like this:
<bean id="fooPOJO" class="org.foo.Foo">
<property name="securityContextHolderStrategy" >
I've always been a little puzzled by the widespread practice of directly calling SecurityContextHolder.getContext() from within Java code. Having to call a static method and to access static, vm-wide state directly like that is exactly the sort of thing that dependency injection, and Spring, is supposed to help a developer avoid doing.
Just so I'm completely clear, let me review the pain of unit testing a class that directly calls SecurityContextHolder.getContext(). If you want to unit test with a mock SecurityContext instance, you have to set that mock instance directly on the SecurityContextHolder, then remember to clean it up during test tear down because it's global, vm-wide state. If your test is running in a large suite of other tests, you may even have to record the current state of SecurityContextHolder.getContext() before setting your mock, then remember to restore the original state because tests later on may be relying on it. Obviously that's both ugly and error-prone. These are all well-understood downsides to having an API based on static methods. On the other hand, if my POJO were to instead have a SecurityContextHolderStrategy property that was injected, unit testing it becomes much cleaner.