Re: GAE and file uploads
Ahhh - 'pull' is a Git term. We're a subversion shop, so I know just enough Git to be dangerous...perhaps even less. FWIW, I have the file upload code updated for Wicket 1.5 and seems to be working. Hopefully I'll get some time after our release to submit Mr Ashr's code to GAE Initializer. He offered it to be added to Wicket, but I feel I need to try to get in contact with him and have him submit the code, to ensure the licensing is handled correctly. Chris On 3/10/2012 9:28 AM, Martin Grigorov wrote: Hi Chris, GAE initializer is part of WicketStuff which is hosted at github.com: https://github.com/wicketstuff/core/ See http://help.github.com/send-pull-requests/ On Thu, Mar 8, 2012 at 7:53 PM, Chris Merrill ch...@webperformance.com wrote: On 3/8/2012 11:55 AM, Martin Grigorov wrote: I'm glad you find gae-initializer project useful! Your can make a pull request with the upgraded to 1.5 code so other people can gain from it too. What is a pull request? Is it a different kind of file upload? -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com| http://webperformance.com 919-433-1762| 919-845-7601 Web Performance: Website Load Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com| http://webperformance.com 919-433-1762| 919-845-7601 Web Performance: Website Load Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: GAE and file uploads
Cool! If you don't want to bother with Git then just paste your code in the issue tracker at https://github.com/wicketstuff/core/issues (when all licensing is OK) On Thu, Mar 15, 2012 at 5:25 PM, Chris Merrill ch...@webperformance.com wrote: Ahhh - 'pull' is a Git term. We're a subversion shop, so I know just enough Git to be dangerous...perhaps even less. FWIW, I have the file upload code updated for Wicket 1.5 and seems to be working. Hopefully I'll get some time after our release to submit Mr Ashr's code to GAE Initializer. He offered it to be added to Wicket, but I feel I need to try to get in contact with him and have him submit the code, to ensure the licensing is handled correctly. Chris On 3/10/2012 9:28 AM, Martin Grigorov wrote: Hi Chris, GAE initializer is part of WicketStuff which is hosted at github.com: https://github.com/wicketstuff/core/ See http://help.github.com/send-pull-requests/ On Thu, Mar 8, 2012 at 7:53 PM, Chris Merrill ch...@webperformance.com wrote: On 3/8/2012 11:55 AM, Martin Grigorov wrote: I'm glad you find gae-initializer project useful! Your can make a pull request with the upgraded to 1.5 code so other people can gain from it too. What is a pull request? Is it a different kind of file upload? -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com | http://webperformance.com 919-433-1762 | 919-845-7601 Web Performance: Website Load Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com | http://webperformance.com 919-433-1762 | 919-845-7601 Web Performance: Website Load Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: GAE and file uploads
Hi Chris, GAE initializer is part of WicketStuff which is hosted at github.com: https://github.com/wicketstuff/core/ See http://help.github.com/send-pull-requests/ On Thu, Mar 8, 2012 at 7:53 PM, Chris Merrill ch...@webperformance.com wrote: On 3/8/2012 11:55 AM, Martin Grigorov wrote: I'm glad you find gae-initializer project useful! Your can make a pull request with the upgraded to 1.5 code so other people can gain from it too. What is a pull request? Is it a different kind of file upload? -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com | http://webperformance.com 919-433-1762 | 919-845-7601 Web Performance: Website Load Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
GAE and file uploads
I've run to an issue with file uploads on GAE - after the file upload exceeds a certain size (~10k?), the default file upload implementation writes to disk, which is not allowed in GAE. I found this previous post: http://apache-wicket.1842946.n4.nabble.com/Wicket-and-FileUpload-on-Google-App-Engine-td1889030.html by Uud Ashr with a solution. However, that solution appears to be for Wicket 1.4 (or earlier?). The Wicket-stuff GAE package, which I'm using, doesn't address file uploads. So I'm planning to upgrade the code proposed by Mr Ashr to 1.5, but thought I should check here first so I don't re-invent the wheel. Does anyone know if this problem has already been solved for GAE, Wicket 1.5 and file uploads? TIA! Chris -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com| http://webperformance.com 919-433-1762| 919-845-7601 Web Performance: Website Load Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: GAE and file uploads
Hi Chris, I'm glad you find gae-initializer project useful! Your can make a pull request with the upgraded to 1.5 code so other people can gain from it too. On Thu, Mar 8, 2012 at 6:43 PM, Chris Merrill ch...@webperformance.com wrote: I've run to an issue with file uploads on GAE - after the file upload exceeds a certain size (~10k?), the default file upload implementation writes to disk, which is not allowed in GAE. I found this previous post: http://apache-wicket.1842946.n4.nabble.com/Wicket-and-FileUpload-on-Google-App-Engine-td1889030.html by Uud Ashr with a solution. However, that solution appears to be for Wicket 1.4 (or earlier?). The Wicket-stuff GAE package, which I'm using, doesn't address file uploads. So I'm planning to upgrade the code proposed by Mr Ashr to 1.5, but thought I should check here first so I don't re-invent the wheel. Does anyone know if this problem has already been solved for GAE, Wicket 1.5 and file uploads? TIA! Chris -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com | http://webperformance.com 919-433-1762 | 919-845-7601 Web Performance: Website Load Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: GAE and file uploads
On 3/8/2012 11:55 AM, Martin Grigorov wrote: I'm glad you find gae-initializer project useful! Your can make a pull request with the upgraded to 1.5 code so other people can gain from it too. What is a pull request? Is it a different kind of file upload? -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com| http://webperformance.com 919-433-1762| 919-845-7601 Web Performance: Website Load Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous File Uploads
Thanks for the suggestion. Since our Wicket application is presently a singular page, I can kind of imagine how this could work assuming the 'iframe' is embedded in the outermost part of the HTML (thus lies outside of any potential AJAX refreshes by Wicket). It will also mean that we must stick to this singular page (i.e. no page changes as part of the user workflow), otherwise I can imagine the 'iframe' would be lost/reset. So I'm guessing this is how it would work: - have a form that submits to the separate servlet being embedded in the hidden iframe - the fields for that hidden iframe form correspond directly to what the user is expected to input via a Wicket form - upon hitting the submit button on the Wicket form, it copies all the contents of the fields (using JS?) from the Wicket form to the hidden iframe form - finally we trigger the submit on the hidden iframe form using JS It sounds like it has potential, but not as clean/quick to implement as I was originally hoping for. Would anyone perchance have already tried this strategy and got it working? Kind Regards, Eric. - Eric is learning how to use Wicket and enjoying the experience so far... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p3086678.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous File Uploads
not sure if this would work, but create another pagemap for your large form and submit to that (if you are trying to keep everything in the wicket world). keep the default pagemap (null) for your short lived requests. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p3086723.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous File Uploads
Use a hidden Iframe to make your upload using the Servlet approach that Jeremy describe. On Fri, Dec 10, 2010 at 2:12 AM, exl [via Apache Wicket] ml-node+3081409-1187169087-65...@n4.nabble.comml-node%2b3081409-1187169087-65...@n4.nabble.com wrote: Hi again, This is how I interpreted your last post Jeremy (please see attached code fragments: TestingServlet.txthttp://apache-wicket.1842946.n4.nabble.com/file/n3081409/TestingServlet.txt) The new approach appears to trigger the separate servlet, but the problem is that it also redirects the browser to the separate servlet's URL (and confirms my suspicion that the Wicket application loses control as I queried in a previous post). The requirements I'm trying to achieve are: - The Wicket application accepts parameters from the user, potentially including a file upload. - When the user hits submit, some processing needs to be done in the background to update the backend (e.g. decode and import the contents of the file). - However, the user should be allowed to continue doing other things in the Wicket application. - The user will be notified via email that the background processing has been completed and then they can come back to interact with the newly created information. So am I still approaching this correctly? Thanks in advanced, Eric. -- View message @ http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p3081409.html To start a new topic under Apache Wicket, email ml-node+1842946-398011874-65...@n4.nabble.comml-node%2b1842946-398011874-65...@n4.nabble.com To unsubscribe from Apache Wicket, click herehttp://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=. -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) --Anyone who has never made a mistake has never tried anything new.-- -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p3081888.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous File Uploads
Hi again, This is how I interpreted your last post Jeremy (please see attached code fragments: http://apache-wicket.1842946.n4.nabble.com/file/n3081409/TestingServlet.txt TestingServlet.txt ) The new approach appears to trigger the separate servlet, but the problem is that it also redirects the browser to the separate servlet's URL (and confirms my suspicion that the Wicket application loses control as I queried in a previous post). The requirements I'm trying to achieve are: - The Wicket application accepts parameters from the user, potentially including a file upload. - When the user hits submit, some processing needs to be done in the background to update the backend (e.g. decode and import the contents of the file). - However, the user should be allowed to continue doing other things in the Wicket application. - The user will be notified via email that the background processing has been completed and then they can come back to interact with the newly created information. So am I still approaching this correctly? Thanks in advanced, Eric. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p3081409.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous File Uploads
Hi.
Ok, I'm trying to go down the path of what I believe is being suggested
here. So this is what I have as the servlet so far:
{code}
public class HelloServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Autowired
private IOurService serviceInst;
public void init(ServletConfig config) throws ServletException {
super.init(config);
SpringBeanAutowiringSupport.processInjectionBasedOnCurrentContext(this);
}
public void doGet (HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
// get an PrintWriter from the response object
PrintWriter out = response.getWriter();
out.println(Used doGet - doPostbr);
doPost(request, response);
}
public void doPost (HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
// get an PrintWriter from the response object
PrintWriter out = response.getWriter();
// prepare the response's content type
response.setContentType(text/html);
// get the IP address of the client
String remoteAddress = request.getRemoteAddr();
// print to the output stream!
out.println(Hello there, web surfer from + remoteAddress +
);
String firstName = request.getParameter(firstName);
out.println(First name was: + firstName);
// This will handle pre-processing the large file for import
into the
database and thus take a long time...
serviceInst.testImport(request);
}
}
{code}
Then I have a Wicket button to submit to this servlet, but it is blocking
(i.e. not asynchronous):
{code}
testForm.add(new Button(Upload, new
StringResourceModel(page.helloServlet, this, null))
{
public void onSubmit()
{
ServletWebRequest servletWebRequest =
(ServletWebRequest) getRequest();
HttpServletRequest request =
servletWebRequest.getHttpServletRequest();
WebResponse webResponse = (WebResponse)
getRequestCycle().getOriginalResponse();
HttpServletResponse response =
webResponse.getHttpServletResponse();
RequestDispatcher dispatcher =
((ServletWebRequest)
getRequest()).getHttpServletRequest().getRequestDispatcher(Constants.HELLOSERVLET);
GenericServletResponseWrapper wrappedResponse =
new
GenericServletResponseWrapper(response);
try {
log.info(Forwarding request to Hello
Servlet);
dispatcher.forward(request,
wrappedResponse);
log.info(response from servlet: + new
String(wrappedResponse.getData()));
} catch (ServletException e) {
throw new RuntimeException(e);
} catch (IOException e) {
throw new RuntimeException(e);
}
log.info(Returned from forward to Hello
Servlet);
}
});
{code}
So synchronously I can get the servlet to handle my request, which prevents
the user from doing other things in the Wicket application until it returns.
What is the final step to get it handling asynchronously?
Kind Regards,
Eric.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p3077633.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous File Uploads
On Tue, Dec 7, 2010 at 8:53 PM, exl eric@uwa.edu.au wrote:
Hi.
Ok, I'm trying to go down the path of what I believe is being suggested
here. So this is what I have as the servlet so far:
{code}
public class HelloServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Autowired
private IOurService serviceInst;
public void init(ServletConfig config) throws ServletException {
super.init(config);
SpringBeanAutowiringSupport.processInjectionBasedOnCurrentContext(this);
}
public void doGet (HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
// get an PrintWriter from the response object
PrintWriter out = response.getWriter();
out.println(Used doGet - doPostbr);
doPost(request, response);
}
public void doPost (HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
// get an PrintWriter from the response object
PrintWriter out = response.getWriter();
// prepare the response's content type
response.setContentType(text/html);
// get the IP address of the client
String remoteAddress = request.getRemoteAddr();
// print to the output stream!
out.println(Hello there, web surfer from + remoteAddress
+ );
String firstName = request.getParameter(firstName);
out.println(First name was: + firstName);
// This will handle pre-processing the large file for import
into the
database and thus take a long time...
serviceInst.testImport(request);
}
}
{code}
Then I have a Wicket button to submit to this servlet, but it is blocking
(i.e. not asynchronous):
{code}
testForm.add(new Button(Upload, new
StringResourceModel(page.helloServlet, this, null))
{
public void onSubmit()
{
ServletWebRequest servletWebRequest =
(ServletWebRequest) getRequest();
HttpServletRequest request =
servletWebRequest.getHttpServletRequest();
WebResponse webResponse = (WebResponse)
getRequestCycle().getOriginalResponse();
HttpServletResponse response =
webResponse.getHttpServletResponse();
RequestDispatcher dispatcher =
((ServletWebRequest)
getRequest()).getHttpServletRequest().getRequestDispatcher(Constants.HELLOSERVLET);
GenericServletResponseWrapper
wrappedResponse = new
GenericServletResponseWrapper(response);
try {
log.info(Forwarding request to
Hello Servlet);
dispatcher.forward(request,
wrappedResponse);
log.info(response from servlet: +
new
String(wrappedResponse.getData()));
} catch (ServletException e) {
throw new RuntimeException(e);
} catch (IOException e) {
throw new RuntimeException(e);
}
log.info(Returned from forward to Hello
Servlet);
}
});
{code}
So synchronously I can get the servlet to handle my request, which prevents
the user from doing other things in the Wicket application until it
returns.
What is the final step to get it handling asynchronously?
Kind Regards,
Eric.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p3077633.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
You are doing this:
browser -- submits to Wicket -- submits to servlet
The whole point of writing a servlet was to take Wicket out of that loop.
You should be doing this:
browser -- submits to servlet
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Asynchronous File Uploads
Thanks for the reply. Sure - I can understand that if the client submits the form directly to the separate servlet, then this would achieve the background processing thread on the server side. However, wouldn't this mean that the Wicket application loses control in that client browser window, since it has been passed over to the separate servlet? The only way I can see this setup working in the sense that a client to be able to continue working somewhere else (perhaps on a different page of the Wicket application) whilst uploading, would be to open a new browser window on the client and have that new window perform the submit to the separate servlet. Our Wicket application is stateful, but hopefully the opening on a new window wouldn't cause problems. So am I on the right track with the above or am I missing something here? Also, would it still be possible to use Wicket components with a submit form posting to the separate servlet? I'm just thinking if I wanted to use Wicket's single file upload (demonstrated here: http://wicketstuff.org/wicket/upload/single?0), whether that would still be possible. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p3077766.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous File Uploads
If you use Wicket to process a request, it is going to synchronize on the page map (up through 1.4.x). This means that any request that is bound to a page (like a form, which is stateful) will result in synchronization. The stateful forms in Wicket submit back to themselves, which means they will always be synchronizing on the pagemap that contains the page that contains the form. No other requests can happen on that pagemap until that one is complete. So, you can submit to another servlet. All you need to do is create a form action=http://server:port/url-to-your-servlet; method=post... etc ... /form. You can use Wicket to create this form tag in your page, although you probably wouldn't use a Form component for this, because you won't actually be using the processing that the form component provides. You would probably just use a WebMarkupContainer, override onComponentTag, and do tag.put(action, yourUrl) to put the URL in the tag. If you don't think that's what you want, please describe the actual problem a little more. On Wed, Dec 8, 2010 at 12:32 AM, exl eric@uwa.edu.au wrote: Thanks for the reply. Sure - I can understand that if the client submits the form directly to the separate servlet, then this would achieve the background processing thread on the server side. However, wouldn't this mean that the Wicket application loses control in that client browser window, since it has been passed over to the separate servlet? The only way I can see this setup working in the sense that a client to be able to continue working somewhere else (perhaps on a different page of the Wicket application) whilst uploading, would be to open a new browser window on the client and have that new window perform the submit to the separate servlet. Our Wicket application is stateful, but hopefully the opening on a new window wouldn't cause problems. So am I on the right track with the above or am I missing something here? Also, would it still be possible to use Wicket components with a submit form posting to the separate servlet? I'm just thinking if I wanted to use Wicket's single file upload (demonstrated here: http://wicketstuff.org/wicket/upload/single?0), whether that would still be possible. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p3077766.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Asynchronous File Uploads
Hi All Has anyone had a requirement to upload huge files in an asynchronous mode? I want to be able to upload some files which are on avg 4G plus. I read some posts that wicket does fine with 50 plus megs. Since these are huge files, we dont want the user to be blocked. Instead was thinking kicking off a Job that takes these files and then notifies the user. If wicket application can be configured to upload these files makes it easy with just the file upload without a-synching, But if there is an elegant solution can someone share their experiences? Many thanks Niv
Re: Asynchronous File Uploads
use a servlet -igor On Thu, Sep 16, 2010 at 2:42 AM, Nivedan Nadaraj shravann...@gmail.com wrote: Hi All Has anyone had a requirement to upload huge files in an asynchronous mode? I want to be able to upload some files which are on avg 4G plus. I read some posts that wicket does fine with 50 plus megs. Since these are huge files, we dont want the user to be blocked. Instead was thinking kicking off a Job that takes these files and then notifies the user. If wicket application can be configured to upload these files makes it easy with just the file upload without a-synching, But if there is an elegant solution can someone share their experiences? Many thanks Niv - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous File Uploads
Thanks mate, I will investigate more on this, but can you elaborate it a little bit? I can think of the following 1. When the application starts up, the servlet will be loaded up. 2. In its init(), I would have to create a process that is more like a daemon and waits for it to be requested or invoked. 3. From the GUI, actor uploads a file - this has to delegate the request to the servlet.Which then does the job Am i on the right track? Cheers -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p2543316.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous File Uploads
On Thu, Sep 16, 2010 at 11:20 PM, nivs shravann...@gmail.com wrote: Thanks mate, I will investigate more on this, but can you elaborate it a little bit? I can think of the following 1. When the application starts up, the servlet will be loaded up. 2. In its init(), I would have to create a process that is more like a daemon and waits for it to be requested or invoked. 3. From the GUI, actor uploads a file - this has to delegate the request to the servlet.Which then does the job Am i on the right track? Cheers You're over-complicating things. He meant just write a regular ol' servlet. Servlets already respond to HTTP requests - there's no daemon junk to worry about. Write a servlet, put it in your web.xml and make your upload form submit to it instead of Wicket. -- Jeremy Thomerson http://www.wickettraining.com
Re: Asynchronous File Uploads
Thanks for the time. Will give that a shot. Many thanks (will keep it simple) Niv -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Asynchronous-File-Uploads-tp2541855p2543362.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
tada, all done in trunk -igor On Wed, Aug 5, 2009 at 8:23 PM, Igor Vaynbergigor.vaynb...@gmail.com wrote: yes, the form action is rewritten to the behavior url. the behavior url processes the form the same way it does when an ajax request is used, but because we do not use an ajax request the form contains its multipart data. i tested it on a small example and it works like a charm save javascript problems. -igor On Wed, Aug 5, 2009 at 8:16 PM, Bas Goorenb...@iswd.nl wrote: Interesting, it looks like you simply POST the form to the AJAX url using an IFRAME. How does it work server-side? I would expect that it does not work, since the form action no longer contains it's usual value, and the new form action points directly to an interface (IBehaviorListener). But I guess that since you're using Wicket.Ajax.Call.submitForm, server-side knows a form is being submitted. I got uploadify working in a componentized form. Works like a charm for now. Bas - Original Message - From: Igor Vaynberg igor.vaynb...@gmail.com To: users@wicket.apache.org Sent: Thursday, August 06, 2009 4:32 AM Subject: Re: Handle file uploads in Behavior and respond using AjaxRequestTarget On Wed, Aug 5, 2009 at 4:10 PM, Bas Goorenb...@iswd.nl wrote: One of the working components I built using IFRAMEs is actually not that complex (400 LOC), i just wrote something that is about 30 lines of javascript that does this. only works in firefox so far. see WICKET-2420. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
Great! Will take a look at it soon. This is what I love about Wicket most: very active development (constant flow of improvement). Thanks Igor. Bas - Original Message - From: Igor Vaynberg igor.vaynb...@gmail.com To: users@wicket.apache.org Sent: Friday, August 07, 2009 7:28 PM Subject: Re: Handle file uploads in Behavior and respond using AjaxRequestTarget tada, all done in trunk -igor On Wed, Aug 5, 2009 at 8:23 PM, Igor Vaynbergigor.vaynb...@gmail.com wrote: yes, the form action is rewritten to the behavior url. the behavior url processes the form the same way it does when an ajax request is used, but because we do not use an ajax request the form contains its multipart data. i tested it on a small example and it works like a charm save javascript problems. -igor On Wed, Aug 5, 2009 at 8:16 PM, Bas Goorenb...@iswd.nl wrote: Interesting, it looks like you simply POST the form to the AJAX url using an IFRAME. How does it work server-side? I would expect that it does not work, since the form action no longer contains it's usual value, and the new form action points directly to an interface (IBehaviorListener). But I guess that since you're using Wicket.Ajax.Call.submitForm, server-side knows a form is being submitted. I got uploadify working in a componentized form. Works like a charm for now. Bas - Original Message - From: Igor Vaynberg igor.vaynb...@gmail.com To: users@wicket.apache.org Sent: Thursday, August 06, 2009 4:32 AM Subject: Re: Handle file uploads in Behavior and respond using AjaxRequestTarget On Wed, Aug 5, 2009 at 4:10 PM, Bas Goorenb...@iswd.nl wrote: One of the working components I built using IFRAMEs is actually not that complex (400 LOC), i just wrote something that is about 30 lines of javascript that does this. only works in firefox so far. see WICKET-2420. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Handle file uploads in Behavior and respond using AjaxRequestTarget
Hi all, Since I've seen many great answers on this list it's time to ask one of my questions ;-) The thing that strikes me as odd is how hard it is right now to handle file uploads and respond as if it were an AJAX request. I've built (based on various sources) a solution which uses a Panel which contains an IFRAME. After the upload, some AJAX javascript is rendered which calls an abstract function on the Panel so the implementor can replace or re-render components. This works great, although it took some extra effort since the frame and panel cannot easily share state (different pages/pagemaps/...?). The examples on the web store the uploaded file, and then pass it's filename through the AJAX request for access. I changed it to store uploads in temporary storage, identified by UUIDs. Now I have to say I really don't like this solution, since the IFRAME has to be sized to fit, or I have to use some not-so-nice javascript to automatically resize the IFRAME when an upload error occurs. Since I have had great fun with swfupload + PHP before, I decided to try and make an easier solution. I wondered if it would be possible to: 1) extend AbstractBehavior (works) 2) render the swf which will upload the file (works) 3) give the swf the URL of the behavior (works) 4) handle the upload(s) in onRequest() (does not work) 5) and then, just like AbstractDefaultAjaxBehavior.onRequest(), build an AjaxRequestTarget and handle the request (like it came in over xmlhttp) (works) 6) use javascript (Wicket.Ajax.Call.loadedCallback) to parse the (fake) AJAX response Sounds possible, right? It just seems overkill to run a POST request _and_ an AJAX request for every upload. It seems more complex than it should be. Actually, with the IFRAME it's three requests: IFRAME GET, IFRAME POST, AJAX GET What is not working right now is: - POST request not directed to the Behavior (I'm assuming there is special-case handling for POST somewhere?) Anyway, I'd like to known if any of the devs think the above is possible. If not, I'll stick to the solution I'm building right now (swfupload to a mounted URIRequestTargetUrlCodingStrategy + UUID in the URL, AJAX request with this UUID after successful upload). Ofcourse it's also possible something like this is possible but needs a completely different angle. Kind regards, Bas
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
well, its complex because you have to hack this in, browser's built in ajax support doesnt handle multipart requests yet. sounds like you are overcomplicating it by prerendering the iframe in the output. i think it would be easier to create the iframe on the fly via javascript, and give it style='display:none' so you wouldnt need to do any sizing. if upload fails the response in the iframe can write out some javascript to notify the main script that is managing the upload - which can then somehow show an error - maybe by doing an ajax request to wicket and rerendering the feedbackpanel. if upload is successful do the same thing, have iframe write out a bit of js that notifies the main script that the upload is done - which can then issue an ajax callback to wicket. makes sense? btw, there have to be libs that do all this for you on the js side of things. -igor On Wed, Aug 5, 2009 at 3:42 PM, Bas Goorenb...@iswd.nl wrote: Hi all, Since I've seen many great answers on this list it's time to ask one of my questions ;-) The thing that strikes me as odd is how hard it is right now to handle file uploads and respond as if it were an AJAX request. I've built (based on various sources) a solution which uses a Panel which contains an IFRAME. After the upload, some AJAX javascript is rendered which calls an abstract function on the Panel so the implementor can replace or re-render components. This works great, although it took some extra effort since the frame and panel cannot easily share state (different pages/pagemaps/...?). The examples on the web store the uploaded file, and then pass it's filename through the AJAX request for access. I changed it to store uploads in temporary storage, identified by UUIDs. Now I have to say I really don't like this solution, since the IFRAME has to be sized to fit, or I have to use some not-so-nice javascript to automatically resize the IFRAME when an upload error occurs. Since I have had great fun with swfupload + PHP before, I decided to try and make an easier solution. I wondered if it would be possible to: 1) extend AbstractBehavior (works) 2) render the swf which will upload the file (works) 3) give the swf the URL of the behavior (works) 4) handle the upload(s) in onRequest() (does not work) 5) and then, just like AbstractDefaultAjaxBehavior.onRequest(), build an AjaxRequestTarget and handle the request (like it came in over xmlhttp) (works) 6) use javascript (Wicket.Ajax.Call.loadedCallback) to parse the (fake) AJAX response Sounds possible, right? It just seems overkill to run a POST request _and_ an AJAX request for every upload. It seems more complex than it should be. Actually, with the IFRAME it's three requests: IFRAME GET, IFRAME POST, AJAX GET What is not working right now is: - POST request not directed to the Behavior (I'm assuming there is special-case handling for POST somewhere?) Anyway, I'd like to known if any of the devs think the above is possible. If not, I'll stick to the solution I'm building right now (swfupload to a mounted URIRequestTargetUrlCodingStrategy + UUID in the URL, AJAX request with this UUID after successful upload). Ofcourse it's also possible something like this is possible but needs a completely different angle. Kind regards, Bas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
Igor, First off: thanks for the amazingly fast response! Yes, it feels like I'm overcomplicating things. But then again: there does not seem to be an easy way. An upload + AJAX refresh always needs 2 requests, which means (for me) that I need to preserve the upload somewhere between those requests. Since this stuff is very easy on other platforms it's just too bad it's like this with Wicket. I mean, I really love Wicket, and most of my new projects are built on Wicket. But things like this one (http://www.uploadify.com/) I'm trying to wrap in a component/behavior right now is difficult to say the least. One of the working components I built using IFRAMEs is actually not that complex (400 LOC), and the problem is not so much in the rendering. It could also be the complexity is in the wrong place... Right now this is the flow: - handle upload, store temp file, pass uuid to client - client runs ajax request with the uuid - ajax handler in wicket processes the temp file, and re-renders components I could choose to process the files @ upload time, and the ajax request only re-renders elements. Though that does mean components which embed the upload component need to implement two methods (processUpload, processAjax) instead of one (processAjax(upload,ajax)). How would you go about building a component or behavior for Uploadify? Let's forget about the IFRAME solution for a second: flash-based uploading replaces the IFRAME. Regards, Bas - Original Message - From: Igor Vaynberg igor.vaynb...@gmail.com To: users@wicket.apache.org Sent: Thursday, August 06, 2009 12:51 AM Subject: Re: Handle file uploads in Behavior and respond using AjaxRequestTarget well, its complex because you have to hack this in, browser's built in ajax support doesnt handle multipart requests yet. sounds like you are overcomplicating it by prerendering the iframe in the output. i think it would be easier to create the iframe on the fly via javascript, and give it style='display:none' so you wouldnt need to do any sizing. if upload fails the response in the iframe can write out some javascript to notify the main script that is managing the upload - which can then somehow show an error - maybe by doing an ajax request to wicket and rerendering the feedbackpanel. if upload is successful do the same thing, have iframe write out a bit of js that notifies the main script that the upload is done - which can then issue an ajax callback to wicket. makes sense? btw, there have to be libs that do all this for you on the js side of things. -igor On Wed, Aug 5, 2009 at 3:42 PM, Bas Goorenb...@iswd.nl wrote: Hi all, Since I've seen many great answers on this list it's time to ask one of my questions ;-) The thing that strikes me as odd is how hard it is right now to handle file uploads and respond as if it were an AJAX request. I've built (based on various sources) a solution which uses a Panel which contains an IFRAME. After the upload, some AJAX javascript is rendered which calls an abstract function on the Panel so the implementor can replace or re-render components. This works great, although it took some extra effort since the frame and panel cannot easily share state (different pages/pagemaps/...?). The examples on the web store the uploaded file, and then pass it's filename through the AJAX request for access. I changed it to store uploads in temporary storage, identified by UUIDs. Now I have to say I really don't like this solution, since the IFRAME has to be sized to fit, or I have to use some not-so-nice javascript to automatically resize the IFRAME when an upload error occurs. Since I have had great fun with swfupload + PHP before, I decided to try and make an easier solution. I wondered if it would be possible to: 1) extend AbstractBehavior (works) 2) render the swf which will upload the file (works) 3) give the swf the URL of the behavior (works) 4) handle the upload(s) in onRequest() (does not work) 5) and then, just like AbstractDefaultAjaxBehavior.onRequest(), build an AjaxRequestTarget and handle the request (like it came in over xmlhttp) (works) 6) use javascript (Wicket.Ajax.Call.loadedCallback) to parse the (fake) AJAX response Sounds possible, right? It just seems overkill to run a POST request _and_ an AJAX request for every upload. It seems more complex than it should be. Actually, with the IFRAME it's three requests: IFRAME GET, IFRAME POST, AJAX GET What is not working right now is: - POST request not directed to the Behavior (I'm assuming there is special-case handling for POST somewhere?) Anyway, I'd like to known if any of the devs think the above is possible. If not, I'll stick to the solution I'm building right now (swfupload to a mounted URIRequestTargetUrlCodingStrategy + UUID in the URL, AJAX request with this UUID after successful upload). Ofcourse it's also possible something like this is possible but needs a completely different
RE: Handle file uploads in Behavior and respond using AjaxRequestTarget
i've done this with php and ajax. the form posts, using target, to a hidden iframe. the response rendered back to the iframe is javascript. The only thing the iframe renders is javascript. In your page you have javascript functions for the onSuccess() or onFailure() that are specific to that page. Or since you are rendering javascript you can render any javascript you like. This is very ajax like in that you are simply rendering callbacks. I suppose you could take it one step further and post the names of your callback functions. I'm not sure if this is any cleaner or any help at all, but I do hope it helps. Russ From: igor.vaynb...@gmail.com Date: Wed, 5 Aug 2009 15:51:44 -0700 Subject: Re: Handle file uploads in Behavior and respond using AjaxRequestTarget To: users@wicket.apache.org well, its complex because you have to hack this in, browser's built in ajax support doesnt handle multipart requests yet. sounds like you are overcomplicating it by prerendering the iframe in the output. i think it would be easier to create the iframe on the fly via javascript, and give it style='display:none' so you wouldnt need to do any sizing. if upload fails the response in the iframe can write out some javascript to notify the main script that is managing the upload - which can then somehow show an error - maybe by doing an ajax request to wicket and rerendering the feedbackpanel. if upload is successful do the same thing, have iframe write out a bit of js that notifies the main script that the upload is done - which can then issue an ajax callback to wicket. makes sense? btw, there have to be libs that do all this for you on the js side of things. -igor On Wed, Aug 5, 2009 at 3:42 PM, Bas Gooren wrote: Hi all, Since I've seen many great answers on this list it's time to ask one of my questions ;-) The thing that strikes me as odd is how hard it is right now to handle file uploads and respond as if it were an AJAX request. I've built (based on various sources) a solution which uses a Panel which contains an IFRAME. After the upload, some AJAX javascript is rendered which calls an abstract function on the Panel so the implementor can replace or re-render components. This works great, although it took some extra effort since the frame and panel cannot easily share state (different pages/pagemaps/...?). The examples on the web store the uploaded file, and then pass it's filename through the AJAX request for access. I changed it to store uploads in temporary storage, identified by UUIDs. Now I have to say I really don't like this solution, since the IFRAME has to be sized to fit, or I have to use some not-so-nice javascript to automatically resize the IFRAME when an upload error occurs. Since I have had great fun with swfupload + PHP before, I decided to try and make an easier solution. I wondered if it would be possible to: 1) extend AbstractBehavior (works) 2) render the swf which will upload the file (works) 3) give the swf the URL of the behavior (works) 4) handle the upload(s) in onRequest() (does not work) 5) and then, just like AbstractDefaultAjaxBehavior.onRequest(), build an AjaxRequestTarget and handle the request (like it came in over xmlhttp) (works) 6) use javascript (Wicket.Ajax.Call.loadedCallback) to parse the (fake) AJAX response Sounds possible, right? It just seems overkill to run a POST request _and_ an AJAX request for every upload. It seems more complex than it should be. Actually, with the IFRAME it's three requests: IFRAME GET, IFRAME POST, AJAX GET What is not working right now is: - POST request not directed to the Behavior (I'm assuming there is special-case handling for POST somewhere?) Anyway, I'd like to known if any of the devs think the above is possible. If not, I'll stick to the solution I'm building right now (swfupload to a mounted URIRequestTargetUrlCodingStrategy + UUID in the URL, AJAX request with this UUID after successful upload). Ofcourse it's also possible something like this is possible but needs a completely different angle. Kind regards, Bas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org _ Get free photo software from Windows Live http://www.windowslive.com/online/photos?ocid=PID23393::T:WLMTAGL:ON:WL:en-US:SI_PH_software:082009 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
On Wed, Aug 5, 2009 at 4:10 PM, Bas Goorenb...@iswd.nl wrote: Igor, First off: thanks for the amazingly fast response! Yes, it feels like I'm overcomplicating things. But then again: there does not seem to be an easy way. An upload + AJAX refresh always needs 2 requests, which means (for me) that I need to preserve the upload somewhere between those requests. Since this stuff is very easy on other platforms it's just too bad it's like this with Wicket. this is the price you pay for abstraction. It is easy on other platforms because this is something that is accomplished by working with low-level http artifacts - http requests. something like php or jsp or servlets have no abstraction, there it is much easier to do this then to write a complex UI. in wicket, because of the abstraction, this is reversed - easy to write UI, more difficult to wire http requests together like this. its a good thing that 99% of the time is spent writing UIs :) I mean, I really love Wicket, and most of my new projects are built on Wicket. But things like this one (http://www.uploadify.com/) I'm trying to wrap in a component/behavior right now is difficult to say the least. didnt really look into it that much, when i went to the demo tab it crashed my firefox :| One of the working components I built using IFRAMEs is actually not that complex (400 LOC), and the problem is not so much in the rendering. It could also be the complexity is in the wrong place... Right now this is the flow: - handle upload, store temp file, pass uuid to client - client runs ajax request with the uuid - ajax handler in wicket processes the temp file, and re-renders components I could choose to process the files @ upload time, and the ajax request only re-renders elements. Though that does mean components which embed the upload component need to implement two methods (processUpload, processAjax) instead of one (processAjax(upload,ajax)). How would you go about building a component or behavior for Uploadify? Let's forget about the IFRAME solution for a second: flash-based uploading replaces the IFRAME. Regards, Bas - Original Message - From: Igor Vaynberg igor.vaynb...@gmail.com To: users@wicket.apache.org Sent: Thursday, August 06, 2009 12:51 AM Subject: Re: Handle file uploads in Behavior and respond using AjaxRequestTarget well, its complex because you have to hack this in, browser's built in ajax support doesnt handle multipart requests yet. sounds like you are overcomplicating it by prerendering the iframe in the output. i think it would be easier to create the iframe on the fly via javascript, and give it style='display:none' so you wouldnt need to do any sizing. if upload fails the response in the iframe can write out some javascript to notify the main script that is managing the upload - which can then somehow show an error - maybe by doing an ajax request to wicket and rerendering the feedbackpanel. if upload is successful do the same thing, have iframe write out a bit of js that notifies the main script that the upload is done - which can then issue an ajax callback to wicket. makes sense? btw, there have to be libs that do all this for you on the js side of things. -igor On Wed, Aug 5, 2009 at 3:42 PM, Bas Goorenb...@iswd.nl wrote: Hi all, Since I've seen many great answers on this list it's time to ask one of my questions ;-) The thing that strikes me as odd is how hard it is right now to handle file uploads and respond as if it were an AJAX request. I've built (based on various sources) a solution which uses a Panel which contains an IFRAME. After the upload, some AJAX javascript is rendered which calls an abstract function on the Panel so the implementor can replace or re-render components. This works great, although it took some extra effort since the frame and panel cannot easily share state (different pages/pagemaps/...?). The examples on the web store the uploaded file, and then pass it's filename through the AJAX request for access. I changed it to store uploads in temporary storage, identified by UUIDs. Now I have to say I really don't like this solution, since the IFRAME has to be sized to fit, or I have to use some not-so-nice javascript to automatically resize the IFRAME when an upload error occurs. Since I have had great fun with swfupload + PHP before, I decided to try and make an easier solution. I wondered if it would be possible to: 1) extend AbstractBehavior (works) 2) render the swf which will upload the file (works) 3) give the swf the URL of the behavior (works) 4) handle the upload(s) in onRequest() (does not work) 5) and then, just like AbstractDefaultAjaxBehavior.onRequest(), build an AjaxRequestTarget and handle the request (like it came in over xmlhttp) (works) 6) use javascript (Wicket.Ajax.Call.loadedCallback) to parse the (fake) AJAX response Sounds possible, right? It just seems overkill to run a POST
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
On Wed, Aug 5, 2009 at 4:10 PM, Bas Goorenb...@iswd.nl wrote: One of the working components I built using IFRAMEs is actually not that complex (400 LOC), i just wrote something that is about 30 lines of javascript that does this. only works in firefox so far. see WICKET-2420. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
Interesting, it looks like you simply POST the form to the AJAX url using an IFRAME. How does it work server-side? I would expect that it does not work, since the form action no longer contains it's usual value, and the new form action points directly to an interface (IBehaviorListener). But I guess that since you're using Wicket.Ajax.Call.submitForm, server-side knows a form is being submitted. I got uploadify working in a componentized form. Works like a charm for now. Bas - Original Message - From: Igor Vaynberg igor.vaynb...@gmail.com To: users@wicket.apache.org Sent: Thursday, August 06, 2009 4:32 AM Subject: Re: Handle file uploads in Behavior and respond using AjaxRequestTarget On Wed, Aug 5, 2009 at 4:10 PM, Bas Goorenb...@iswd.nl wrote: One of the working components I built using IFRAMEs is actually not that complex (400 LOC), i just wrote something that is about 30 lines of javascript that does this. only works in firefox so far. see WICKET-2420. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
yes, the form action is rewritten to the behavior url. the behavior url processes the form the same way it does when an ajax request is used, but because we do not use an ajax request the form contains its multipart data. i tested it on a small example and it works like a charm save javascript problems. -igor On Wed, Aug 5, 2009 at 8:16 PM, Bas Goorenb...@iswd.nl wrote: Interesting, it looks like you simply POST the form to the AJAX url using an IFRAME. How does it work server-side? I would expect that it does not work, since the form action no longer contains it's usual value, and the new form action points directly to an interface (IBehaviorListener). But I guess that since you're using Wicket.Ajax.Call.submitForm, server-side knows a form is being submitted. I got uploadify working in a componentized form. Works like a charm for now. Bas - Original Message - From: Igor Vaynberg igor.vaynb...@gmail.com To: users@wicket.apache.org Sent: Thursday, August 06, 2009 4:32 AM Subject: Re: Handle file uploads in Behavior and respond using AjaxRequestTarget On Wed, Aug 5, 2009 at 4:10 PM, Bas Goorenb...@iswd.nl wrote: One of the working components I built using IFRAMEs is actually not that complex (400 LOC), i just wrote something that is about 30 lines of javascript that does this. only works in firefox so far. see WICKET-2420. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
bug in firefox in file uploads?
i get the stack trace below when uploading files in 1.4-rc1 it only happens in firefox. safari seems to be fine. is this a known problem or should i file a bug? thanks, jon WARN - Form - Upload failed: Processing of multipart/form-data request failed. null org.apache.wicket.util.upload.FileUploadException: Processing of multipart/form-data request failed. null at org.apache.wicket.util.upload.FileUploadBase.parseRequest(FileUploadBase.java:360) at org.apache.wicket.util.upload.ServletFileUpload.parseRequest(ServletFileUpload.java:115) at org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:133) at org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWebRequest(ServletWebRequest.java:476) at org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1577) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:839) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:182) at org.apache.wicket.request.target.component.listener.ListenerInterfaceRequestTarget.processEvents(ListenerInterfaceRequestTarget.java:73) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:91) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1191) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1270) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1371) at org.apache.wicket.RequestCycle.request(RequestCycle.java:498) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:455) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:288) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:295) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:841) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:639) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:361) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) Caused by: org.mortbay.jetty.EofException at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:300) at org.mortbay.jetty.HttpParser$Input.blockForContent(HttpParser.java:944) at org.mortbay.jetty.HttpParser$Input.read(HttpParser.java:905) at org.apache.wicket.util.upload.MultipartFormInputStream.readBodyData(MultipartFormInputStream.java:553) at org.apache.wicket.util.upload.FileUploadBase.parseRequest(FileUploadBase.java:337) ... 33 more -- View this message in context: http://www.nabble.com/bug-in-firefox-in-file-uploads--tp21186555p21186555.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
file uploads
Hi I am using the file upload component in wicket and I like to set the folder path to save uploaded files. Folder folder = new Folder(Uploads); folder.mkdirs(); File newFile = new File(folder,fileUpload.getClientFileName()); This code snippet saves the files in a folder called 'uploads' but is created inside the resin folder. How do I specify a relative path so that a folder is created inside my project directory thanks tbt -- View this message in context: http://www.nabble.com/file-uploads-tp16249006p16249006.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: file uploads
On Mon, Mar 24, 2008 at 7:31 AM, tbt [EMAIL PROTECTED] wrote: Hi I am using the file upload component in wicket and I like to set the folder path to save uploaded files. Folder folder = new Folder(Uploads); folder.mkdirs(); File newFile = new File(folder,fileUpload.getClientFileName()); By default, your files are saved in a temporary directory. You can just copy your uploaded files to whatever directory you want. Check out the source code to the file upload example for inspiration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
