In the standard TxFile stores null permissions (which cause the NPE not the revision number) do not cause problems, but do in the db stores.
I have committed changes both the the CVS head and the 2.1 release branch that simply add a check at the beginning of revokePermission:
if (permission == null) return;
Would be great if you checked if this works for you.
Oliver
Patrick van Kann schrieb:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
