You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Ian Boston <ie...@tfd.co.uk> on 2009/08/27 11:48:15 UTC

InternalError in UserAccessControlProvider

Hi,
JR 1.5.6

I am getting an "Internal Error" from the UserAccessControlProvider  
traced with a debugger to line
UserAccessControlProvider .java:506 where the code says

              } catch (RepositoryException e) {
                     // should never get here
                     log.error("Internal error ", e.getMessage());
                 }

On inspection the error is
javax.jcr.InvalidItemStateException: c86bf464-509e-4e8a-808a- 
fd729cef0be9: the item does not exist anymore

Users are being created and deleted from the security workspace when  
this is happening.

Although the comment says it should not happen, it does, regularly.

Is it anything to be concerned about ?

Thanks
Ian

Re: InternalError in UserAccessControlProvider

Posted by Ian Boston <ie...@tfd.co.uk>.
On 27 Aug 2009, at 14:03, Tobias Bocanegra wrote:

> it would be better if you create a junit test case for jackrabbit -
> because we don't use sling for testing.
> regards, toby


Ok, I will have a go at isolating the issue.
Ian

Re: InternalError in UserAccessControlProvider

Posted by Tobias Bocanegra <tr...@day.com>.
On Thu, Aug 27, 2009 at 12:15 PM, Ian Boston<ie...@tfd.co.uk> wrote:
>
> On 27 Aug 2009, at 11:08, Stefan Guggisberg wrote:
>
>>> Is it anything to be concerned about ?
>>
>> without knowing the code in question, i think, yes. the code obviously
>> assumes
>> that this situation should never happen. however, if it does, i guess
>> it's a bug.
>
> This is Sling with some modifications/enhancements/additions.
> Although I have made modifications to other areas of the non-securirty
> access control structure, I dont think I have made any to the
> UserManagerImpl or the UserAccesControlProvider which are direct from the
> 1.5.6 jackrabbit jar.
>
> The test that reproduces this is a Ruby script running outside the JVM,
> single threaded, exercising the Sling http user manager endpoints.
>
> If its a real problem (from your response, I guess it is) I will try and
> reproduce against an unmodified Sling with a simple bash/curl script.
it would be better if you create a junit test case for jackrabbit -
because we don't use sling for testing.
regards, toby

Re: InternalError in UserAccessControlProvider

Posted by Ian Boston <ie...@tfd.co.uk>.
On 27 Aug 2009, at 11:08, Stefan Guggisberg wrote:

>> Is it anything to be concerned about ?
>
> without knowing the code in question, i think, yes. the code  
> obviously assumes
> that this situation should never happen. however, if it does, i guess
> it's a bug.

This is Sling with some modifications/enhancements/additions.
Although I have made modifications to other areas of the non-securirty  
access control structure, I dont think I have made any to the  
UserManagerImpl or the UserAccesControlProvider which are direct from  
the 1.5.6 jackrabbit jar.

The test that reproduces this is a Ruby script running outside the  
JVM, single threaded, exercising the Sling http user manager endpoints.

If its a real problem (from your response, I guess it is) I will try  
and reproduce against an unmodified Sling with a simple bash/curl  
script.

Thanks,
Ian

Re: InternalError in UserAccessControlProvider

Posted by Stefan Guggisberg <st...@gmail.com>.
hi ian

On Thu, Aug 27, 2009 at 11:48 AM, Ian Boston<ie...@tfd.co.uk> wrote:
> Hi,
> JR 1.5.6
>
> I am getting an "Internal Error" from the UserAccessControlProvider traced
> with a debugger to line
> UserAccessControlProvider .java:506 where the code says
>
>             } catch (RepositoryException e) {
>                    // should never get here
>                    log.error("Internal error ", e.getMessage());
>                }
>
> On inspection the error is
> javax.jcr.InvalidItemStateException: c86bf464-509e-4e8a-808a-fd729cef0be9:
> the item does not exist anymore
>
> Users are being created and deleted from the security workspace when this is
> happening.
>
> Although the comment says it should not happen, it does, regularly.
>
> Is it anything to be concerned about ?

without knowing the code in question, i think, yes. the code obviously assumes
that this situation should never happen. however, if it does, i guess
it's a bug.

cheers
stefan

>
> Thanks
> Ian
>