Bug 122161 - Davenport Servlet Crashes Under Tomcat
Summary: Davenport Servlet Crashes Under Tomcat
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc34
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-01 04:56 UTC by Paul Bender
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: 4.0.0-8
Clone Of:
Environment:
Last Closed: 2005-07-22 08:12:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Servlet Exception (5.52 KB, text/plain)
2004-05-01 04:58 UTC, Paul Bender
no flags Details
The unwrapped exception (6.26 KB, text/plain)
2004-05-19 13:28 UTC, Gary Benson
no flags Details
Testcase (363 bytes, text/plain)
2004-05-21 11:30 UTC, Gary Benson
no flags Details
Fix (553 bytes, patch)
2004-05-21 15:23 UTC, Gary Benson
no flags Details | Diff

Description Paul Bender 2004-05-01 04:56:41 UTC
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:

Comment 1 Paul Bender 2004-05-01 04:58:29 UTC
Created attachment 99853 [details]
Servlet Exception

Comment 2 Gary Benson 2004-05-07 16:45:58 UTC
Could you try this using tomcat-4.1.27-13 please?

Comment 3 Paul Bender 2004-05-08 14:11:43 UTC
I tried it with Fedora Core development 20040508, which includes
tomcat-4.1.27-13. I am still getting the same error message.

Comment 4 Gary Benson 2004-05-10 15:39:08 UTC
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!

Comment 5 Gary Benson 2004-05-19 13:06:05 UTC
Ok, I've reproduced it.  Now to figure out what's going on...

Comment 6 Gary Benson 2004-05-19 13:28:42 UTC
Created attachment 100330 [details]
The unwrapped exception

smbdav.Davenport.getServer() is actually wrapping this exception in an
IOException.

Comment 7 Gary Benson 2004-05-21 11:30:05 UTC
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.

Comment 8 Gary Benson 2004-05-21 15:23:49 UTC
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.

Comment 9 Jakub Jelinek 2005-07-22 08:12:52 UTC
The test in comment #7 passes in gcc-4.0.0-8 (FC4 gcc), so I assume this has been
fixed.


Note You need to log in before you can comment on or make changes to this bug.