UserManager API strangeness

[Felix Meschberger <fm...@gmail.com>]

Hi,

Forgive me if this has been discussed before (yes, I know I should RTFM
and list archives).

I see the UserManager interface has an autoSave(boolean) method, which
must be called to have the user manager persist any created users and
groups immediately after creation. The setup can also be asked by
calling the isAutoSave() method.

So far, so good.

What strikes me is, that to actually persist changes made by the
UserManager, the Session.save() method must be called. IMHO for a proper
level of alignment, the UserManager should probably be extended with
save() and rollback() methods.

WDYT ?

Regards
Felix

Re: UserManager API strangeness

[Felix Meschberger <fm...@gmail.com>]

Hi,

On 11.03.2010 12:14, Angela Schreiber wrote:
> hi
> 
>> What strikes me is, that to actually persist changes made by the
>> UserManager, the Session.save() method must be called. IMHO for a proper
>> level of alignment, the UserManager should probably be extended with
>> save() and rollback() methods.
> 
> i don't think this is required.
> 
> JSR 283 defines other managers that need their changes persisted
> using Session.save() (e.g. AccessControlManager and RetentionManager),
> which are both obtained from the Session similar to the UserManager.
> (in contrast to those managers that are obtained from Workspace
>  that do NOT require a session.save).

While I might not agree that they don't have a save method (it just
sounds strange, that you have a manager where you apply changes and then
have to revert back to the session to persist), I agree that for
consistency, it thus makes sense the UserManager does not have a save
method.

> 
> the real problem is that we originally had a UserManager
> that stored the changes in a separate workspace in which case
> there is no way to persist the changes with a call to save()
> on the session you obtained the user manager from. and for
> backwards-compatibility i didn't want to drop that old
> user manager... that's about it and the only reason for
> adding the autosave functionality....

Thanks for the clarification.

Regards
Felix

Re: UserManager API strangeness

[Angela Schreiber <an...@day.com>]

hi

> What strikes me is, that to actually persist changes made by the
> UserManager, the Session.save() method must be called. IMHO for a proper
> level of alignment, the UserManager should probably be extended with
> save() and rollback() methods.

i don't think this is required.

JSR 283 defines other managers that need their changes persisted
using Session.save() (e.g. AccessControlManager and RetentionManager), 
which are both obtained from the Session similar to the UserManager.
(in contrast to those managers that are obtained from Workspace
  that do NOT require a session.save).

the real problem is that we originally had a UserManager
that stored the changes in a separate workspace in which case
there is no way to persist the changes with a call to save()
on the session you obtained the user manager from. and for
backwards-compatibility i didn't want to drop that old
user manager... that's about it and the only reason for
adding the autosave functionality....

angela