Hi,
I am running Slide 2.1 on a patched version of Jetty 4.2.20 for big file
transfer ( 2GB).
I implemented this and transferring small files works fine; but when
uploading a large file 2GB; the process uploads fine until its done then
an Internal Server Error occurs and the file is not
Hello,
I have a requirement that means developers need to be able to edit JSP files
(i.e. get and put from a WebDAV-aware IDE) on a Slide WebDAV server. I
understand that this requires the disabling of the JSP servlet for the Slide
app (otherwise it intercepts puts and gets before the WebDAV
Yes you can use the filesystem content store and locate that store someplace
that you can map a tomcat context. For example your store might be
c:\somefiles\content\ then you could create a tomcat context called /pubfiles
that pointed to your store's /files directory and you should be in
I'm not an expert but it seems to me that you have a couple of potential
options:
1. Use a 'nix style link on the server-side to map two paths - one
of which is served by the Slide WebDAV servlet, the other of which is
mapped to the JSP servlet.
2. Add a hook so that when a file is
Hi folks, sorry for the cross posting but I think this issue is relevant
to both projects.
I am trying to use custom authentication with the Slide library, which
itself relies on the httpclient library (I am using the latest 3.x
release candidate to use the newer authentication APIs). Suffice
Well, I looked and the code is still in there. It must not be working
right. Can someone post a trace of a failing request?
-James
On Sat, 2005-02-05 at 23:48 +0200, Roman D wrote:
That thread from 25-Jan-2005 is indeed about this same issue.
I build from HEAD and tests fail with reference
I am getting this failure with WCK;
org.apache.slide.transaction.SlideTransaction - WARNING - Commit
failure: Resource manager
[EMAIL PROTECTED] Error code
XAER_NOTA in Transaction 13 xid [EMAIL PROTECTED]@1a01f91 in thread
http-8180-Processor25
javax.transaction.xa.XAException
at
You were evidently relying on an Ace for the node /users for the principal
who was executing the Rdir command. I'd start digging into what happened
to the permissions for that node, and/or the principal who actually
executes the Rdir command. One of those two changed, to get the 403.
Nick
Hi Oleg,
The type of authentication I am implementing is in fact Kerberos.
There is no secret key sent, etc. Kerberos has it's own
replay/man-in-the-middle protections. I agree in principal that it is
best to operate in accordance with existing standards and behavior (even
if they do not
On Mon, 2005-02-07 at 15:25 -0500, Aaron Hamid wrote:
Hi Oleg,
The type of authentication I am implementing is in fact Kerberos.
OK, I see. The trouble is that currently Basic authentication scheme is
hardwired. It cannot be substituted with any other scheme
I can't seem to connect to Slide using the Mac OS X webdav client when I
map Slide's webdav servlet to anything but the application root...
I set the default-servlet:false. Is there something I forgot?
Fine:
servlet-mapping
servlet-namewebdav/servlet-name
url-pattern//url-pattern
Hello,
I was looking into a caching solution to cache the WebdavResource obtained
for a user so as to avoid the time taken to re-authenticate that user to
Slide App. In doing so I came across the way the HttpClient is managed by
the WebdavResource. After execution of any method the HttpConnection
Is it possible that I am stuck in some kind of transaction?
I just tried to put the proppatchMethod in the finalize-Method, I know thats
not the best way,
but in there it worked.
i have to methods, the one called addUserToRole, make a propPatchMethod, to the
role and the second one creates a
13 matches
Mail list logo