You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Felix Meschberger <fm...@gmail.com> on 2010/03/11 11:51:14 UTC

UserManager autosace issue

Hi,

Consier a UserManager not set to autosave mode. I do:

   Group g = userManager.createGroup(groupPrincipal);
   g.addMemmber(someUser);

This results in an InvalidItemStateException:

javax.jcr.InvalidItemStateException:
c0a1a731-9fea-34fa-aa78-d224bd58a981 has been modified externally
	at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1145)
	at
org.apache.jackrabbit.core.security.user.UserManagerImpl.setProtectedProperty(UserManagerImpl.java:581)
	at
org.apache.jackrabbit.core.security.user.GroupImpl.addMember(GroupImpl.java:151)

I assume this is because the addMember method calls Item.save() while
the parent node has not been saved yet.

Is this a known issue worth following up to ?

Thanks and Regards
Felix

Re: UserManager autosace issue

Posted by Guo Du <mr...@gmail.com>.
On Thu, Mar 11, 2010 at 10:51 AM, Felix Meschberger <fm...@gmail.com> wrote:
> I assume this is because the addMember method calls Item.save() while
> the parent node has not been saved yet.
>
> Is this a known issue worth following up to ?

It could be a bug as javax.jcr. Item.save() is @deprecated.

-Guo

Re: UserManager autosace issue

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,



On 11.03.2010 12:25, Angela Schreiber wrote:
> hi felix
> 
>> Consier a UserManager not set to autosave mode. I do:
>>
>>    Group g = userManager.createGroup(groupPrincipal)
>>    g.addMemmber(someUser);
>> This results in an InvalidItemStateException:
>>
>> javax.jcr.InvalidItemStateException:
>> c0a1a731-9fea-34fa-aa78-d224bd58a981 has been modified externally
>>     at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1145)
>>     at
>> org.apache.jackrabbit.core.security.user.UserManagerImpl.setProtectedProperty(UserManagerImpl.java:581)
>>
>>     at
>> org.apache.jackrabbit.core.security.user.GroupImpl.addMember(GroupImpl.java:151)
>>
>>
>> I assume this is because the addMember method calls Item.save() while
>> the parent node has not been saved yet.

The cause, as it turns out, is another thread modifying the group at the
same time as my code tries to add the member to the group. This
modification is part of our in-house application based on Jackrabbit.

This is not directly related to Jackrabbit (at the moment), though IMHO
Jackrabbit should probably be more lenient here ...

> 
> but why is the save method called? if you are *not* in
> autosave-mode the save-call should be omitted and you are
> in charge of calling session.save to persist the complete
> set of transient modifications anyway... strange.

Well, apparently the UserManager *is* in auto-save mode, since I did not
change it.

So it is out of my control whether the addMember calls save or not.

> 
>> Is this a known issue worth following up to ?
> 
> no, this isn't a known issue... can you check why
> Item.save() is called in the first place? and file
> a new JIRA issue if it's a bug in the user-management code.

As said above, the problem is probably not the user-management code
itself but something else.

So, sorry for the noise.

Regards
Felix

Re: UserManager autosace issue

Posted by Angela Schreiber <an...@day.com>.
hi felix

> Consier a UserManager not set to autosave mode. I do:
> 
>    Group g = userManager.createGroup(groupPrincipal)
>    g.addMemmber(someUser);
> This results in an InvalidItemStateException:
> 
> javax.jcr.InvalidItemStateException:
> c0a1a731-9fea-34fa-aa78-d224bd58a981 has been modified externally
> 	at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1145)
> 	at
> org.apache.jackrabbit.core.security.user.UserManagerImpl.setProtectedProperty(UserManagerImpl.java:581)
> 	at
> org.apache.jackrabbit.core.security.user.GroupImpl.addMember(GroupImpl.java:151)
> 
> I assume this is because the addMember method calls Item.save() while
> the parent node has not been saved yet.

but why is the save method called? if you are *not* in
autosave-mode the save-call should be omitted and you are
in charge of calling session.save to persist the complete
set of transient modifications anyway... strange.

> Is this a known issue worth following up to ?

no, this isn't a known issue... can you check why
Item.save() is called in the first place? and file
a new JIRA issue if it's a bug in the user-management code.

thanks
angela
> Thanks and Regards
> Felix
>