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):
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
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
Created attachment 99853 [details]
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
Created attachment 100415 [details]
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]
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