Quoting Christopher Lenz <[EMAIL PROTECTED]>:
> well, that doesn't seem to be the actual problem here.
>
> I'm having a hard time tracking the problem down... I think it's
> something to do with the caching performed by StandardStore, but
> that's a shot in the dark actually.
>
> the permission that fails to get created is "/-root-/actions-true"
> (and I assume any other permission on the root node would fail too).
> SecurityImpl.grantPermission() _does_ check whether the permission
> already exists, but JDBCDescriptorsStore.enumeratePermissions() is
> never called at that point, instead the enumeration that is used for
> the comparison only contains "/-/-/-true" (i.e. the temporary all-
> access permission).
>
> btw: the ServiceAccessException thrown by the JDBC driver at this
> point is caught at servlet-level, it seems it should be caught quite a
> bit earlier (XMLUnmarschaller maybe?). in addition, it leaves the
> database in a bad state because the /tempaction object and the /-/-/
> permission both still exist (those get created/removed outside of the
> transaction).
Ok, it seems that something really bad happens here. I guess we could add a
check in the standard store, but I don't like that solution too much (since
it's supposed to be pluggable, I don't want people to have to remember that
they have to check for this at that time.
Maybe it's a cache problem as you mentioned but I'm not 100% sure.
Remy
