使用注入的bean方法的返回值作为@Cacheable批注中的键

Question

I have an @Cacheable annotated method in one of my beans, and I'd like to use the currently logged in user ID as the key for the Cache. However, I'm using Spring Security and have an Injected service as an instance variable in this bean that calls SecurityContextHolder.getContext().getAuthentication() to return the user ID. Hence, I have a zero-argument constructor on the @Cacheable method. Is there anyway to use the user ID returned from my injected service's method as the key for the Cache?

@Service
public class MyServiceImpl implements MyService {

@Inject
private UserContextService userContextService;

@Override
@Cacheable("myCache")
public String getInformation() {
  //use this as the key for the cache entry
String userId = userContextService.getCurrentUser();
return "something";
}
}

UserContextService implementation:

@Service
public class UserContextServiceImpl implements UserContextService {

public String getCurrentUser() {
return SecurityContextHolder.getContext().getAuthentication().getName();
}

}

I found this question, but it's somewhat different from what I'd like to do. I don't think this functionality is possible with a static method.

Using Spring beans as a key with @Cacheable annotation

Answer 1

I would write this class so that the userId was an argument to the getInformation() method, and make users of the method/service pass lookup the ID themselves.

@Override
@Cacheable("myCache")
public String getInformation(String userId) { ... }

IMO it's a bad practice to write your service-layer to use the Spring Security context directly, as it limits the usefulness of the service - if you implement some sort of REST API that doesn't use Spring Security (just as an example), then getCurrentUser() might have no meaning / return value. Then MyServiceImpl is unusable if Spring Security is not used for that request, and this method is unusable if you ever need to support something like "admin user needs to look up information for user X".

Let the web-facing layer worry about how to extract the userid from the security context, rather than your service layer.