Home » Eclipse Projects » Remote Application Platform (RAP) » Changes to Upload widgets (sandbox)
| Changes to Upload widgets (sandbox) [message #77491] |
Sun, 09 March 2008 05:58  |
Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi all,
I run into a problem using the upload widget. Debugging the problem I
detected that System.getProperty("java.io.tmpdir") returns a different value
in my demo app than it does in the FileUploadServlet. I'm not sure at the
moment how this can happen, but anyway I think that servlets should use the
servlets temp directory available using:
ServletContext context = session.getServletContext();
File tempDir = ( File )context.getAttribute(
"javax.servlet.context.tempdir" );
Another problem seems to me that each session uses the same temp dir, which
can cause problems, if different sessions try to upload a file with the same
name. Digging into this I noticed additionally that the upload also creates
a new session, which I think is undesirable.
To solve these problems I've made some changes in the Upload plugin and RAP.
I've registered the upload servlet to the RAP Servlet Context (see
plugin.xml). This ensures that the upload takes place in the same session in
which the according workbench exists. I provided a new method
Upload#getLastUploadedFile() that returns an java.io.File handle pointing to
the uploaded file. Each session uses an own temp directory for uploading, so
uploading files with the same name in different sessions should not
conflict. Usage:
final Upload upload = new Upload( parent, SWT.NONE, null, true );
UploadAdapter uploadAdapter = new UploadAdapter() {
public void uploadFinished( final UploadEvent uploadEvent ) {
if( uploadEvent.isFinished() ) {
File lastUploadedFile = upload.getLastUploadedFile();
[...]
}
}
};
upload.addUploadListener( uploadAdapter );
Note that I've set the showProgress parameter of the Upload constructor to
true. It didn't work with the parameter set to false. I will have a look at
this at a later point in time.
Giving the whole thing a second thought I'm not sure whether it is a good
idea to save the file in the temp directory with the 'original' name, maybe
we should use a more 'cryptical' name to avoid any conflicts at all.
Changes are in CVS, note that you also have to update the RAP bundles to get
everything to work.
Ciao
Frank
|
|
|
| Re: Changes to Upload widgets (sandbox) [message #77661 is a reply to message #77491] |
Mon, 10 March 2008 11:23  |
| Eclipse User |
|
|
|
Hi Frank,
thanks very much for improving the file upload component - just in time
for us :-)
However, after getting the latest CVS HEAD I get a compile error in
WorkbenchPlugin.java:
servlet.start( Bundle.START_ACTIVATION_POLICY );
The constant cannot be resolved. Did I miss anything?
When using the file upload widget I experience some problems, too.
If the upload widget is put on a shell which is disposed on close and
after that opened again, a JS error ocurrs.
Fileupload doesn't work either (servlet is never called), but I suppose
this has sth to do with the line above in WorkbenchPlugin (which I
removed for testing purposes).
I would suggest that I'll take a look at the JS issue. Do you have time
to take a look at the other problem?
Regards,
Stefan.
Frank Appel schrieb:
> Hi all,
>
> I run into a problem using the upload widget. Debugging the problem I
> detected that System.getProperty("java.io.tmpdir") returns a different value
> in my demo app than it does in the FileUploadServlet. I'm not sure at the
> moment how this can happen, but anyway I think that servlets should use the
> servlets temp directory available using:
>
> ServletContext context = session.getServletContext();
> File tempDir = ( File )context.getAttribute(
> "javax.servlet.context.tempdir" );
>
> Another problem seems to me that each session uses the same temp dir, which
> can cause problems, if different sessions try to upload a file with the same
> name. Digging into this I noticed additionally that the upload also creates
> a new session, which I think is undesirable.
>
> To solve these problems I've made some changes in the Upload plugin and RAP.
> I've registered the upload servlet to the RAP Servlet Context (see
> plugin.xml). This ensures that the upload takes place in the same session in
> which the according workbench exists. I provided a new method
> Upload#getLastUploadedFile() that returns an java.io.File handle pointing to
> the uploaded file. Each session uses an own temp directory for uploading, so
> uploading files with the same name in different sessions should not
> conflict. Usage:
>
> final Upload upload = new Upload( parent, SWT.NONE, null, true );
> UploadAdapter uploadAdapter = new UploadAdapter() {
> public void uploadFinished( final UploadEvent uploadEvent ) {
> if( uploadEvent.isFinished() ) {
> File lastUploadedFile = upload.getLastUploadedFile();
> [...]
> }
> }
> };
> upload.addUploadListener( uploadAdapter );
>
> Note that I've set the showProgress parameter of the Upload constructor to
> true. It didn't work with the parameter set to false. I will have a look at
> this at a later point in time.
>
> Giving the whole thing a second thought I'm not sure whether it is a good
> idea to save the file in the temp directory with the 'original' name, maybe
> we should use a more 'cryptical' name to avoid any conflicts at all.
>
> Changes are in CVS, note that you also have to update the RAP bundles to get
> everything to work.
>
>
> Ciao
> Frank
>
>
|
|
| |
| Re: Changes to Upload widgets (sandbox) [message #77833 is a reply to message #77677] |
Tue, 11 March 2008 03:51 |
| Eclipse User |
|
|
|
Hi Frank,
was this dependency to 3.3 intended? Until now, everything works fine
with 3.2 either...
Regards,
Stefan.
Matthias Maar schrieb:
> Hi Stefan,
>
> the constant is available beginning with Eclipse target 3.3 and is
> defined as:
> public static final int START_ACTIVATION_POLICY = 0x00000002;
>
> Greetings,
> Matthias
>
>
> Stefan Röck schrieb:
>> Hi Frank,
>>
>> thanks very much for improving the file upload component - just in
>> time for us :-)
>>
>> However, after getting the latest CVS HEAD I get a compile error in
>> WorkbenchPlugin.java:
>> servlet.start( Bundle.START_ACTIVATION_POLICY );
>>
>> The constant cannot be resolved. Did I miss anything?
>>
>> When using the file upload widget I experience some problems, too.
>> If the upload widget is put on a shell which is disposed on close and
>> after that opened again, a JS error ocurrs.
>>
>> Fileupload doesn't work either (servlet is never called), but I
>> suppose this has sth to do with the line above in WorkbenchPlugin
>> (which I removed for testing purposes).
>>
>> I would suggest that I'll take a look at the JS issue. Do you have
>> time to take a look at the other problem?
>>
>> Regards,
>> Stefan.
|
|
|
| Re: Changes to Upload widgets (sandbox) [message #77864 is a reply to message #77833] |
Tue, 11 March 2008 09:23 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi Stefan,
it wasn't actually intended, but with the current development stream
towards the 1.1 Release we skipped the 3.2 support. I even don't know if
the functionality used in the particular code fragment is already
available with 3.2.
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Stefan Röck [mailto:stefan.roeck@cas.de]
Bereitgestellt: Dienstag, 11. März 2008 08:51
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: Changes to Upload widgets (sandbox)
Betreff: Re: Changes to Upload widgets (sandbox)
Hi Frank,
was this dependency to 3.3 intended? Until now, everything works fine
with 3.2 either...
Regards,
Stefan.
Matthias Maar schrieb:
> Hi Stefan,
>
> the constant is available beginning with Eclipse target 3.3 and is
> defined as:
> public static final int START_ACTIVATION_POLICY = 0x00000002;
>
> Greetings,
> Matthias
>
>
> Stefan Röck schrieb:
>> Hi Frank,
>>
>> thanks very much for improving the file upload component - just in
>> time for us :-)
>>
>> However, after getting the latest CVS HEAD I get a compile error in
>> WorkbenchPlugin.java:
>> servlet.start( Bundle.START_ACTIVATION_POLICY );
>>
>> The constant cannot be resolved. Did I miss anything?
>>
>> When using the file upload widget I experience some problems, too.
>> If the upload widget is put on a shell which is disposed on close and
>> after that opened again, a JS error ocurrs.
>>
>> Fileupload doesn't work either (servlet is never called), but I
>> suppose this has sth to do with the line above in WorkbenchPlugin
>> (which I removed for testing purposes).
>>
>> I would suggest that I'll take a look at the JS issue. Do you have
>> time to take a look at the other problem?
>>
>> Regards,
>> Stefan.
|
|
|
| Re: Changes to Upload widgets (sandbox) [message #78293 is a reply to message #77864] |
Fri, 14 March 2008 07:38 |
| Eclipse User |
|
|
|
Originally posted by: nindl_go.hotmail.com
Hi Frank,
Thanks for your update of the file upload, but it doesn't work out for me.
There are a number of problems,
which I fixed as the following:
1) In the plugin.xml of the org.eclipse.rwt.widgets.upload, I had to remove
the plugin dependency "javax.servlet" and replace it
by two entries in the "Imported packages", namely "javax.servlets" and
"javax.servlets.http" in order to sucessfully start this
plugin on a tomcat.
2) I had to remove the httpcontextId, otherwise the file is not uploaded at
all (doPost of the FileUploadServlet is never called)
3) The static "getUploadTempDir" method of the "FileUploadServlet" class is
called twice. First, when the
file is uploaded in the "doPost" method of the "FileUploadServlet" and
second, when the "Upload" class
asks for the uploaded file with the "getLastUploadedFile()". The problem
occurs with the following
command in the method "getUploadTempDir":
File tempDir = ( File )context.getAttribute( CONTEXT_TEMP_DIR );
The command returns different directories for the same file upload. The
logic consequence is that
the file cannot be found. Actually two different directories are created,
whereas the first contains the
uploaded file, which cannot be found in the newly created directory of the
second call.
My workaround for this problem is like this:
a) Add the temporary file to session at the end of the
"getUploadTempDir" method like this:
session.setAttribute(CONTEXT_TEMP_DIR, result);
b) I make the static variable of the FileUploadServlet public like this:
public static final String CONTEXT_TEMP_DIR =
"javax.servlet.context.tempdir";
c) Finally I replace the second line of the "getLastUploadedFile()"
method in the "Upload" class in
order to get the file from the session:
File tmpDir =
(File)session.getAttribute(FileUploadServlet.CONTEXT_TEMP_DI R);
4) This was sufficient in order to run RAP in Eclipse hosted mode. When I
deployed the RAP application on
a tomcat the file upload couldn't be processed again. I detected the cause
when I wanted to call the upload
servlet directly by an URL in the browser, like
http://localhost:8080/<webappname>/upload. Instead of a sucessfull
byte read response the servlet returned a ClassNotFoundException. The
org.apache.commons.* classes of the
org.apache.commons.fileupload couldn't be found, although the plugin is
marked as ACTIVE in the Osgi console.
Is this some plugin-dependency OSGI framework problem? I just copied the
source classes of the
org.eclipse.commons.fileupload and the org.eclipse.commons.io to the
org.eclipse.rap.rwt.widgets.upload plugin and deleted
the unneccessary org.eclipse.commons.fileupload.portlet. A pretty dirty way
but I can invoke the upload servlet sucessfully
in a servlet container. Almost done, just a final fix
5) Point to the Chenney Chen's solution in the newsgroup entry
http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg02308.html
I did the following
String application = RWT.getRequest().getContextPath();
application = application.trim();
final Upload upload1 = new Upload(firstCp, 0, application + "/upload",true);
Finally I can use the upload in Eclipse AND tomcat mode. Am I missing
something? For sure there is
an easier to do this. See the attachments for the code.
Regards, Gottfried
|
|
|
| Re: Changes to Upload widgets (sandbox) [message #78337 is a reply to message #78293] |
Fri, 14 March 2008 09:58 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi Gottfried,
thank you for your information on the fileupload widget. I'm currently
spending some time on the upload widget and hopefully at the end there
will be a solution that works for all. Unfortunately I'm out for
EclipseCon next week, so don't expect the next steps happening too
soon...
Now to your points.
1) This is true, I didn't check the import strategie of the original
implementation.
2) Removing the context id leeds for me to the problems you've
encountered in (3). So that was originally the reason for introducing
it- this is very strange. What osgi, http.service, RAP (guess CVS-Head)
etc. versions do you use (just asking in order not to miss something). I
will have a deeper look at that.
3) See comments on (2). It seems as if you can retrieve the same session
from different httpContexts - hm. Maybe I've misunderstood what
HttpContext is all about - The API say "Servlets that are registered
using the same HttpContext object will share the same ServletContext
object". So how can sessions of different contexts exchange data (ok,
you could use cross-context configuration on a servlet container, but I
don't think that this is done here)? As mentioned above I will have a
deeeep look at this.
4) This looks also very odd to me. Back from ECon I will deploy my
simple upload demo on a tomcat to see if I can reproduce your problem.
5) I think this could be build into the Upload itself.
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Gottfried Nindl [mailto:nindl_go@hotmail.com]
Bereitgestellt: Freitag, 14. März 2008 12:38
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: Changes to Upload widgets (sandbox)
Betreff: Re: Changes to Upload widgets (sandbox)
Hi Frank,
Thanks for your update of the file upload, but it doesn't work out for
me.
There are a number of problems,
which I fixed as the following:
1) In the plugin.xml of the org.eclipse.rwt.widgets.upload, I had to
remove the plugin dependency "javax.servlet" and replace it by two
entries in the "Imported packages", namely "javax.servlets" and
"javax.servlets.http" in order to sucessfully start this plugin on a
tomcat.
2) I had to remove the httpcontextId, otherwise the file is not uploaded
at all (doPost of the FileUploadServlet is never called)
3) The static "getUploadTempDir" method of the "FileUploadServlet" class
is called twice. First, when the file is uploaded in the "doPost" method
of the "FileUploadServlet" and second, when the "Upload" class asks for
the uploaded file with the "getLastUploadedFile()". The problem occurs
with the following command in the method "getUploadTempDir":
File tempDir = ( File )context.getAttribute( CONTEXT_TEMP_DIR );
The command returns different directories for the same file upload. The
logic consequence is that the file cannot be found. Actually two
different directories are created, whereas the first contains the
uploaded file, which cannot be found in the newly created directory of
the second call.
My workaround for this problem is like this:
a) Add the temporary file to session at the end of the
"getUploadTempDir" method like this:
session.setAttribute(CONTEXT_TEMP_DIR, result);
b) I make the static variable of the FileUploadServlet public like
this:
public static final String CONTEXT_TEMP_DIR =
"javax.servlet.context.tempdir";
c) Finally I replace the second line of the "getLastUploadedFile()"
method in the "Upload" class in
order to get the file from the session:
File tmpDir =
(File)session.getAttribute(FileUploadServlet.CONTEXT_TEMP_DI R);
4) This was sufficient in order to run RAP in Eclipse hosted mode. When
I deployed the RAP application on a tomcat the file upload couldn't be
processed again. I detected the cause when I wanted to call the upload
servlet directly by an URL in the browser, like
http://localhost:8080/<webappname>/upload. Instead of a sucessfull byte
read response the servlet returned a ClassNotFoundException. The
org.apache.commons.* classes of the
org.apache.commons.fileupload couldn't be found, although the plugin is
marked as ACTIVE in the Osgi console.
Is this some plugin-dependency OSGI framework problem? I just copied the
source classes of the org.eclipse.commons.fileupload and the
org.eclipse.commons.io to the org.eclipse.rap.rwt.widgets.upload plugin
and deleted the unneccessary org.eclipse.commons.fileupload.portlet. A
pretty dirty way but I can invoke the upload servlet sucessfully in a
servlet container. Almost done, just a final fix
5) Point to the Chenney Chen's solution in the newsgroup entry
http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg02308.ht
ml
I did the following
String application = RWT.getRequest().getContextPath();
application = application.trim();
final Upload upload1 = new Upload(firstCp, 0, application +
"/upload",true);
Finally I can use the upload in Eclipse AND tomcat mode. Am I missing
something? For sure there is an easier to do this. See the attachments
for the code.
Regards, Gottfried
|
|
|
| Re: Changes to Upload widgets (sandbox) [message #78665 is a reply to message #78337] |
Tue, 18 March 2008 11:13 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------040509090109020902040705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
additionally to the mentioned points some other things came into my mind:
1. Security
To prevent other people from uploading huge files on my server without
permission, an authentication check should be performed in the upload
servlet.
2. Disk memory
The current solution stores a file on the server (which the Apache
common libs do as well for larger files) and never deletes it again.
Wouldn't it be a better aproach to use the DiskFileItemFactory from the
commons lib and return only a reference to the stored DiskFileItem to
the Upload widget? Than, the standard "reaper thread" [1] could manage
the deletion of temporary files.
I used the file upload widget without the provided servlet but
implemented a ServiceHandler which handles above mentioned issues.
However, this can be hardly done generic without application specific stuff.
Last point: I created a patch which fixes a smaller issue in
Upload.java. The current fireUploadEvent implementation doesn't allow
registered listeners to remove themselves in their
listener-implementation. This patch is attached.
Regards,
Stefan.
[1] http://commons.apache.org/fileupload/using.html
--------------040509090109020902040705
Content-Type: text/plain;
name="upload_patch.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="upload_patch.txt"
### Eclipse Workspace Patch 1.0
#P org.eclipse.rwt.widgets.upload
Index: src/org/eclipse/rwt/widgets/Upload.java
============================================================ =======
RCS file: /cvsroot/technology/org.eclipse.rap/sandbox/org.eclipse.rwt. widgets.upload/src/org/eclipse/rwt/widgets/Upload.java,v
retrieving revision 1.5
diff -u -r1.5 Upload.java
--- src/org/eclipse/rwt/widgets/Upload.java 14 Mar 2008 12:31:08 -0000 1.5
+++ src/org/eclipse/rwt/widgets/Upload.java 18 Mar 2008 15:11:28 -0000
@@ -394,9 +394,11 @@
public final synchronized void fireUploadEvent(
final UploadEvent uploadEvent )
{
- final Iterator listeners = uploadListeners.iterator();
- while( listeners.hasNext() ) {
- ( ( UploadAdapter )listeners.next() ).uploadFinished( uploadEvent );
+ // Copy listener list to allow listeners to remove themselves in their implementation
+ List listeners = new ArrayList(uploadListeners);
+ final Iterator iterator = listeners.iterator();
+ while( iterator.hasNext() ) {
+ ( ( UploadAdapter )iterator.next() ).uploadFinished( uploadEvent );
}
}
--------------040509090109020902040705--
|
|
|
Goto Forum:
Current Time: Tue Apr 29 03:00:49 EDT 2025
Powered by FUDForum. Page generated in 0.29280 seconds |
Home