Issue with FileUpload.writeToTempFile()
Hi all, I seem to be having a small portability glitch with FileUpload.writeToTempFile(). Looking at the source code it seems to be using item.getFieldName(), which on my page translates to filefields:1:upload. Windows doesn't really like colons, which gives me the following stacktrace: ...snip until root cause... Caused by: java.io.IOException: The parameter is incorrect at java.io.WinNTFileSystem.createFileExclusively(Native Method) at java.io.File.checkAndCreate(File.java:1704) at java.io.File.createTempFile(File.java:1793) at java.io.File.createTempFile(File.java:1830) at org.apache.wicket.markup.html.form.upload.FileUpload.writeToTempFile(FileUpload.java:189) ...snip... On mac linux this works just fine. I know that more elegant way would be using the InputStream, but having a file is much more useful for reading image dimensions and file length etc. than juggling things in memory. Sincerely, -- Lauri Piispanen Senior Product Architect Conmio Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
igor.vaynberg wrote: so now you have to do new DataViewVoid,Foo which is very noisy not to mention you have to remember which one is for the model and which one is for the dataprovider. -igor I don't know if this is too late, and haven't played with DataViews for a while but why couldn't you do something to this extent: public abstract class DataViewBaseT extends AbstractPageableViewT { public K DataViewBase(String id, IDataProviderK dataProvider) { ...snip... } ...snip... private static final class ModelIteratorK implements IteratorIModelK { ...snip... } } as DataView's children aren't actually supposed to use T - that's what the DataView's model would use but chooses to ignore it (and we can't know if some subclass would actually _want_ to use the model for something). Just drop the T parameter and avoid the noise if required. -- View this message in context: http://www.nabble.com/generics-tp18083910p19065291.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]
WicketTester and continueToOriginalDestination
Hi all, I'm having problems trying to test interception pages with WicketTester in Wicket 1.3. For some reason my application homepage is used instead of the one that threw the RestartResponseAtInterceptPageException. I have the same code running fine in the servlet environment, so I think the issue is most likely with WicketTester. Either that, or it's actually due to my erroneous use of it. Here's my test case: public void testContinueToOriginalDestination() throws Exception { tester.startPage(TargetPage.class); tester.assertRenderedPage(InterceptPage.class); tester.submitForm(form); tester.assertRenderedPage(TargetPage.class); // This line fails, as the rendered page is actually the application home page. } TargetPage is set to throw a RestartResponseAtInterceptException at first request: private boolean firstTime = true; public TargetPage() { if (firstTime) { firstTime = false; throw new RestartResponseAtInterceptPageException(InterceptPage.class); } } My intercept page simply has a form with a continueToOriginalDestination() when submit: public InterceptPage() { add(new Form(form) { @Override protected void onSubmit() { continueToOriginalDestination(); } }); } Can anyone help me with this, or have I encountered some bug with the tester? I have test cases that reproduce the issue. Sincerely, -- Lauri Piispanen +358 45 630 2546 Senior Product Architect Conmio Ltd http://www.conmio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WicketTester and continueToOriginalDestination
Hi Maurice, Great, that solves the problem and my bar is green again! :) I can still post the issue to JIRA along with my test cases if you want me to, just so it doesn't get buried. Sincerely, Lauri Piispanen +358 45 630 2546 Senior Product Architect Conmio Ltd http://www.conmio.com Maurice Marrink wrote: I believe there is indeed a problem with continueTo... I have talked with Johan about it a long time ago, i don't recall what the problem was but ever since i am using the following work around to test continueTo behavior. // continueToOriginaldestination does not work if there is no url available, so we need to fake one here(testing only hack) mock.setupRequestAndResponse(); WebRequestCycle cycle = mock.createRequestCycle(); String url1 = cycle.urlFor(new BookmarkablePageRequestTarget(YOUR_PAGE_HERE.class, null)).toString(); mock.getServletRequest().setURL(/GeneralTest$1/GeneralTest$1/ + url1); mock.processRequestCycle(); mock is the WicketTester. GeneralTest$1 from the url is the classname of your application without the package. (in my case it is an anonymous inner class hence the $1) Note that this classname appears twice in the url. Maurice On Jan 18, 2008 12:24 PM, Lauri Piispanen - Conmio Ltd [EMAIL PROTECTED] wrote: Hi all, I'm having problems trying to test interception pages with WicketTester in Wicket 1.3. For some reason my application homepage is used instead of the one that threw the RestartResponseAtInterceptPageException. I have the same code running fine in the servlet environment, so I think the issue is most likely with WicketTester. Either that, or it's actually due to my erroneous use of it. Here's my test case: public void testContinueToOriginalDestination() throws Exception { tester.startPage(TargetPage.class); tester.assertRenderedPage(InterceptPage.class); tester.submitForm(form); tester.assertRenderedPage(TargetPage.class); // This line fails, as the rendered page is actually the application home page. } TargetPage is set to throw a RestartResponseAtInterceptException at first request: private boolean firstTime = true; public TargetPage() { if (firstTime) { firstTime = false; throw new RestartResponseAtInterceptPageException(InterceptPage.class); } } My intercept page simply has a form with a continueToOriginalDestination() when submit: public InterceptPage() { add(new Form(form) { @Override protected void onSubmit() { continueToOriginalDestination(); } }); } Can anyone help me with this, or have I encountered some bug with the tester? I have test cases that reproduce the issue. Sincerely, -- Lauri Piispanen +358 45 630 2546 Senior Product Architect Conmio Ltd http://www.conmio.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]