I have fixed the issue with getName() returning a path instead of the file name only, which was indeed creating this error as I have been able to reproduce it.
@Marco: I have been able to get your test case to work reliably (without any change in the scripts) on IE 7/8 - Firefox 3.6 - Chrome 7 - Safari 5
I cannot send you a plugin to test as the changes made are also in some of the core Servoy libraries, but a patch has been sent to Johan, hope this will make it for Servoy 5.2.3!
@Scott: I have added a new getDefaultUploadLocation() method which will give you the server-side path of the upload folder.
Johan applied the patch but I don’t know if this will be part of the next (5.2.3) release.
I have the file plugin working in my localhost (servoy-admin) and see under server plugins, and emtpy line where I can fill in the path.
I have zipped my plugins & beans & libs folder and deployed them to my prod server. (they where already signed by the signtester)
Now when I start the server, I get this error in the log:
[attachment=0]Schermafbeelding 2011-01-20 om 21.46.06.png[/attachment]
and I don’t see the plugin under server plugins in de servoy-admin page.!
Also no entry is found, in the servoy.properties file.
I have checked, and there is a folder: …ROOT/uploads.
I have started the application_server as a system service, and all system users has full read-write access to that folder.
Not sure why it cannot resolve the upload directory, if the “servoy.FileServerService.defaultFolder” is null or empty (you can always set it yourself in the servoy.properties file), the plugin will try looking for the ROOT/uploads from the place where it was started, which could be the bat or sh file if you launch it from the command line, or the inside of the Servoy.app bundle on Mac OS X when you launch from Developer, or the user home (the user being the one who launched Servoy) if all else fail… In the case if your error, none of these tries worked and we ended up with a null default folder… Being launched as a service, I’m guess it first tried at the wrong place so I will have a look at that, but even so, it should at least find the home folder…
In any case, I agree that it shouldn’t bomb out and I will try to reproduce in service mode to get a better idea of where it starts and hopefully look at the right place.
But if it cannot resolve an upload directory in the end, none of the streaming functions will work, so I can trap that exception and output an ERROR in the log, although it is the subsequent calls to any streaming function which will bomb out.
I have found a fix for this: the plugin is now also searching for ROOT from the /service sub-folder (which is the ‘home’ dir path when launched from a service).
Have also caught the exception so that the plugin outputs an ERROR in the log but still loads and allow for setting the default upload folder.
Of course if this exception is found in the log, the plugin’s streaming functionality won’t be available, but the rest of the plugin will still work reliably.
So it will be up to you to give it a path to a default upload folder. The property will show in the admin.