Red Hat Bugzilla – Bug 122161
Davenport Servlet Crashes Under Tomcat
Last modified: 2007-11-30 17:10:41 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040422 Description of problem: I have installed apache, tomcat and mod_jk2 from Fedora Core development. I have installed version 0.9.8 of the davenport servlet from <http://sourceforge.net/projects/davenport>. When I run the davenport servlet, the server returns a java.lang.NullPointerException. Version-Release number of selected component (if applicable): 4.1.27-12 How reproducible: Always Steps to Reproduce: 1. Install mozilla, apache, tomcat, mod_jk2 and the associated dependencies on Fedora Core development. 2. Download davenport from <http://sourceforge.net/projects/davenport>. 3. Copy the davenport.war file to /usr/share/tomcat/webapps/ 4. Add the line "ENSURE_WEBAPPS_WRITABLE=yes in /etc/sysconfig/tomcat" to the file /etc/sysconfig/tomcat 5. Add the line "[uri:/davenport/*]" to the file /etc/httpd/conf/workers2.properties 6. Restart apache and tomcat 7. Start mozilla and point it at http://127.0.0.1/davenport Actual Results: The server returns the exception in the attached file Expected Results: I expect to be able to browse my SMB shares via WebDAV Additional info:
Created attachment 99853 [details] Servlet Exception
Could you try this using tomcat-4.1.27-13 please?
I tried it with Fedora Core development 20040508, which includes tomcat-4.1.27-13. I am still getting the same error message.
Ok, in that case I'm guessing that Davenport is exercising some part of libgcj that is broken. I'll look into it asap, but I have a couple of other things I need to do first. Thanks for your help!
Ok, I've reproduced it. Now to figure out what's going on...
Created attachment 100330 [details] The unwrapped exception smbdav.Davenport.getServer() is actually wrapping this exception in an IOException.
Created attachment 100415 [details] Testcase This code reproduces the crash outside of both Davenport and Tomcat. The API documentation mentions nothing about whether or not the constructor in question, URL(URL context, String spec, URLStreamHandler handler), can handle a null context, but libgcj's implementation states that "[i]f context is null, then spec must be an absolute URL", which it is, and indeed, libgcj's implementation sets context to null in this case.
Created attachment 100420 [details] Fix When you create a java.net.URL with a particular URLStreamHandler the constructor ends up setting the URLStreamHandler to null and then choking on it. The attached patch to libgcj fixes the problem, though I'd be reluctant to say that it is correct before some libgcj wizards have cast their eyes over it. You should be able to run Davenport if you rebuild gcc34-3.4.0-1 with the attached patch. Unfortunatly there's no way to work around this at a higher level without rewriting a chunk of Davenport.
The test in comment #7 passes in gcc-4.0.0-8 (FC4 gcc), so I assume this has been fixed.