I don't know much about WebDAV, but I don't think it is reasonable to have an implementation for Jetty that requires all of Tomcat and 6 supporting jars as a dependency. To me it would make more sense to integrate Tomcat if WebDAV is required, or implement WebDAV independent of Tomcat.
I agree. It is also my primary concern.
To be more precise, the Tomcat JAR along with the 6 supporting JARs are only required by the TomcatDAVRepository. These 6 JARs are required by the WebdavServlet provided by Tomcat and I am pretty sure that one can extract only the required classes and end with a couple of classes.
All the other classes, and especially JettyConnector, JettyConnectorImpl and JettyDAVServer, have no dependencies with Tomcat.
JettyConnectorImpl was intended to be a HTTP listener. JettyDAVServer was intended to be a Jetty Server able to add/remove DAVRepository instances (and not especially a TomcatDAVRepository instances). A DAVRepository was a kind of Servlet definition (Class of the Servlet, init parameters, context attributes mainly), plus a notion of local directory exposed via DAV.
It was far to be clever to name the class JettyDAVServer. I should have named it JettyHTTPServer.
What exactly do we need WebDAV for?I think that one could use WebDAV to distribute components over HTTP as most of the firewalls allow it. Another approach is to leverage the Remoting implementation: one could perform a random file access of an artifact to be distributed and send it into smaller parts. However, I do not think that this is really efficient.
How do you intend to distribute components?
Thanks, Gianny
_________________________________________________________________
Get a FREE online virus check for your PC here, from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
