I'm using Slide 2.1 beta, JBoss 3.2.5 (Tomcat 5.0.26), Java 1.4.2 on Windows XP SP 2.

I have now verified that the same error occurs using the J2EEStore with both MySQL 
(version 3 driver) and SQL Server 2000 (Opta2000 driver) adapters. I haven't managed 
to get plain JDBC stores to run in JBoss yet. It may not be significant, but I am 
using a non-Slide realm for authentication - authentication itself seems to work fine, 
and indeed I get no problems when I use the file stores.

I have traced back through the calls that lead to the exception and all seems in 
order. My guess is that the problem actually occurs when the ACL is added - I guess 
that no revision number is being inserted when the ACL is created, hence  
NodeRevisionNumber revisionNumber = permission.getRevisionNumber() returns null in 
StandardRDBMSAdapter.revokePermission().

However, I don't know enough about the schema structure to determine whether this is 
the case. How would I find the revisions of an ACL in the schema? Can you give me a 
clue about what I should be seeing in the database?

Cheers.

Patrick


-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Tue 10/5/2004 8:53 PM
To: Slide Users Mailing List
Subject: Re: Setting ACLs on a file via WebdavResource
 
Maybe I have already asked, but which version of Slide do you use? Maybe 
it can worth to try the latest from the 2.1 release branch. Trying MySQL 
sounds like a good idea as well.

Oliver

Patrick van Kann schrieb:
> The problem goes away if I use the standard TxFile stores (as in the out-of-the-box 
> distrib).
> 
> So it seems that this problem is specific to the either J2EEStore, 
> SQLServerRDBMSAdapter or the standard/abstract RDBMSadapters from which the 
> SQLServerAdapter is derived.
> 
> I am going to try:
> 1) Plain SQLServerAdapter (eliminate J2EEStore as the problem)
> 2) Plain MySQL (eliminate SQLServer as the problem).
> 
> I'll let you know what else I find out.
> 
> Thanks,
> 
> Patrick
> 
> 
> -----Original Message-----
> From: Patrick van Kann [mailto:[EMAIL PROTECTED]
> Sent: Tue 10/5/2004 3:30 PM
> To: Slide Users Mailing List
> Subject: RE: Setting ACLs on a file via WebdavResource
>  
> I don't know why revision number is null. I'm not sure what it has to do with me 
> setting permissions, unless the act of setting a permission is considered a 
> revision. 
> 
> What more could I do to assist in debugging this?
> 
> Patrick
> 
> 
> -----Original Message-----
> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
> Sent: Tue 10/5/2004 3:19 PM
> To: Slide Users Mailing List
> Subject: Re: Setting ACLs on a file via WebdavResource
>  
> Any idea why the revision number is null? It really should not...
> 
> Oliver
> 
> Patrick van Kann schrieb:
> 
> 
>>Thanks for all your help and suggestions. I have managed to resolve the issue with 
>>ACLs but have uncovered a slightly more troubling problem. The solution was to use
>>denyUser.setNegative( true ) for "/slide/users/john". There was no need to deny the 
>>other roles like user.
>>
>>However, I now find that I cannot delete a file once I have set any permissions on 
>>it. For example the code below:
>>
>>res.putMethod("/slide/files/testFile5.txt","test data");
>>Ace denyJohn = new Ace( "/slide/users/john" );
>>denyJohn.addPrivilege( Privilege.READ );
>>denyJohn.setNegative( true );                         
>>Ace[] aces = new Ace[1];
>>aces[0] = denyJohn;
>>res.aclMethod( "/slide/files/testFile5.txt" , aces );
>>res.deleteMethod("/slide/files/"+filename);
>>                              
>>Causes the following exception
>>14:46:54,162 INFO  [STDOUT] java.lang.NullPointerException
>>14:46:54,162 INFO  [STDOUT]     at org.apache.slide.store.impl.rdbms.StandardRDB
>>MSAdapter.revokePermission(StandardRDBMSAdapter.java:584)
>>14:46:54,162 INFO  [STDOUT]     at org.apache.slide.store.impl.rdbms.AbstractRDB
>>MSStore.revokePermission(AbstractRDBMSStore.java:481)
>>14:46:54,162 INFO  [STDOUT]     at org.apache.slide.store.AbstractStore.revokePe
>>rmission(AbstractStore.java:759)
>>14:46:54,162 INFO  [STDOUT]     at org.apache.slide.store.ExtendedStore.revokePe
>>rmission(ExtendedStore.java:658)
>>14:46:54,162 INFO  [STDOUT]     at org.apache.slide.security.SecurityImpl.revoke
>>Permission(SecurityImpl.java:383)
>>14:46:54,162 INFO  [STDOUT]     at org.apache.slide.macro.MacroImpl.deleteObject
>>(MacroImpl.java:814)
>>
>>Looking at the source for StandardRDBMSAdapter, it appears that the NullPointer is 
>>being thrown here:
>>statement.setString(4, revisionNumber.toString());
>>
>>I would guess this is because revisionNumber is null. 
>>
>>It might be worth pointing out that I can put and delete files where I have not set 
>>permissions as described above.
>>
>>I would value any suggestions as to why this is occuring.
>>
>>Thanks in advance
>>
>>Patrick
>>
>>
>>-----Original Message-----
>>From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
>>Sent: Tue 10/5/2004 8:18 AM
>>To: Slide Users Mailing List
>>Subject: Re: Setting ACLs on a file via WebdavResource
>> 
>>Sounds very reasonable! Besides me saying that the user may still have 
>>access because the role may if is not possible. Confusing...
>>
>>Oliver
>>
>>Tassos Bassoukos schrieb:
>>
>>
>>
>>>>Ace denyUser = new Ace( "/slide/roles/user" );
>>>>denyUser.addPrivilege( Privilege.READ );
>>>>denyUser.setNegative( false );
>>>
>>>
>>>Hi all,
>>>I don't know much about permissions yet, but should'nt the last line be
>>> denyUser.setNegative( true );
>>>?
>>>
>>>At least that's what I've undestood from reading the source.
>>>
>>>Cheers,
>>>Tassos Bassoukos
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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



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

Reply via email to