Re: WOFileUpload ANOTHER bug
Re: WOFileUpload ANOTHER bug
- Subject: Re: WOFileUpload ANOTHER bug
- From: Aleksey Novicov <email@hidden>
- Date: Thu, 6 Mar 2003 00:05:26 -0800
Jonathan,
I'm seeing the exact same problem on Solaris. Everything works fine
under OS X - the files get uploaded to where I want them uploaded. But
deployed under Solaris, the files seem to always get put in /var/tmp,
even with the process running as root. My next strategy is to let WO do
what it wants to do, and then copy the files using Java APIs to where I
WANT them:-) If anyone comes up a solution to this problem I would love
to hear it.
On another WO 5.2 note, I have discovered another bug running with
Solaris. At startup of a new session the WO framework looks for
Main.java and Main.wo and among other things, instantiates a new Main
object. In doing so, it also initializes any WODisplayGroups that are
defined in Main.woo. The problem occurs if you have a localized version
of Main.wo in .lprof subdirectories. The framework can't find Main.woo
for the first time but still instantiates a Main object. If you have
anything in your constructor that interacts with a WODisplayGroup for
that page, you will simply get a null WODisplayGroup. For all of the
cool new stuff in WO 5.2, it really is a very buggy release.
By the way, I was also stung with the same problem you had with actions
for submit buttons associated with a WOFileUpload not being called when
submitted!
cheers,
aleksey
Okay, the new WOFileUpload is starting to really make me mad. It seems
to
be incredibly buggy. Here's what appears to me to be a bug. I would
much
appreciate it if someone else could confirm it.
I am running on Solaris. The process is running as the user 'webob'.
There
is a directory, /usr/local/apache/htdocs/. Now, /usr, /usr/local/, and
/usr/local/apache are NOT writeable by the 'webob' user. However,
/usr/local/apache/htdocs/ IS writeable by the webob user. If I use
java.io.File.createNewFile() I can succesfully create a file inside
/usr/local/apache/htdocs without any problems at all----in my same test
app, running as the user 'webob'.
However, WOFileUpload refuses to upload there. If I instruct it to
upload
there, after the upload the 'finalFilePath' binding is set to a path
in the
/var/tmp directory, and indeed this is where I find the file. No
exceptions
are generated, and even turning on FULL debugging with NSLog, no debug
messages are generated at all! There is definitely no conflict with an
existing file--I am making sure to try file paths that do not already
have
a file there.
If instead I try to upload a file to a directory where the 'webob'
user has
write permissions to every single directory along the path (for
example,
/var/tmp), then the upload works as expected, and the finalFilePath
matches
my chosen streamToFilePath binding exactly. This is what makes me
suspect
that WOFileUpload is eroneously refusing to upload a file to a
directory
unless the process has write permissions on EVERY directory in the
filepath. This is not how unix permissions work though, I don't need
write
permissions like that to write to the actual leaf directory, and I can
use
java.io.File to write there myself without a problem.
So if anyone can confirm this, that would be great. But WOFileUpload
is
really starting to enfuriate me. I had already encountered three to
four
bugs that were not show stoppers, that I was able to work around. But
this
one is a show stopper. I can not easily work around it without
compromising the security of my server. This is stupid. I am not
confident about the thoroughness that Apple tests this stuff before
sending
it out the door. I feel like I should be getting paid by Apple for
spending
my time finding these bugs; but the real problem is that I can't get
my app
to work properly. I really need the streaming API provided in 5.2.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.