incubator-shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Borkowski <>
Subject Re: Problematic first steps with JSecurity
Date Sat, 18 Oct 2008 10:51:44 GMT

Thanks for tips. I will definitely try the new annoations.
Regarding other points:
When I think about enabling the default realm when there are no other realms
default - I think it is not bad to use this approach. The only missing thing
was explaining it - the quick start is probably the best place to mention

Now I'm trying to build some application with JSecurity and I had problem
with NullPointerException being thrown all the time. After long time I found
the reason: the Cache field is not set in AuthorizingRealm; (it tries
EHCache, and it gives up after not finding it on classpath). So when I call
the code then:

SecurityUtils.getSubject().login(new UsernamePasswordToken("empl1",

the method doGetAuthenticationInfo() from SimpleAccountRealm throws NPE
because of its second line:
SimpleAccount account = (SimpleAccount)
and getAuthorizatoinCache() return null.

I'm thinking about two solutions: change the doGetAuthenticationInfo() so
that it not use the Cache object (if it is possible) - or change the
deafault CachingSecurityManager to uses HashtableCache as default
implementation, not EHCache. I would vote for second solution, as this is
more aligned with JSecurity policy of "working out of the box with zero
configuration". And at miniumum it shouldn't throw NPE, but inform the user
about missing cache. I think I should post Jira ticket for this.

Another issue: if I define the DefaultSecurityManager as a Spring bean, why
it is not visible for SecurityUtils? Wouldn't be better if the constructor
of any SecurityManager register itself in SecurityUtils?
View this message in context:
Sent from the JSecurity Developer mailing list archive at

View raw message