Re: Slide search performance issues
Hi Pontus , I have the same trouble, i work with 1 documents ... so if i found any solution or explication i will take you part. I have an another question , how do you created your own property , because when i created a property with proppatch i was enable to specify the Namespace webdav. Have you got a little exemple of specific property creation and how to have this property ? Thanks a lot ! CF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide search performance issues
Hi Cdric, To add a custom property is really rather simple. First you must create a PropertyName object, like this: PropertyName propName = new PropertyName(DAV:, my_property_name); Next you have to use the setPath-method and the proppatchMethod in the WebdavResource class, like this: webdavResource.setPath(path_to_document_or_directory); webdavResource.proppatchMethod(propName, my_property_value, true); More details on these classes can be found in the javadoc. I hope this help you. The total lack of responses regarding the performance issues so far give me little hope that there is a solution, at least a simple solution. We are currently evaluating our options as how to proceed, currently we are looking into bypass Slide when searching. Regards, Pontus -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Cdric Sent: Wednesday, January 12, 2005 10:25 AM To: slide-user@jakarta.apache.org Subject: Re: Slide search performance issues Hi Pontus , I have the same trouble, i work with 1 documents ... so if i found any solution or explication i will take you part. I have an another question , how do you created your own property , because when i created a property with proppatch i was enable to specify the Namespace webdav. Have you got a little exemple of specific property creation and how to have this property ? Thanks a lot ! CF - 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]
Question - is ACL negotiation unchangeable w/ competing rights ?
Hi If a resource (document) in Slide has an ACL with multiple entries for the same principal, the spec (as I recall it) says that the lesser permission is applied to requests. ie, if user has read-only access as a member of one group, and read-write as a member of another group, both of which are named in the resource's ACL, then the user is given only the lesser (read-only). Is there a way to modify this behaviour, ie, such that either the first or last permission is applied ? Ideas ? Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Litmus propget problem
I'm playing with litmus (http://www.webdav.org/neon/litmus/) to do some basic testing against our Slide-WCK fronted archive. All of the propget props tests are failing. I'm running Slide HEAD from about 3 weeks ago (roughly 2.2-pre1). I'm running this on Jetty 4.2.19 and Sun's J2SDK 1.4.2_06. The propget tests send a request that looks like: PROPFIND /fcfs_data/litmus/prop HTTP/1.1 Host: localhost:8081 User-Agent: litmus/0.10.1 neon/0.25.0-dev Connection: TE TE: trailers Depth: 0 Content-Length: 581 Content-Type: application/xml X-Litmus: props: 7 (propget) ?xml version=1.0 encoding=utf-8? propfind xmlns=DAV:prop prop0 xmlns=http://webdav.org/neon/litmus// prop1 xmlns=http://webdav.org/neon/litmus// prop2 xmlns=http://webdav.org/neon/litmus// prop3 xmlns=http://webdav.org/neon/litmus// prop4 xmlns=http://webdav.org/neon/litmus// prop5 xmlns=http://webdav.org/neon/litmus// prop6 xmlns=http://webdav.org/neon/litmus// prop7 xmlns=http://webdav.org/neon/litmus// prop8 xmlns=http://webdav.org/neon/litmus// prop9 xmlns=http://webdav.org/neon/litmus// /prop/propfind The response is: HTTP/1.1 400 Bad+Request%3A+Invalid+child+%5BNamespace%3A+prefix+%22%22+is+mapped+to+URI+%22DAV%3A%22%5D%3Afoobar+of+root+element+DAV%3Apropfind Date: Wed, 12 Jan 2005 18:16:58 GMT Server: Jetty/4.2.19 (Linux/2.4.20-31.9 i386 java/1.4.2_06) Expires: Thu, 01 Jan 1970 00:00:00 GMT Set-Cookie: JSESSIONID=1gkn6uk9p0iiv;Path=/ Content-Type: text/html Content-Length: 1468 html head titleError 400 Bad+Request%3A+Invalid+child+%5BNamespace%3A+prefix+%22%22+is+mapped+to+URI+%22DAV%3A%22%5D%3Afoobar+of+root+element+DAV%3Apropfind/title /head body h2HTTP ERROR: 400 Bad+Request%3A+Invalid+child+%5BNamespace%3A+prefix+%22%22+is+mapped+to+URI+%22DAV%3A%22%5D%3Afoobar+of+root+element+DAV%3Apropfind/h2 pRequestURI=/fcfs_data/litmus/prop/p pismalla href=http://jetty.mortbay.org;Powered by Jetty:///a/small/i/p /body /html For those of you that can't read URL encoding, the message translates to: Bad Request: Invalid child [Namespace: prefix is mapped to URI DAV:]:foobar of root element DAV:propfind I'm using the default XML parser that comes with the Sun VM. Any ideas? Is this a slide bug or a litmus bug? A quick google showed some valid WebDAV requests that look just like what litmus is sending. Thanks -John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question - is ACL negotiation unchangeable w/ competing rights ?
I read the spec at http://www.greenbytes.de/tech/webdav/rfc3744.html#acl.evaluation such that the order is important and not strictness. Slide code says the same. Oliver On Wed, 12 Jan 2005 13:15:16 -0500, Nick Longinow [EMAIL PROTECTED] wrote: Hi If a resource (document) in Slide has an ACL with multiple entries for the same principal, the spec (as I recall it) says that the lesser permission is applied to requests. ie, if user has read-only access as a member of one group, and read-write as a member of another group, both of which are named in the resource's ACL, then the user is given only the lesser (read-only). Is there a way to modify this behaviour, ie, such that either the first or last permission is applied ? Ideas ? Nick - 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]
Re: [litmus] Litmus propget problem
John Rousseau wrote:
I'm playing with litmus (http://www.webdav.org/neon/litmus/) to do some
basic testing against our Slide-WCK fronted archive. All of the
propget props tests are failing. I'm running Slide HEAD from about 3
weeks ago (roughly 2.2-pre1). I'm running this on Jetty 4.2.19 and Sun's
J2SDK 1.4.2_06.
...
For those of you that can't read URL encoding, the message translates to:
Bad Request: Invalid child [Namespace: prefix is mapped to URI
DAV:]:foobar of root element DAV:propfind
I'm using the default XML parser that comes with the Sun VM.
Any ideas? Is this a slide bug or a litmus bug? A quick google showed
some valid WebDAV requests that look just like what litmus is sending.
Judging from the error message, it seems that it's really a different
request that's causing this, namely the one in props.c:
static int propextended(void)
{
return propfind_returns_wellformed(with extended propfind element,
XML_DECL propfind
xmlns=\DAV:\foobar/
allprop//propfind);
}
...in which case the answer is: it's a bug in Slide: unknwon extension
elements in request bodies aren't ignored (as required by RFC2518).
Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [litmus] Litmus propget problem
Julian Reschke wrote:
...
Judging from the error message, it seems that it's really a different
request that's causing this, namely the one in props.c:
static int propextended(void)
{
return propfind_returns_wellformed(with extended propfind element,
XML_DECL propfind
xmlns=\DAV:\foobar/
allprop//propfind);
}
...in which case the answer is: it's a bug in Slide: unknwon extension
elements in request bodies aren't ignored (as required by RFC2518).
Best regards, Julian
Actually, this looks very similar to the following issue...:
http://forums.tamino.com/3/OpenTopic?a=tpcs=153292895f=2382994291m=5722967586
reported back in December 2002 :-).
Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
EventCollection on Create NodeRevisionContent empty
I am using the EventCollectionListener to determine what happened after a certain webdav call was made. The problem I am having is that when a put is executed I can retrieve the Create event, however the byte array returned from event.getRevisionContent() is empty. This is not the case if I catch the event with the ContentListener. Any reasons/ideas? Evan Kracoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question - is ACL negotiation unchangeable w/ competing rights ?
Nick Longinow wrote: Hi If a resource (document) in Slide has an ACL with multiple entries for the same principal, the spec (as I recall it) says that the lesser permission is applied to requests. ie, if user has read-only access as a member of one group, and read-write as a member of another group, both of which are named in the resource's ACL, then the user is given only the lesser (read-only). Is there a way to modify this behaviour, ie, such that either the first or last permission is applied ? Ideas ? Nick Nick, Your understanding of how this works isn't quite right. The ACL spec doesn't say anything about the relative 'strengths' of rights, the only thing that matters is the order within the ACL. The way it works is this: 1) you want to figure out if a user can perform some action (for example: writing to resource X) 2) You look at each ACE on resource X _in order_. The order of evaluation is: direct permissions on the resource (in their explicit ordering within the ACL), then inherited permissions from the parent, then inherited permissions from the grandparent, etc. 3) If this permission allows you to perform the appropriate action, then the access control checks pass. Don't look at the rest of the ACEs 4) If this permission _denies_ the appropriate permission, the access control check fails. Don't look at the rest of the ACEs. 5) If this permission does neither, continue to the next ACE. This is common - a 'read' permission, for example, doesn't allow writes, but doesn't deny them either. So the default behaviour (I think you can plug in alternative implementations, by the way, to answer your original question - but that would likely make it incompatible with the ACL spec) will be that, in your example, things 'just work'. However, this depends on exactly how you've set up your permissions. Specifically, you said user has read-only access as a member of one group. There are two ways you could set that up. One would be to say this group has read access (and say nothing at all about write access!), the other would be to say this group has read access AND this group explicitly does not have write access, using two ACEs (a grant and a deny). This latter form would not do what you want, so you should avoid it. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question - is ACL negotiation unchangeable w/ competing rights ?
Michael Oliver wrote: Michael, this is EXCELLENT and a very good thing to go into the Wiki...please! I would but you should get the credit. Ok. I've put it on the (more-or-less empty, previously) Security page. Feel free to edit it however you want. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide search performance issues
Surprise, but I too am seeing very slow search times! I'd greatly appreciate any insight the users of this list may have. I'm also seeing that when I do a getChildren on any collection with more than 10 entries, the times are very slow, even if it's just more collections. Thanks, Jeff From: Pontus Strand [EMAIL PROTECTED] Reply-To: Slide Users Mailing List slide-user@jakarta.apache.org To: 'Slide Users Mailing List' slide-user@jakarta.apache.org Subject: RE: Slide search performance issues Date: Wed, 12 Jan 2005 11:03:13 +0100 Hi Cédric, To add a custom property is really rather simple. First you must create a PropertyName object, like this: PropertyName propName = new PropertyName(DAV:, my_property_name); Next you have to use the setPath-method and the proppatchMethod in the WebdavResource class, like this: webdavResource.setPath(path_to_document_or_directory); webdavResource.proppatchMethod(propName, my_property_value, true); More details on these classes can be found in the javadoc. I hope this help you. The total lack of responses regarding the performance issues so far give me little hope that there is a solution, at least a simple solution. We are currently evaluating our options as how to proceed, currently we are looking into bypass Slide when searching. Regards, Pontus -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Cédric Sent: Wednesday, January 12, 2005 10:25 AM To: slide-user@jakarta.apache.org Subject: Re: Slide search performance issues Hi Pontus , I have the same trouble, i work with 1 documents ... so if i found any solution or explication i will take you part. I have an another question , how do you created your own property , because when i created a property with proppatch i was enable to specify the Namespace webdav. Have you got a little exemple of specific property creation and how to have this property ? Thanks a lot ! CF - 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]
Re: Question - is ACL negotiation unchangeable w/ competing rights ?
This is ok, but the issue is that when checking the ACL for a user belonging to several groups, the first one that explicitly grants/denies access is the one that takes effect. This sounds right but sometimes is not what you expect. For example, you have an admin group that you've given full access to a top directory, then in some subdirectory you denied access to another group. If you have a user that belongs to both groups it will be denied access to the given subdirectory even if he belongs to the admin group because the inherited ACEs come last in the ACL. Of course, you can explicity grant access to the admin group in the subdirectory's ACL, but it kind of defeats the purpose of inherited ACLs. Reading the spec it looks like this is the way that it has to be, but it doesn't sound logical in situations like the above. A way to implement this other behaviour, is to evaluate the whole ACL for each group a user belongs to separately and then choose the one that gives higher access. Resolving group strength at the time each ACE is evaluated will not work because, as Nick explains, an ACE may say nothing about a particular group but that doesn't mean that for that group at this point, access has been granted or denied. Carlos Michael Smith wrote: Nick Longinow wrote: Hi If a resource (document) in Slide has an ACL with multiple entries for the same principal, the spec (as I recall it) says that the lesser permission is applied to requests. ie, if user has read-only access as a member of one group, and read-write as a member of another group, both of which are named in the resource's ACL, then the user is given only the lesser (read-only). Is there a way to modify this behaviour, ie, such that either the first or last permission is applied ? Ideas ? Nick Nick, Your understanding of how this works isn't quite right. The ACL spec doesn't say anything about the relative 'strengths' of rights, the only thing that matters is the order within the ACL. The way it works is this: 1) you want to figure out if a user can perform some action (for example: writing to resource X) 2) You look at each ACE on resource X _in order_. The order of evaluation is: direct permissions on the resource (in their explicit ordering within the ACL), then inherited permissions from the parent, then inherited permissions from the grandparent, etc. 3) If this permission allows you to perform the appropriate action, then the access control checks pass. Don't look at the rest of the ACEs 4) If this permission _denies_ the appropriate permission, the access control check fails. Don't look at the rest of the ACEs. 5) If this permission does neither, continue to the next ACE. This is common - a 'read' permission, for example, doesn't allow writes, but doesn't deny them either. So the default behaviour (I think you can plug in alternative implementations, by the way, to answer your original question - but that would likely make it incompatible with the ACL spec) will be that, in your example, things 'just work'. However, this depends on exactly how you've set up your permissions. Specifically, you said user has read-only access as a member of one group. There are two ways you could set that up. One would be to say this group has read access (and say nothing at all about write access!), the other would be to say this group has read access AND this group explicitly does not have write access, using two ACEs (a grant and a deny). This latter form would not do what you want, so you should avoid it. Mike - 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]
Re: Slide search performance issues
Pontus Strand wrote: Doing the same search as before on 1 files yielded a log file of 55 MB. Each one of the 1 files generated 18 different select-queries!! 18!!! There simply must be a better way to do this! snip/ Have you modified the search queries or search methods? Are there any parameters in Domain.xml or similar files that can be added and/or modified to increase performance? Any help at all would be welcome, even if it is just asking obvious questions! Did you put parameter name=use-rdbms-expression-factorytrue/parameter into your nodestore configuration? Guido -- Freundliche Grüße / With kind regards Guido Casper SN AG Competence Center Open Source Klingenderstr. 5 D 33100 Paderborn voice +49 5251/1581-87 fax+49 5251/1581-71 eMail [EMAIL PROTECTED] Webhttp://www.s-und-n.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
