Bug 122161 - Davenport Servlet Crashes Under Tomcat
Davenport Servlet Crashes Under Tomcat
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gcc34 (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-01 00:56 EDT by Paul Bender
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: 4.0.0-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-22 04:12:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Paul Bender 2004-05-01 00:56:41 EDT
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 00:58:29 EDT
Created attachment 99853 [details]
Servlet Exception
Comment 2 Gary Benson 2004-05-07 12:45:58 EDT
Could you try this using tomcat-4.1.27-13 please?
Comment 3 Paul Bender 2004-05-08 10:11:43 EDT
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 11:39:08 EDT
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 09:06:05 EDT
Ok, I've reproduced it.  Now to figure out what's going on...
Comment 6 Gary Benson 2004-05-19 09:28:42 EDT
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 07:30:05 EDT
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 11:23:49 EDT
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 04:12:52 EDT
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.