I created an issue to track this thread of conversation: https://issues.apache.org/jira/browse/JSEC-40
I also committed an initial CacheManager implementation that should be used as the default instead of EhCache: org.jsecurity.cache.DefaultCacheManager. It uses SoftHashMap caches, which are maps that use SoftReferences to maintain the map values. This provides us a production-capable memory-constrained cache, as opposed to Hashtables which are likely to lead to OutOfMemoryExceptions. Lemme know what you think. The next step that we should decide on is - should we even provide a default CacheManager implementation? Should caching be something that a user is forced to turn on manually via configuration? Cheers, Les On Fri, Nov 7, 2008 at 12:32 PM, Jeremy Haile <[email protected]> wrote: > I agree with this - stick with dependency for 0.9 and open a JIRA issue for > 1.0 to finish discussing and make any changes. Too late in the game to make > this kind of change for 0.9 IMO. > > > > On Nov 7, 2008, at 12:18 PM, Alan D. Cabrera wrote: > > Agreed. What to do tactically for v0.9? I think that since EHCache was >> the default cache for RC1-3 we should stick with it. Following the same >> lines of reasoning SimpleAccountRealm should also stay the same for v0.9. >> So, all that remains to be done is to put ehcache back into the v0.9 line. >> >> All of this will, of course, be fixed for the v1.0 release. >> >> Thoughts? >> >> Regards, >> Alan >> >> >> >> On Nov 7, 2008, at 8:15 AM, Jeremy Haile wrote: >> >> Yeah, I think that if I dropped JSecurity into my project, I wouldn't >>> expect it to work out of the box with no configuration whatsoever. I >>> certainly wouldn't expect to see it firing up a realm and loading in users >>> and passwords loaded from the JAR. >>> >>> If we DO want to support that sort of scenario at all (perhaps for >>> quickly getting projects up and running, etc.) - then I think we could just >>> allow users to set a flag like enable.test.realm=true. >>> >>> I like making JSecurity easy to setup right out of the box in a minimal >>> way, but don't feel comfortable having it magically work with no >>> configuration - and having the user not even know where it's loading >>> usernames and passwords from. I think we could make it as simple to setup >>> as saying "realm=file, file=user.properties" or whatever. Bam - two config >>> properties and you're up and running - and now there's no magic or confusion >>> involved in where the data or realm is coming from. >>> >>> On Nov 7, 2008, at 11:08 AM, Alan D. Cabrera wrote: >>> >>> Yeah, I dug up that conversation and re-read it. I agree, >>>> SimpleAccountRealm needs to be reworked. I also agree that there should be >>>> no default realm. Having default realms, in the security world, strikes me >>>> as scary. Though I do see that it's compelling to have something totally >>>> work out of the box, I think that in this case the easy of use argument as >>>> crossed the line. >>>> >>>> >>>> Regards, >>>> Alan >>>> >>>> >>>> >>>> On Nov 7, 2008, at 7:49 AM, Jeremy Haile wrote: >>>> >>>> We initially made the decision to not fallback to HashtableCacheManager >>>>> because it is not suitable for a production environment. So, if you put >>>>> EhCache in your classpath then it uses that, otherwise it disables >>>>> caching. >>>>> >>>>> However - I think SimpleAccountRealm, etc. depending on a cache >>>>> implementation is probably wrong. Those realms should definitely fall >>>>> back >>>>> to using a hashtable or something else, probably printing out appropriate >>>>> warnings. (e.g. WARN - Falling back to Hashtable implementation. This is >>>>> NOT suitable for production environments. Instead, enable a CacheManager >>>>> implementation - see JSecurity documentation for details) >>>>> >>>>> In fact, I really don't like the fact that JSecurity has a default >>>>> realm at all - I think the user should have to specify something, even if >>>>> we >>>>> make it extremely easy. (e.g. setting a single property to enable the >>>>> default realm) >>>>> >>>>> Thoughs? >>>>> >>>>> Jeremy >>>>> >>>>> >>>>> On Nov 7, 2008, at 5:04 AM, Peter Ledbrook wrote: >>>>> >>>>> This class attempts to use EhCacheManager as the default cache >>>>>>> manager, if >>>>>>> Ehcache is in the classpath. If it's not, then there is no cache >>>>>>> manager. >>>>>>> This breaks SimpleAccountRealm and anything that inherits from it, >>>>>>> i.e. >>>>>>> PropertiesRealm, the default realm. So, if Ehcache is not in the >>>>>>> classpath, >>>>>>> the default behavior of JSecurity is broken. >>>>>>> >>>>>>> IMO, we should either make a hard dependency on Ehcache or make >>>>>>> HashtableCacheManager the default cache manager. >>>>>>> >>>>>> >>>>>> I think it makes sense to fall back to HashtableCacheManager as the >>>>>> default. It might also be worth considering taking a leaf out of the >>>>>> SLF4J book and having an adapter jar such as "ehcache-manager.jar" >>>>>> that users can depend on or not. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Peter >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >
