Question about patch submission
Hey all, Quick question about patch submission: I submitted a patch a week or so ago and was curious if it was even received or acknowledged or anything or simply diverted to /dev/null. If it was rejected is there any protocol for the submitter getting notice or anything? thx, russ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
I don't know if you've considered this, but why not just make a Filter (ala Servlet 2.3) instead of a valve? They are more portable to other containers and should have less quirky behavior than you see now with valves. I use a filter to do a very similar operation where I check the session for certain values and load it up with other things to send downstream to the target servlet. russ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Patch to allow more flexible WebdavServlet/DefaultServlet operation
Two patches attached,
catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
There are two main pieces to this patch:
1) The addition of an isDefaultServlet initialization parameter to the
WebdavServlet
This allows the webdav servlet to be integrated as both the default servlet
as well as a url-pattern prefix servlet. Some small mods are made to
generate correct HREF's in a PROPFIND request based on this parameter value.
2) Parameterize getResources() DefaultServlet and WebdavServlet to pass in a
HttpServletRequest object so that DirContext's can be created by derived
servlets to return DirContext's on other request-based parameters, either in
the URL or session or whatever. The default behavior is to simply ignore the
HttpServletRequest parameter and return the same DirContext that has always
been returned (the one created on webapp initialization).
Lemme know if this can be applied by somebody. Thanks
Index: DefaultServlet.java
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.39.2.6
diff -u -r1.39.2.6 DefaultServlet.java
--- DefaultServlet.java 18 Apr 2002 03:08:04 - 1.39.2.6
+++ DefaultServlet.java 24 Jun 2002 18:33:23 -
@@ -1,5 +1,5 @@
/*
- * $Header: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v 1.39.2.6 2002/04/18 03:08:04 billbarker Exp $
+ * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v 1.39.2.6 2002/04/18 03:08:04 billbarker Exp $
* $Revision: 1.39.2.6 $
* $Date: 2002/04/18 03:08:04 $
*
@@ -344,6 +344,18 @@
/**
+ * Return a DirContext. This can be overridden in subclasses to return
+ * different kind of DirContexts if desired, perhaps based on data in the
+ * request. By, default we call DefaultServlet's getResources() to return
+ * the context-configured resource.
+ */
+protected DirContext getResources(HttpServletRequest request)
+{
+ return getResources();
+}
+
+
+/**
* Get resources. This method will try to retrieve the resources through
* JNDI first, then in the servlet context if JNDI has failed (it could be
* disabled). It will return null.
@@ -588,7 +600,7 @@
}
// Retrieve the resources
-DirContext resources = getResources();
+DirContext resources = getResources(req);
if (resources == null) {
resp.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
@@ -655,7 +667,7 @@
// Retrieve the Catalina context
// Retrieve the resources
-DirContext resources = getResources();
+DirContext resources = getResources(req);
if (resources == null) {
resp.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
@@ -1049,7 +1061,7 @@
}
// Retrieve the Catalina context and Resources implementation
-DirContext resources = getResources();
+DirContext resources = getResources(request);
ResourceInfo resourceInfo = new ResourceInfo(path, resources);
if (!resourceInfo.exists) {
Index: WebdavServlet.java
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
retrieving revision 1.25.2.2
diff -u -r1.25.2.2 WebdavServlet.java
--- WebdavServlet.java 1 Apr 2002 18:17:43 - 1.25.2.2
+++ WebdavServlet.java 24 Jun 2002 18:33:09 -
@@ -1,5 +1,5 @@
/*
- * $Header: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v 1.25.2.2 2002/04/01 18:17:43 remm Exp $
+ * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v 1.25.2.2 2002/04/01 18:17:43 remm Exp $
* $Revision: 1.25.2.2 $
* $Date: 2002/04/01 18:17:43 $
*
@@ -249,6 +249,19 @@
*/
private String secret = catalina;
+
+/**
+ * This flag keeps track of whether the servlet is invoked as the default
+ * servlet for the web application. We need to know the difference
+ * since the because we use HttpServletRequest methods to generate
+ * HREF's in the XML that gets returned for PROPFIND, etc. In testing,
+ * depending on the Webdav client and if this servlet is
+ * a default servlet the behavior of getServletPath()
+ * and getPathInfo() varies. A user must put true in the web.xml
+ * for this init parameter if the url-pattern for the servlet
+ * is the string /.
+ */
+private boolean isDefaultServlet = true;
// - Public Methods
@@ -266,6 +279,9 @@
value =
Tomcat 4.0.3, WebdavServlet and Konqueror
Hello, I'm having a problem Tomcat's built-in WebdavServlet /webdav from Konqueror. basically, konq is just hanging trying to hit the base /webdav URL. I stepped through the WebdavServlet code and noticed it was hanging trying to parse XML data over a call to req.getInputStream(). My theory is that the input stream is not returning EOF. I uncommented the RequestDumperValve and notice the following: The initial /webdav request has the following characterstics: 1. No Content-Length header 2. HTTP/1.1 3. No Connection header It almost looks as though Konq is NOT closing the connection after the request (when maybe it should?) Is the InputStream returned just assuming since it has no persistent connection indication and no content-length that socket-close means EOF. Thanks for any help, russ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servlet-path, path-info and Filters
Thank for your response Craig. Just re-read SRV.11 (for the umpteenth time!) So just so I have understanding, whatever resource (either static file, servlet, etc) the filter is filtering is irrelavent in determining what is returned from getServletPath(), getPathInfo() _in the filter_? From what you're saying whether it's a filter or a servlet, if the url-pattern is /something/* then that is the return of the getServletPath() call? Both being consistent with one-another? thanks again, russ - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 9:09 AM Subject: Re: servlet-path, path-info and Filters The rules are in the Servlet 2.3 Specification, section 11. In your particular example, getServletPath will return /files and getPathInfo() will return /foo.jpg. Thanks, russ Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servlet-path, path-info and Filters
Hello again Craig, Well, after going back into my filter setup again, I see that for Tomcat 4.0.1, i have the same setup that I describe in my example below (e.g. a url-pattern of /files/* for the filter-mapping element in web.xml) but the call to getServletPath() inside that filter returns /files/foo.jpg and getPathInfo() returns null for a request of /context/files/foo.jpg. Where's the error? (me, Tomcat, the spec, or all of the above) :-) russ - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 9:09 AM Subject: Re: servlet-path, path-info and Filters On Wed, 6 Feb 2002, Russ Trotter wrote: Date: Wed, 6 Feb 2002 23:04:40 -0700 From: Russ Trotter [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: servlet-path, path-info and Filters Does anyone here know what the official correct handling of ServletRequest.getServletPath() and ServletRequest.getPathInfo() should be? More specifically, if I specify a filter with an url-pattern of /files/* and I make a request to /context/files/foo.jpg, what should getServletPath() and getPathInfo() return? I've observed some differing behavior between Tomcat 4.0.1 and Jetty in this regard and the spec doesn't explicitly clear up the issue between the two. The rules are in the Servlet 2.3 Specification, section 11. In your particular example, getServletPath will return /files and getPathInfo() will return /foo.jpg. Thanks, russ Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
servlet-path, path-info and Filters
Does anyone here know what the official correct handling of ServletRequest.getServletPath() and ServletRequest.getPathInfo() should be? More specifically, if I specify a filter with an url-pattern of /files/* and I make a request to /context/files/foo.jpg, what should getServletPath() and getPathInfo() return? I've observed some differing behavior between Tomcat 4.0.1 and Jetty in this regard and the spec doesn't explicitly clear up the issue between the two. Thanks, russ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
