I tried it again - moving the UserSecurityAdvice.afterReturning() code to the
UserManager and it worked this time. I had to adjust the UserManagerTest
class as well to get the tests to run. The UserCache mocks were expecting
the code to call removeFromCache once, but the code in the UserManager was
not making the call unless the user object had a version user.setVersion()
had to be called in the set up of the user db objects and then all is good.

I've noticed that when permissions are removed from a user, the refresh time
is definitely slower than when adding permissions.

Does anyone have an idea as to why?

Thanks,

Tony

tonyl wrote:
> 
> Hmm - someone here then must have added it. OK - I tried to move the code
> from UserSecurityAdvice to the UserManagerImpl and the code didn't work.
> Not sure why. So I've left it in SecurityAdvice for the moment.
> 
> Thanks.
> 
> 
> 
> mraible wrote:
>> 
>> In the 1.9.x code I'm looking at, there's no userCache being injected
>> into
>> UserManagerImpl.java:
>> 
>>     /**
>>      * @see
>> org.appfuse.service.UserManager#saveUser(org.appfuse.model.User)
>>      */
>>     public void saveUser(User user) throws UserExistsException {
>>         // if new user, lowercase userId
>>         if (user.getVersion() == null) {
>>             user.setUsername(user.getUsername().toLowerCase());
>>         }
>>         try {
>>             dao.saveUser(user);
>>         } catch (DataIntegrityViolationException e) {
>>             throw new UserExistsException("User '" + user.getUsername() +
>> "'
>> already exists!");
>>         }
>>     }
>> 
>>     /**
>>      * @see org.appfuse.service.UserManager#removeUser(java.lang.String)
>>      */
>>     public void removeUser(String userId) {
>>         if (log.isDebugEnabled()) {
>>             log.debug("removing user: " + userId);
>>         }
>> 
>>         dao.removeUser(new Long(userId));
>>     }
>> 
>> As far as removing UserSecurityAdvice - there's probably not an issue
>> with
>> that.  It's main purpose right now is to prevent someone from saving the
>> form locally, modifying the HTML to give themselves the admin role, and
>> then
>> submitting it back.  It was easier to do this logic in AOP rather than
>> doing
>> it in the web tier for each framework.
>> 
>> Matt
>> 
>> On 3/2/07, tonyl <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>> Matt,
>>>
>>> I understand the purpose of the cache - it is certainly a good idea to
>>> not
>>> have to hit the database all the time. But actually, there is a
>>> userCache
>>> instance injected into the UserManager. It is used in removeUser and
>>> saveUser. I'd prefer to move the code from UserSecurityAdvice into
>>> UserManagerImpl and have it all in one place so that we can remove the
>>> UserSecurityAdvice completely from the code base. We are handling the
>>> security checks that UserSecurityAdvice.before() is doing in other ways
>>> now
>>> - specifically through the security.xml and in our application it is OK
>>> for
>>> a user to upgrade to admin role - we are allowing this through groups
>>> since
>>> a group can have admin privileges.
>>>
>>> Thanks,
>>>
>>> Tony
>>>
>>>
>>> mraible wrote:
>>> >
>>> > The userCache is not injected into UserManager, only
>>> > UserSecurityAdvice.  It's also used by Acegi and basically maintains a
>>> > cache of the users.  UserSecurityAdvice uses it to expire cache items
>>> > when a user is updated.  Now that we use our own Dao (instead of
>>> > Acegi's), it may be possible to remove this and rely on Hibernate's
>>> > 2nd level cache.
>>> >
>>> > At the very least, this cache prevents Acegi from hitting the database
>>> > for every request when the user information is not stored in the
>>> > session (which is an option).
>>> >
>>> > Matt
>>> >
>>> > On 3/1/07, tonyl <[EMAIL PROTECTED]> wrote:
>>> >>
>>> >> I haven't been able to find any clear explanations of the userCache -
>>> >> what it
>>> >> is, why use it, etc. And I really don't understand the purpose of
>>> having
>>> >> a
>>> >> userCache in 2 places.
>>> >>
>>> >> What's going on?
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Tony
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://www.nabble.com/Why-is-userCache-in-userManager-and-UserSecurityAdvice--tf3327560s2369.html#a9251684
>>> >> Sent from the AppFuse - User mailing list archive at Nabble.com.
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > http://raibledesigns.com
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> > For additional commands, e-mail: [EMAIL PROTECTED]
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Why-is-userCache-in-userManager-and-UserSecurityAdvice--tf3327560s2369.html#a9272040
>>> Sent from the AppFuse - User mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>> 
>> 
>> -- 
>> http://raibledesigns.com
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Why-is-userCache-in-userManager-and-UserSecurityAdvice--tf3327560s2369.html#a9335184
Sent from the AppFuse - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to