AW: Slide and JSR170
I don't think that jsr170 supports all the features that are required by WebDAV. The Slide core has some nice features that can't be found in the jackrabbit core up to now. So my personal favourite would be to build a java api that reflects the WebDAV protocols in a simpler and local/remote neutral way as it is described in the Slide 3.0 design approach in the wiki ;-) Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von John Gilbert Gesendet: Mittwoch, 1. Dezember 2004 05:14 An: Slide Users Mailing List; [EMAIL PROTECTED]; [EMAIL PROTECTED] Betreff: RE: Slide and JSR170 Just some food for thought to help protect your software from this duplication... If I were to start from scratch (not that I would) I would create an architecture that uses both in a multi-layered fashion. On the java client side (e.g. Swing) I would: - wrap a webdav api (e.g. slide) with the jsr170 api - this allows the client to access any webdav server - allows swapping jsr170 implementations - allows for swapping client-side CM tools that are used locally and don't need http. I think this is along the lines of jsr-147. On the server side I would: - expose the external facing/remote interface using webdav - this allows existing clients to access it - it also allows streaming large files over http which is more scalable then the non-streaming rmi alternative - internally I would use the jsr170 api so I don't have to define my own - the server could also act as a webdav client and use the wrapper mentioned above I use this logical architecture as a reference model when I need to decide what to use where and to help protect/decouple me from those choices. - John -Original Message- From: Jeff Broberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 7:57 PM To: [EMAIL PROTECTED]; 'Slide Users Mailing List' Subject: RE: Slide and JSR170 Thanks for the response. I quess my question is, What is the overall architecture for CMS as far as Apache goes ? There seems to be quite a bit of duplication, and I am not sure why slide wouldn't use jackrabbit, or 170. They seem like the logical stack. I agree with your assessment re: webdav. It is more global in nature. Just curious, why do you recommend against using the server Slide API. Is it because it is only relevant to slide ? If so, I agree, because it causes technology lockin. So, if that is the case, what is the benefit of the server api at all ? Jeff -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 6:08 PM To: Slide Users Mailing List; [EMAIL PROTECTED] Subject: Re: Slide and JSR170 Slide does not support JRS170. Jackrabbit isn't used either. It's the other way round as well, Jackrabbit does not use Slide either. I guess there are quite a number of parameters included in the decision which way to go, so I really can not make any recommendation. Good thing about WebDAV is that there already are a number of applications supporting it. Drawback would be that WebDAV by nature is a client/sever protocol, so you would always have the communication overhead. On the other hand while JSR170 covers only certain aspects of a content store, WebDAV is pretty much complete. Additionally, programming against JSR170 would restrict you to Java solutions. I *personally* would not at all recommend programming against the sever Slide API... Oliver On Tue, 30 Nov 2004 17:52:17 -0500, Jeff Broberg [EMAIL PROTECTED] wrote: Ok, simple question. Is the Slide API based on JSR170 ? If so, is JackRabbit used inside Slide ? We are considering if we should write our java clients to use WebDAV client protocols or use the Slide API, or if possible the 170 api. Any guidance would be appreciated. Jeff - 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: problem: OS X mounting webdav as read only
Most likely this is due to the SimpleFileStore implementation. I remember having some problems with this as well. I have done some work based on your initial contribution and have created WCK with a file store reference implementation. Perhaps you want to try that out? Oliver On Tue, 30 Nov 2004 18:43:03 -0800, alon salant [EMAIL PROTECTED] wrote: I've searched the archives and found some recent discussion around this but no great diagnostics or resolution. I'll do what I can to be helpful... My setup: I have slide running embedded in my own web application running on Tomcat 5. I built slide from CVS Nov 5. I have disabled authentication in slide and am using container-managed security for authentication (HTTP basic). I am using TransientLockStore and TransientSecurityStore and SimpleFileStore for the other stores. My problem: With my Win2k webdav client, I can use my webdav share with the ability to do all actions. On OS X 10.3.6, I can mount my webdav share but it mounts read only. I see that there are people who are having more success with OS X on this mailing list so I'm curious what could be different. I've tried: I've tried toggling lockdiscoveryIncludesPrincipalURL and get the same behavior. I tried a new build from the latest changes in CVS (I saw a post saying that recent changes may have fixed OS X issues) but ran in to showstopper issues with both webdav clients. (I'll provide info in another email.) I turned on debugging but see the same log entries for both the working win2k client and read-only OS X client. Goliath 1.0.1 seems to work great. I'm happy to provide more info. It doesn't look like webdavfs can be configured to run through a proxy so is tcpdump the call? Alon - 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 and JSR170
On Tue, 30 Nov 2004 23:13:45 -0500, John Gilbert [EMAIL PROTECTED] wrote: - wrap a webdav api (e.g. slide) with the jsr170 api This has been discussed as in option inside Slide. If you plan to implement something like that would you consider donating it to Slide? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide and JSR170
On Tue, 30 Nov 2004 19:56:44 -0500, Jeff Broberg [EMAIL PROTECTED] wrote: Thanks for the response. I quess my question is, What is the overall architecture for CMS as far as Apache goes ? There seems to be quite a bit of duplication, and I am not sure why slide wouldn't use jackrabbit, or 170. 1) Slide was there long before there even was the JSR170 or Jackrabbit, so it can hardly rely on it 2) You do not actually *use* JSR170 but at most expose it as an API to the programmer 3) I do not think there is something like a master plan concerning CMS architecture at Apache Just curious, why do you recommend against using the server Slide API. Is it because it is only relevant to slide ? If so, I agree, because it causes technology lockin. So, if that is the case, what is the benefit of the server api at all ? It is not because it is proprietary. You could easily put something like an abstraction wrapper around it or use any form of data access ojects. The reason is that it is pretty hard and error prone to program to the Server API. So, do not program to it if you do not have to. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide and JSR170
To do this you will need to perform a major 'gap-analysis' exercise. The
functionality that is specified by the WebDav JCR specifications are
basically over-lapping sets, i.e. the functionality of neither specification
is a subset of the other but there are significant degrees of overlap.
From my cursory introduction (I have been using both Slide and JCR170 for
about 3 months) the following areas spring to mind:
JCR Implementation
* - includes version control that allows you to roll back to a named
previous version.
* - Node Type definitions. All nodes are related to a node type that
defines the details of attributes that can be assigned to that node and can
be used to restrict the type of children that can be attached.
* - XML Import Export of Node hierarchies
WebDav Implementation
* - Ability to assign privileges to nodes (JCR spec deliberately excludes
this but does allow you to check if the user has appropriate privilege)
{ I am sure that there are other features that are in WebDav/DeltaV but not
in JCR170 but I am using the Slide Server API directly and found that Oliver
is right in saying that it's not a task to be undertaken lightly :) }
HTH
Andy Bowes
NB : Public release of JCR170 also includes the ability to have multiple
parents for a specific node
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: 01 December 2004 10:06
To: Slide Users Mailing List
Subject: Re: Slide and JSR170
On Tue, 30 Nov 2004 23:13:45 -0500, John Gilbert [EMAIL PROTECTED]
wrote:
- wrap a webdav api (e.g. slide) with the jsr170 api
This has been discussed as in option inside Slide. If you plan to
implement something like that would you consider donating it to Slide?
Oliver
-
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]
WCK: Another Qustion
Hello Again? Is there a way to minimize the no. of levels slide retrieves items?? i can see that slide retrieves 3 levels at the first start.. Am using WCK, and my CMS database is quite huge which increases the time of retrieveing the data, so that the web folder times out giving an error message saying that items are moved or deleted.. is there a way to let slide only retrieves 1 level at a time??? Thanx alot! Rony __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WCK: Another Question
Hello Again Is there a way to minimize the no. of levels slide retrieves items?? i can see that slide retrieves 3 levels at the first start.. Am using WCK, and my CMS database is quite huge which increases the time of retrieveing the data, so that the web folder times out giving an error message saying that items are moved or deleted.. is there a way to let slide only retrieves 1 level at a time??? Thanx alot! Rony - Do you Yahoo!? The all-new My Yahoo! Get yours free!
Possible Slide development position
Spotted this on Ted's blog, and did not see it posted here yet: http://www.sauria.com/blog/2004/12/01#1156 OSAF is looking for a server developer to work on WebDAV and (likely) CalDAV stuff. You'll probably be working on Slide, which means that the target language is Java. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DreamWeaver and Slide
Hola! I'm trying to access a Slide (2.0) repository with DreamWeaver (MX 2004) using WebDav. When I create a new file and try to upload it, DreamWeaver fails because of a 423 error reported by Slide. The sequence of requests executed by DreamWeaver (according to Slide logs) is this: PROPFIND /slide/index.html HTTP/1.1 404 - PROPFIND /slide/index.html HTTP/1.1 404 - LOCK /slide/index.html HTTP/1.1 200 771 PROPFIND /slide/index.html HTTP/1.1 207 1135 PUT /slide/index.html HTTP/1.1 423 - Interestingly, the file 'index.html' is created (length 0) and then shows up in DreamWeaver as locked. On the other hand, when I access an Apache mod_dav-enabled repository, the sequence of requests is the following one: PROPFIND /update/index.html HTTP/1.1 404 296 PROPFIND /update/index.html HTTP/1.1 404 296 LOCK /update/index.html HTTP/1.1 200 457 PROPFIND /update/index.html HTTP/1.1 207 616 PUT /update/index.html HTTP/1.1 201 271 PROPFIND /update/index.html HTTP/1.1 207 457 PROPFIND /update/index.html HTTP/1.1 207 616 PROPFIND /update/index.html HTTP/1.1 207 616 PROPFIND /update/index.html HTTP/1.1 207 616 PROPFIND /update/index.html HTTP/1.1 207 616 PROPFIND /update/ HTTP/1.1 207 2388 PROPFIND /update/ HTTP/1.1 207 6413 The file is then successfully created. Any ideas on why Slide behaves the way it does? Thanks a lot, Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide and JSR170
Personally, I like the WebDav layer ontop of JSR170. I still feel that Slide should expose jsr170 as one of its stores, so that it can have relevance in the long term. I can understand using webdav to access the content from the client, but to build out a web based management console ontop of the repository, I do not want a proprietary api ( aka slides ), I would prefer a standard. At that is where I see 170 being important. jeff -Original Message- From: Carlos Villegas [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 12:39 AM To: Slide Users Mailing List Subject: Re: Slide and JSR170 kranga wrote: I don't think jsr 170 forms a logical stack for Slide - who's primary concern is WebDAV protocol implementation. I am very skeptical of jsr 170 - more so after looking at participants - Fujitsu, IBM, BEA, Sun, HP, Borland aren't exactly companies I think of when considering content management systems. I think this is another example of the jcp's callous disregard for what already exists. Webdav, Delta V, ACL, WebDAV-search etc. already exist as standards in a language neutral way. Instead of specifying a java API that basically uses java native method calls in lieu of http, they've created a whole parallel spec set. What a waste ... Well, I don't think we're talking about the same things here. Just because there's SQL, it doesn't mean we don't need JDBC. They are two different things, WebDAV is a protocol with an underlying model, as you say language neutral. But to work with it from within a language like java we need an API. Or else how do you communicate with a WebDAV server from Java. That's why there's slide-webdavclient, or the slide internal server API. That jsr170 parallels some of the concepts of WebDAV and related tools is only natural but it's not a replacement, you can use jsr170 as the java webdav client API or you can put WebDAV on top of a jsr170 repository server to expose it remotely. I see it as the same difference as LDAP/JNDI or SQL/JDBC or XML/SAX/DOM etc. Carlos - 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 and JSR170
It was my understanding that JSR170 is still immature. It is not a final
spec. Coding to an unfinished spec is not worth the risk, imho. We chose to
use slide, aside from the obvious webdav support (versioning, locks,
role-based security, etc...) because slide supports cache invalidation and
clustering with its new 2.1b. Implementing this feature-set with the
incomplete JSR170 is not an option for us.
Roy Russo
JBoss Portal Developer
- Original Message -
From: Andy Bowes [EMAIL PROTECTED]
To: 'Slide Users Mailing List' [EMAIL PROTECTED]
Sent: Wednesday, December 01, 2004 5:33 AM
Subject: RE: Slide and JSR170
To do this you will need to perform a major 'gap-analysis' exercise. The
functionality that is specified by the WebDav JCR specifications are
basically over-lapping sets, i.e. the functionality of neither
specification
is a subset of the other but there are significant degrees of overlap.
From my cursory introduction (I have been using both Slide and JCR170 for
about 3 months) the following areas spring to mind:
JCR Implementation
* - includes version control that allows you to roll back to a named
previous version.
* - Node Type definitions. All nodes are related to a node type that
defines the details of attributes that can be assigned to that node and
can
be used to restrict the type of children that can be attached.
* - XML Import Export of Node hierarchies
WebDav Implementation
* - Ability to assign privileges to nodes (JCR spec deliberately excludes
this but does allow you to check if the user has appropriate privilege)
{ I am sure that there are other features that are in WebDav/DeltaV but
not
in JCR170 but I am using the Slide Server API directly and found that
Oliver
is right in saying that it's not a task to be undertaken lightly :) }
HTH
Andy Bowes
NB : Public release of JCR170 also includes the ability to have multiple
parents for a specific node
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: 01 December 2004 10:06
To: Slide Users Mailing List
Subject: Re: Slide and JSR170
On Tue, 30 Nov 2004 23:13:45 -0500, John Gilbert [EMAIL PROTECTED]
wrote:
- wrap a webdav api (e.g. slide) with the jsr170 api
This has been discussed as in option inside Slide. If you plan to
implement something like that would you consider donating it to Slide?
Oliver
-
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: Slide and JSR170
AFAIK the Jackrabbit people plan to add WebDAV as well... By the way I see no way why you should not program your management console to the Slide client API that translates your stuff to WebDAV. That one is nice, exists, is easy to program to *and* supports a standard. Oliver On Wed, 1 Dec 2004 10:27:38 -0500, Jeff Broberg [EMAIL PROTECTED] wrote: Personally, I like the WebDav layer ontop of JSR170. I still feel that Slide should expose jsr170 as one of its stores, so that it can have relevance in the long term. I can understand using webdav to access the content from the client, but to build out a web based management console ontop of the repository, I do not want a proprietary api ( aka slides ), I would prefer a standard. At that is where I see 170 being important. jeff -Original Message- From: Carlos Villegas [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 12:39 AM To: Slide Users Mailing List Subject: Re: Slide and JSR170 kranga wrote: I don't think jsr 170 forms a logical stack for Slide - who's primary concern is WebDAV protocol implementation. I am very skeptical of jsr 170 - more so after looking at participants - Fujitsu, IBM, BEA, Sun, HP, Borland aren't exactly companies I think of when considering content management systems. I think this is another example of the jcp's callous disregard for what already exists. Webdav, Delta V, ACL, WebDAV-search etc. already exist as standards in a language neutral way. Instead of specifying a java API that basically uses java native method calls in lieu of http, they've created a whole parallel spec set. What a waste ... Well, I don't think we're talking about the same things here. Just because there's SQL, it doesn't mean we don't need JDBC. They are two different things, WebDAV is a protocol with an underlying model, as you say language neutral. But to work with it from within a language like java we need an API. Or else how do you communicate with a WebDAV server from Java. That's why there's slide-webdavclient, or the slide internal server API. That jsr170 parallels some of the concepts of WebDAV and related tools is only natural but it's not a replacement, you can use jsr170 as the java webdav client API or you can put WebDAV on top of a jsr170 repository server to expose it remotely. I see it as the same difference as LDAP/JNDI or SQL/JDBC or XML/SAX/DOM etc. Carlos - 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: WCK: A Question
Hmmm, still a little bit confusing to me. I understand that createResource is called with a specifc path is called, but you store an id instead, right? So, the problem seems to be that the *client* still tries to find that file by the oringal name as it has got no idea of your change. I suppose after you issue a refresh in the client everything works ok? If this is your scenario there isn't pretty much you can do as you can not force the client to refresh. Maybe mapping the original path to your id would be the only solution... Oliver On Tue, 30 Nov 2004 23:39:02 -0800 (PST), EngR H [EMAIL PROTECTED] wrote: Thanz Oliver for the reply! :) Well, the symptoms are that when I try to create an item to my CMS through the webdav servlet, an item is added by name not by Id so that when i open it, my CMS complains that the id is not valid, (cos the diplay name is passed istead of the id) that's why i need to know how to change the item url to show the id instead of the name?? should I issue a refresh, (so that my CMS reads the items by ID and set the label as the diplay name as needed) ?? or is there another way?? Thanx alot! Rony Oliver Zeigermann [EMAIL PROTECTED] wrote: -- Forwarded message -- From: Oliver Zeigermann Date: Mon, 29 Nov 2004 17:59:55 +0100 Subject: Re: WCK: A Question To: EngR H On Mon, 29 Nov 2004 00:06:55 -0800 (PST), EngR H wrote: Hi Oliver, thanks alot for the reply! first of all, sorry for not being somehow to the point in my last mail.. may be cos English is not my mother language :) Well, concerning JAAS I didn't yet work wiz it ... English isn't my native language either, but people don't even understand me in German ;) About the problem, caching is half the problem .. I'll try to explain :) getChildrenNames in my customization returns my CMS item id's not labels, while labels are set as the display name property, so that items are seen with their display name while they are recognized by the webdav server by their id's, the problem is that when creating a new (folder/document) to the webdav server, the folder name is added to the webdav children by name and a new folder is added to my CMS. I need to let the webdav replace the folder name with my CMS folder ID, is that possible ??? Hmmm, not sure if this is such a good idea as some clients do not use the display name, but only the URL. Anyway, I think I understand the problem. What are the symptoms? Does the client see something wrong? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Mail - You care about security. So do we. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
UserTransaction and WebdavResource
I'd like to create a J2EE application which is both a Slide client and a database and jms client. The Slide client will use the WebdavResouce class with its transaction methods (startTransaction, commitTransaction, abortTransaction, etc.). The J2EE client part will use a UserTransaction (or the theadlocal transaction mechanism) to mediate the transactions. How can I wrap these together to form a single transaction mechanism - doing Slide and database/jms actions all within a single transaction? Thanks. Richard -- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UserTransaction and WebdavResource
I guess the best approach is to wrap the Slide WebdavResource transaction calls in a XAResource and add it to the J2EE Transaction object. RME Richard Emberson wrote: I'd like to create a J2EE application which is both a Slide client and a database and jms client. The Slide client will use the WebdavResouce class with its transaction methods (startTransaction, commitTransaction, abortTransaction, etc.). The J2EE client part will use a UserTransaction (or the theadlocal transaction mechanism) to mediate the transactions. How can I wrap these together to form a single transaction mechanism - doing Slide and database/jms actions all within a single transaction? Thanks. Richard -- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UserTransaction and WebdavResource
Never mind, I found WebDAVXAResource.java. RME Richard Emberson wrote: I guess the best approach is to wrap the Slide WebdavResource transaction calls in a XAResource and add it to the J2EE Transaction object. RME Richard Emberson wrote: I'd like to create a J2EE application which is both a Slide client and a database and jms client. The Slide client will use the WebdavResouce class with its transaction methods (startTransaction, commitTransaction, abortTransaction, etc.). The J2EE client part will use a UserTransaction (or the theadlocal transaction mechanism) to mediate the transactions. How can I wrap these together to form a single transaction mechanism - doing Slide and database/jms actions all within a single transaction? Thanks. Richard -- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another Question
The webdav client methods take a depth parameter which can be 0, 1 or infinite. When you specify 0 the operation works on the target alone. 1 indicates target and immediate children and infinite to operate on the target and all children. Of course they really only apply when the target is a collection. So the client controls how deep any operation should go and if you control the client, as I can with my app, I have managed never to need to use the infinite option. The actual depth of the infinite depth option can be changed with this init parameter defined in slide/WEB-INF/web.xml. init-param param-namedepth-limit/param-name param-value3/param-value description This init-parameter determines the depth limit for PROPFIND and other methods, to avoid performance hits on the server for requests with infinite depth. The default value is '3'. /description /init-param Warwick -Original Message- From: EngR H [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 4:55 AM To: [EMAIL PROTECTED] Subject: WCK: Another Question Hello Again Is there a way to minimize the no. of levels slide retrieves items?? i can see that slide retrieves 3 levels at the first start.. Am using WCK, and my CMS database is quite huge which increases the time of retrieveing the data, so that the web folder times out giving an error message saying that items are moved or deleted.. is there a way to let slide only retrieves 1 level at a time??? Thanx alot! Rony - Do you Yahoo!? The all-new My Yahoo! - Get yours free! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Webdav client transactions
Hi, I've been working with the webdav client transaction methods and wanted to confirm something about their use and also potentially pass on some useful information to others who intend to use them. The startTransaction and endTransaction (the latter called by commitTransaction and abortTransaction) methods lock the resource represented by the WebdavResource they are called upon seemingly as a means of implementing transaction security. So when you start a transaction with a webdav resource who's target is /slide you must also call the commit and abort methods using the same path. If you don't then the webdav client doesn't remove the transaction lock from its own lock cache. And using the same resource for lock and unlock is exactly how it is with the normal webdav client lock and unlock methods; but with the transaction methods this is not immediately obvious as they don't take a target parameter as lock and unlock do and the fact that they do lock and unlock a resource to frame the transaction isn't common knowledge. I discovered this because I have assigned one WebdavResource instance per thread in my application and reuse these during the course of an application request. To access another webdav resource I use the setPath() method to change it to point to whatever resource I need at that time. But when I come to commit or abort the transaction I needed to set the path of the WebdavResource instance back to that I originally called startTransaction with. So, with all this, I'm now wondering if there is an optimal resource path that I should use for the transaction lock? I just picked /slide. But I don't understand enough about what the transaction lock is to guess whether this is a good or bad thing. Will having this resource locked during transactions affect anyone else's attempts to lock this resource for general CM purposes? Is the transaction lock even a normal lock in this regard? It doesn't seem to be as it is treated differently by the server. If anyone can shine some light on the design of the transaction locks I'd be interested to know. Thanks, Warwick
Performance gain from WebdavResource reuse?
Is there a performance gain when you use a single WebdavResource object per thread and reuse it to access different resources on the same Slide server? ie. if there is only one WebdavResource then is there only one HTTP connection to the Slide server across which all requests flow no matter what the target document or collection is? Or is the connection torn down and reestablished again when setPath() is called. I would not think so but want to confirm it. Also, is there anything in particular that I need to do to enable HTTP 1.1 persistent connections for the webdav client if I'm using Tomcat 4.1.30 or is this the default mode of operation for the webdav client? Thanks, Warwick
Re: UserTransaction and WebdavResource
There is a Slide connector that can be used. However, it currently works with JBoss only. Have a look at the thread Andrew Tibets started. Oliver On Wed, 01 Dec 2004 09:06:57 -0800, Richard Emberson [EMAIL PROTECTED] wrote: I'd like to create a J2EE application which is both a Slide client and a database and jms client. The Slide client will use the WebdavResouce class with its transaction methods (startTransaction, commitTransaction, abortTransaction, etc.). The J2EE client part will use a UserTransaction (or the theadlocal transaction mechanism) to mediate the transactions. How can I wrap these together to form a single transaction mechanism - doing Slide and database/jms actions all within a single transaction? Thanks. Richard -- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - 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]
MKACTIVITY and transactions
Hi, I was reading in the Subversion documentation that Subversion performs atomic commits by creating a WebDAV activity which creates a server transaction and it then do a checkout, put, proppatch and checkin, all supposedly occurring within the same transaction. Does this work on Slide? Could this be a standard alternative to using the propieratory MS client transactions? Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MKACTIVITY and transactions
What are the standard MS client transactions you're talking about? Warwick -Original Message- From: Carlos Villegas [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 6:22 PM To: Slide Users Mailing List Subject: MKACTIVITY and transactions Hi, I was reading in the Subversion documentation that Subversion performs atomic commits by creating a WebDAV activity which creates a server transaction and it then do a checkout, put, proppatch and checkin, all supposedly occurring within the same transaction. Does this work on Slide? Could this be a standard alternative to using the propieratory MS client transactions? Carlos - 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: MKACTIVITY and transactions
No, what I'm saying is that instead of using MS extensions one could possibly use activities which are defined in the WebDAV spec. Subversion seems to use them to implement atomic commits. So my question is if this is supported by Slide. Carlos Warwick Burrows wrote: What are the standard MS client transactions you're talking about? Warwick -Original Message- From: Carlos Villegas [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 6:22 PM To: Slide Users Mailing List Subject: MKACTIVITY and transactions Hi, I was reading in the Subversion documentation that Subversion performs atomic commits by creating a WebDAV activity which creates a server transaction and it then do a checkout, put, proppatch and checkin, all supposedly occurring within the same transaction. Does this work on Slide? Could this be a standard alternative to using the propieratory MS client transactions? Carlos - 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]
commercial cooperation
Dear all of you, (B (B We want to use the Slide as a file repository manager in our company (Bspecialized in a translation company. This file repository should support (Bthe ACL management, Versioning, Checkin/Checkout, WebDAV, and must be (Bintegrated into our J2EE-based System easily. I have read some documents (Brelated to Slide and find that the Slide provides the above functionalities. (B (BHowever, considerable efforts must be made in order to run it correctly. As (Ba translation company, we do not have adequate staffs too skilled in (Butilizing Slide, especially, to integrate it into the J2EE System. So, could (Banyone on this mailing list provide a plausible solution to our problem (Bsuggesting an easy-to-use built-in system of Slide? (B We would appreciate it very much if someone can suggest us the easy-to-use (BSLIDE Tools so that even beiginners are able to fulfill the tasks above (Bincluding a slide-based off-the-shelf product. (B (BBTW, our company is located in Tokyo, Japan. (B I am looking forward to your reply. (B (B Best regards (B (BPingkui Hou
