Hmmm... I'm not sure that catalina can write to /tmp just because your
users can. Try running this code before calling MultipartRequest multi =
...
FileWriter fw = new FileWriter("/tmp/hello.txt"); // (line 1)
fw.write("Hello World\n");
fw.close();
When you start Tomcat, what value does it say it is using for
$CATALINA_TEMP? Try using that directory (instead of /tmp) for your file
upload.
Also, defaultFileRenamePolicy was initialized to be new
DefaultFileRenamePolicy(), right?
--
Sean Dockery
[EMAIL PROTECTED]
Certified Java Web Component Developer
Certified Delphi Programmer
SBD Consultants
http://www.sbdconsultants.com
"Patrick L Archibald" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I've tried JVM 1.2 and 1.3. The public (meaning valid users) have all
> authority to the "/tmp" directory. This direcoty is Coded character set
> ID . . . . . . . . : 37. I tried another directory "/public/platemp"
> which is Coded character set ID . . . . . . . . : 437. I don't know
> why the "L" prefix is in the stack trace. It has always been that way as
> far as I can remember.
>
> I added a sendMessage method using the jt400 message queue function. I'm
> getting messages now. The System.out.println and System.err.println were
> never being written.
>
> By using the sendMessage method I've found the statement it is blowing
> up on:
>
> MultipartRequest multi = new MultipartRequest(request, "/tmp", 5000
> * 1024, defaultFileRenamePolicy);
>
> Any more suggestions? Is there something wrong with my statement above?
>
> BTW, the upload.war application that comes with the com.oreilly.servlet
> packages blows up too.
>
> Thanx, PLA
>
>
> Sean Dockery wrote:
>
> > I doubt the JVM is the problem. What version are you using, by the
> > way? (java -version)
> >
> > There is probably still something we're missing in your root cause...
> >
> > What is with the "L" prefix on some of the class names in the root
> > cause message? Ljava/lang/String? Those aren't actually in your
> > code? Are they? The "L" and "IL" a probably an artifact of the java
> > compiler, but maybe do a search for "Ljava" in your source code--just
> > to be sure...
> >
> > There is also mention of a FileRenamePolicy. Do you have "write"
> > permissions to the area at which the uploaded file is to be copied?
> >
> > AS/400s use EBCDIC (crazy IBM sticking to their own inventions)
> > instead of ASCII. Could that be a problem?
> >
> > At 21:50 2003-02-06 -0500, you wrote:
> >
> >> No difference in common. I've installed 4.1.18 and still getting the
> >> same error. Could the AS/400 JVM be suspect?
> >>
> >> Thanx, PLA
> >>
> >>
> >>> root cause
> >>>
> >>> java.lang.NoClassDefFoundError: javax/servlet/http/HttpServletRequest
> >>> java/lang/Throwable.(Ljava/lang/String;)V+4 (Throwable.java:90)
> >>> java/lang/LinkageError.(Ljava/lang/String;)V+1
> >>> (LinkageError.java:39)
> >>> java/lang/NoClassDefFoundError.(Ljava/lang/String;)V+1
> >>> (NoClassDefFoundError.java:43)
> >>>
com/oreilly/servlet/multipart/MultipartParser.(Ljavax/servlet/http/HttpServl
etRequest;IZZ)V+23
> >>> (MultipartParser.java:114)
> >>>
com/oreilly/servlet/multipart/MultipartParser.(Ljavax/servlet/http/HttpServl
etRequest;I)V+1
> >>> (MultipartParser.java:94)
> >>>
com/oreilly/servlet/MultipartRequest.(Ljavax/servlet/http/HttpServletRequest
;Ljava/lang/String;ILjava/lang/String;Lcom/oreilly/servlet/multipart/FileRen
amePolicy;)V+148
> >>> (MultipartRequest.java:219)
> >>>
com/oreilly/servlet/MultipartRequest.(Ljavax/servlet/http/HttpServletRequest
;Ljava/lang/String;ILcom/oreilly/servlet/multipart/FileRenamePolicy;)V+1
> >>> (MultipartRequest.java:148)
> >>>
FileUploadDownloadServlet3.performUpload(Ljavax/servlet/http/HttpServletRequ
est;Ljavax/servlet/http/HttpServletResponse;)V+0
> >>> (FileUploadDownloadServlet3.java:293)
> >>> FileUploadDownloadServlet3.doPost(Ljavax/servlet/http/HttpServletReque
st;Ljavax/servlet/http/HttpServletResponse;)V+0
> >>> (FileUploadDownloadServlet3.java:57)
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > Sean Dockery
> > [EMAIL PROTECTED]
> > Certified Java Web Component Developer
> > Certified Delphi Programmer
> > SBD Consultants
> > http://www.sbdconsultants.com
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
