On Nov 9, 2008, at 12:59 PM, Grzegorz Borkowski wrote:
Grzegorz Borkowski wrote:
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",
"pass1"));
the method doGetAuthenticationInfo() from SimpleAccountRealm throws
NPE
because of its second line:
SimpleAccount account = (SimpleAccount)
getAuthorizationCache().get(upToken.getUsername());
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.
In the meantime similar issue was raised:
https://issues.apache.org/jira/browse/JSEC-24
So I've added the link to this conversation to that issue.
I think your opinions are spot on with regards to the default realm
and the added dependency.
At the moment, the current thinking is that we put EHCache back for
v0.9 and push it out the door. Then for v1.0 we move in the direction
that Les started and move EHCache out, we make sure that there is no
default realm, and we fix SimpleAccountRealm to not totally depend on
the cache.
Other things I think should be slated for v1.0:
- make sure that there's no default realm
- remove the way PropertiesRealm has that default properties file,
default-jsecurity-users.properties
- there should be no default cache at all and everything should work
fine that way
Regards,
Alan
