JSecurity

Hi Todd,

Thanks for making us aware of the sessionMode bug! Thankfully the new config stuff we're working on has done away with that attribute (it still exists, just specified in a different place), so this won't be an issue for the upcoming final Release Candidate.

Initializing the securityManager by calling init() is definitely the correct way to get around this problem for now.

And as far as caching, there are a number of good options:

1) If you use Hibernate or JPA, typically its good to have those products utilize 2nd-level caching on your behalf so that every time you do a lookup, their 2nd-level cache will return the value instead of a round-trip to the RDBMS.

2) If you're not using Hibernate or JPA or similar framework with built-in caching, JSecurity does provide its own caching layer, but it is really a thin wrapper around any 3rd party caching framework that you might want to use. So, if you don't go with option #1, here's how I would do it:

You already subclass AuthorizingRealm, which has built-in support for caching. So you can do one of two things:

A. Before calling realm.init(), inject it with a org.jsecurity.cache.CacheManager instance. It will use that CacheManager to acquire a Cache instance which will be used to cache the acquired Account instances pulled from the DB. Note that doing it this way makes that CacheManager available to _only_ that Realm. You would have to manually inject the CacheManager into other realms if you have more than one or want to add more later.

For example:

DefaultRealm realm = new DefaultRealm();
EhCacheManager cacheManager = new EhCacheManager();
cacheManager.init();
realm.setCacheManager(cacheManager);
realm.init();


For a more 'hands off' approach, which doesn't require worrying about managing injecting CacheManagers for this or other potential future realms, the next approach is better:

B. The JSecurity SecurityManager implementations have built-in support for caching via a CacheManager instance, just like the Realm above. But when set on the SecurityManager (or when allowing the SecurityManager to implicitly create one automatically), that CacheManager will be used by all JSecurity components that can utilize it - the Authenticator, Authorizer, SessionManager, your Realms, etc. Because the SecurityManager delegates to these components, they all have access to the same CacheManager.

If ehcache.jar is in the classpath, the default SecurityManager implementations will try to build a CacheManager using Ehcache and then make that accessible to all of their children components (including your realm). So, if you drop ehcache.jar in the classpath, you can do this:

(first example):

DefaultRealm realm = new DefaultRealm(); //DON'T init() it yet, see below.
DefaultWebSecurityManager dwsm = new DefaultWebSecurityManager();
dwsm.setRealm( realm );
//this next call will automatically create an EhCacheManager and inject it
//into 'myRealm'.
dwsm.init();
//now that the CacheManager has been injected into the realm,
//this next init() call will acquire the cache used by that realm for Account objects:
realm.init();