WebDav folder

[Alexander Nikitin]

Hello! Need your help.
How can i configure webdav folder out of webapps? Is it possible?
I need to share, for examle, d:/repository and access it via http://someapp/repository
Thanks.

[Ulf Dittmer]

Search for "docBase" in http://stackoverflow.com/questions/7833152/change-webdav-folder-on-tomcat

[Alexander Nikitin]

Cannot make it work
I have my app, for example testApp, i've added into its web.xml

<servlet>
  <servlet-name>webdav</servlet-name>
  <servlet-class>org.apache.catalina.servlets.WebdavServlet</servlet-class>
  <init-param>
    <param-name>debug</param-name>
    <param-value>0</param-value>
  </init-param>
  <init-param>
    <param-name>listings</param-name>
    <param-value>true</param-value>
  </init-param>
  <!-- Read-Write Access Settings -->
  <init-param>
    <param-name>readonly</param-name>
    <param-value>false</param-value>
  </init-param>
</servlet>

<!-- URL Mapping -->
<servlet-mapping>
  <servlet-name>webdav</servlet-name>
  <url-pattern>/rep</url-pattern>
</servlet-mapping>

and in server.xml

<Context path="/rep" docBase="d://blahblahblah" debug="0" reloadable="true" />

but when i try localhost:8080/testApp/rep i get the content of my application folder, except web-inf folder

Can you please guide me, what do i do wrong?

[Alexander Nikitin]

Well, now i can change docBase, but it requires to contain all app folders (web-inf), but i want to share only some storage folder and don't replace my app files. Can anyone help?

[Tim Holloway]

Do NOT attempt to configure a J2EE webapp to share its internal folders. In strict J2EE, the webapp is a read-only component. In Tomcat, you can write to it if you explode the WAR, but don't come crying to me when critical data gets destroyed.

Any WebDAV folders you wish to present via Tomcat should be located external to both the Tomcat and Tomcat webapps directories.

[Alexander Nikitin]

Any WebDAV folders you wish to present via Tomcat should be located external to both the Tomcat and Tomcat webapps directories.

This is exactly what i need, but i'm a newbie and i don't know how to configure this way. I've described before just what i was able to achieve, but it is not a goal.
Still, any help is welcome.

[Tim Holloway]

Tomcat does not provide WebDAV services, so the only way to use WebDAV with Tomcat is by deploying a WebDAV webapp. You'll have to tell it where your DAV folders are according to whatever configuration options that particular webapp requires.

[Alexander Nikitin]

Tomcat does not provide WebDAV services, so the only way to use WebDAV with Tomcat is by deploying a WebDAV webapp. You'll have to tell it where your DAV folders are according to whatever configuration options that particular webapp requires

I'm confused, This WebDAV webapp will be placed under tomcat/webapps and will share its own webapp folder, but on the other hand

Any WebDAV folders you wish to present via Tomcat should be located external to both the Tomcat and Tomcat webapps directories

I'm too greenhorn to understand it:( And not clear to me is

You'll have to tell it where your DAV folders are according to whatever configuration options that particular webapp requires

Could you please describe in more details?

[Tim Holloway]

You should do like I do and RTFM. http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/servlets/WebdavServlet.html

The catalina WebDAV servlet is a special servlet that can be configured into a webapp that "has the effect of re-mounting the entire web application under that sub-path, with WebDAV access to all the resources".

It's not part of the Tomcat server, however, it is available as a pre-supplied add-on to user-provided webapps. I'm not sure what the intent of this servlet is, since it breaks the rule about writing into WARs, it exposes all of the internals of the WAR except for the WEB-INF and META-INF subtrees, and the only part of the WAR that can be actually written into is hard-coded (the "content" subdirectory). So to me, it's both dangerous and inflexible. And unless I'm missing something, it's not even really "DAV" except that it supports the WebDAV protocol. Somewhat. There's no Versioning support I can see.

Then again, all the DAV stuff I do is via Apache HTTPD front-ending SVN, not Tomcat.

Repeating, however, it's dangerous to write into WARs, since you can lose critical data. If I was to ever actually use this servlet, I'd use a filesystem directory link to point the webapp's content directory to somewhere outside of Tomcat and the webapps folder. That could require a settings change to the Tomcat configuration, however, since Tomcat can restrict such practices.

[Alexander Nikitin]

Sad:(

Repeating, however, it's dangerous to write into WARs, since you can lose critical data. If I was to ever actually use this servlet, I'd use a filesystem directory link to point the webapp's content directory to somewhere outside of Tomcat and the webapps folder. That could require a settings change to the Tomcat configuration, however, since Tomcat can restrict such practices

Yes, i've tried, but it doesn't fit to me.
In general, what i need all these for: i have web-based file manager (Vaadin app) with the predefined storage on hdd(repository), and i need to develop an upload with resume:(. Applets and FTP are rejected by the customer. So i've started to look on webdav. Is there any other possibilities?

[Tim Holloway]

You probably wouldn't want WebDAV, then. It only works in most browsers if the user has explicitly enabled DAV client support for that browser.

I know nothing about Vaadin myself, but this page should help. https://vaadin.com/book/-/page/components.upload.html

Note that the uploaded files are being placed in a temporary directory, and yes, it's outside of the WAR. The Windows equivalent path would be something like "D:/temp/uploads". But string concatenation isn't how I form filenames, since it's OS-dependent. So I'd do it something like this:

final File uploadDir = new File("D:/temp/uploads");
File uploadedFile = new File(uploadDir, filename);

Normally I don't hard-code the upload directory either, but then I get a lot of criticism because of the extra time I take on making apps configurable.

[Alexander Nikitin]

Yes, it works this way right now. But i need upload with resume, i.e. if you upload big file and upload fails, you only need to upload remaining data.
Anyway big thanks.

[Tim Holloway]

Alexander Nikitin wrote:Yes, it works this way right now. But i need upload with resume, i.e. if you upload big file and upload fails, you only need to upload remaining data.
Anyway big thanks.

You have a problem there. In the normal course of events, the client crams the entire source file into one great big HTTP Request stream, shoving it down the Internet and into the corresponding receiving code in Tomcat, which detects the MIME headers and shunts the file data into a holding area (typically a temp file(s)) although for small stuff, RAM could be used.

So in other words, by the time the data reaches the web application code, it's a done deal. You have 2 choices: All. Or Nothing. "All", of course, subject to breakage in shipping.

To make an upload resumable, you need a client that can break the upload into segments, and server code that can reassemble them. The hard part is the client, since it's rarely something you have much control over. The standard browser architecture doesn't allow things like javascripting a partial upload because some of the related functionality has security issues. So you'd need signed JavaScript. Other approaches include custom upload controls such as ActiveX (good luck on that - I don't use Windows!), Java Applets (to access the client filesystem, they must be signed), or Flash components (back! back! I say!!!).

DAV, BTW, does not do segmented uploads either as far as I'm aware, so there still wouldn't be a benefit to using DAV here.

Your best bet is to google for "http resumable upload" and see what others have done.

One approach, used by Oracle, IBM and Sun is to provide a stand-alone resumable upload utility program. Each vendor, of course, having their own custom implementation. Typically such utilities maintain a list of files being/been uploaded, along with current upload status. You can do this in Java by writing the client as a standard Java desktop application that submits segments via the Java HttpURLRequest interface and using JNLP to get this client downloaded to the user's machine. The server-side code is fairly straightforward, although you should keep in mind that the nature of TCP/IP makes it possible that the segments might be received out of sequence and/or in parallel and adjust the reassembly process accordingly.