svn commit: r667341 - /wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
Author: ivaynberg
Date: Thu Jun 12 22:03:49 2008
New Revision: 667341
URL: http://svn.apache.org/viewvc?rev=667341&view=rev
Log:
remove warning
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java?rev=667341&r1=667340&r2=667341&view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
Thu Jun 12 22:03:49 2008
@@ -25,9 +25,9 @@
import java.util.HashSet;
import java.util.Set;
-import org.apache.wicket.Component.IVisitor;
import org.apache.wicket.Page;
import org.apache.wicket.WicketTestCase;
+import org.apache.wicket.Component.IVisitor;
import org.apache.wicket.util.file.File;
import org.apache.wicket.util.tester.FormTester;
import org.apache.wicket.util.tester.ITestPageSource;
@@ -79,7 +79,7 @@
// know the path of (e.g. the big DTD this test used
previously). This enables
// us to run the test out of a JAR file if need be, and
also with an unknown
// running directory (e.g. when run from wicket-parent).
-tmp = writeTestFile(1000);
+ tmp = writeTestFile(1000);
// Let's upload the dtd file. It's large enough to
avoid being in memory.
FormTester formtester = tester.newFormTester("form");
@@ -123,94 +123,98 @@
}
}
-public void testFileUploadCanBeValidated() throws IOException
-{
-final Set validatedComponents = new
HashSet();
-
-final File tmpFile = writeTestFile(1);
-tmpFile.deleteOnExit();
-
-final IValidator testValidator = new IValidator()
-{
-public void validate(IValidatable validatable)
-{
-validatedComponents.add(validatable);
-assertEquals(FileUpload.class,
validatable.getValue().getClass());
-FileUpload upload = (FileUpload) validatable.getValue();
-assertEquals(tmpFile.getName(), upload.getClientFileName());
-assertEquals(new String(read(tmpFile)), new
String(upload.getBytes()));
-}
-};
-final MockPageWithFormAndUploadField page = new
MockPageWithFormAndUploadField();
-page.getForm().visitChildren(FileUploadField.class, new
IVisitor()
-{
-public Object component(FileUploadField uploadField)
-{
-uploadField.add(testValidator);
-return STOP_TRAVERSAL;
-}
-});
-
-tester.startPage(new ITestPageSource()
-{
-private static final long serialVersionUID = 1L;
-
-public Page getTestPage()
-{
-return page;
-}
-});
-
-FormTester formtester = tester.newFormTester("form");
-formtester.setFile("upload", tmpFile, "text/plain");
-formtester.submit();
-assertEquals(validatedComponents.size(), 1);
-}
-
-private File writeTestFile(int numberOfowsToCreate)
-throws IOException
-{
-File tmp = new File(java.io.File.createTempFile(getClass().getName(),
".txt"));
-OutputStream os = new BufferedOutputStream(new FileOutputStream(tmp));
-for (int i = 0; i < numberOfowsToCreate; i++)
-{
-os.write("test test test test test\n".getBytes());
-}
-os.close();
-return tmp;
-}
-
-private byte[] read(File file)
-{
-try
-{
-return readFile(file);
-} catch (IOException e)
-{
-throw new RuntimeException(e);
-}
-}
-
-private byte[] readFile(File file) throws IOException
-{
-InputStream stream = null;
-byte[] bytes = new byte[0];
-try
-{
-stream = new FileInputStream(file);
-int length = (int) file.length();
-bytes = new byte[length];
-int offset = 0;
-int bytesRead;
-
-while (offset < bytes.length && (bytesRead = stream.read(bytes,
offset, bytes.length - offset)) >= 0)
-{
-offset += bytesRead;
-}
-} finally
-{
-stream.close();
-}
-return bytes;
-}
+ public void testFileUploadCanBeValidated() throws IOException
+ {
+ final Set validatedComponents = new
HashSet();
+
+ final File tmpFile = writeTestF
svn commit: r667340 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
Author: ivaynberg
Date: Thu Jun 12 22:03:37 2008
New Revision: 667340
URL: http://svn.apache.org/viewvc?rev=667340&view=rev
Log:
tweak
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java?rev=667340&r1=667339&r2=667340&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
Thu Jun 12 22:03:37 2008
@@ -112,7 +112,7 @@
// Only update the model if one was passed in
if (hasExplicitModel)
{
- setModelObject(getFileUpload());
+ setModelObject(getConvertedInput());
}
}
@@ -131,18 +131,18 @@
return null;
}
-@Override
-protected FileUpload convertValue(String[] value) throws
ConversionException
-{
-final String[] filenames = getInputAsArray();
-if (filenames == null)
-{
-return null;
-}
-return getFileUpload();
-}
+ @Override
+ protected FileUpload convertValue(String[] value) throws
ConversionException
+ {
+ final String[] filenames = getInputAsArray();
+ if (filenames == null)
+ {
+ return null;
+ }
+ return getFileUpload();
+ }
-/**
+ /**
* @see org.apache.wicket.markup.html.form.FormComponent#isMultiPart()
*/
@Override
[CONF] Apache Wicket: Wicket Employers (page edited)
Page Edited : WICKET : Wicket Employers Wicket Employers has been edited by Sean Kilcoin (Jun 12, 2008). Change summary: added Cataphora (View changes) Content: List of employers who are interested in developers with Wicket experience. Wicket Employers BlueXML BlueXML is hiring for a R&D project which mixes models, specifications and components to create a new paradigm to develop web applications in a more "sustainable" way. People with strong java and web skills are more than welcome. Cataphora is a leading e-discovery and legal review software company located in Silicon Valley and is using Wicket for its web applications. Its careers page can be found here. Curalia provides web applications and system integrations based on Wicket, Spring, Hibernate, ServiceMix and internal solutions. Func. Internet Integration is a Dutch company providing web applications and system integrations on a Wicket - Hibernate - XFire - Spring stack, mainly for the educational market. Hippo ECMS Hippo, supplier of Enterprise Content Management and Portal software based on Wicket, Lucene, Jackrabbit and Jetspeed. Inertia Beverage Group is a Software-as-Service platform for the wine industry. (Wicket-based platform is currently under development.) Koodaripalvelut.com Finland a Finnish ICT consulting company. MeetMoi.com Location based real time dating on mobile phones MX Telecom is a major player in the international mobile telecoms industry, and uses Wicket for various internal and client-facing systems. Reaktor Innovations is a Finnish consulting company. Syncron Tech is a Finnish industrial consulting company. Teachscape provides professional learning tools through a platform that uses Wicket. Topicus Zorg is a Dutch company (located in Deventer) that is specialised in the realisation of innovative web-based applications in the care sector. Topicus Onderwijs is a Dutch company (located in Deventer) that is specialised in the realisation of innovative web-based applications in the education sector: amongst others we have created Parnassys for primary schools, and Vocus for high schools. Some slides for Vocus can be found here. Vegas.com is a travel/entertainment retailer (hotel reservations, tickets to shows, etc), focused on the Las Vegas market. WorldEvolved Services, a young startup based in New York City, is hiring talented developers to design and implement a web framework based on Wicket. The company is in stealth mode, and hence further information will be given after an initial screening. To apply please contact [EMAIL PROTECTED] Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[jira] Commented: (WICKET-1698) IE7 memory leak when components are updated via AJAX
[ https://issues.apache.org/jira/browse/WICKET-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604698#action_12604698 ] Matej Knopp commented on WICKET-1698: - Hi, I looked at drip and the examples. First of all, IMHO drip is too simplistic tool to reliably detect memory leaks in javascript. It works on javascript level and can't even intercept replaceOuterHTML. Also it shows elements that Wicket doesn't keep any references to. >From my experience the only relative reliable way to detect memory leak in IE >is to use tasks manager and play with the application. Beware though, that the >GC doesn't run all the time and that it an take a while to garbage collect >unreferenced elements. Also some elements (particularly with YUI) are not GCed >until the page is reloaded (attached events). I tested multiple wicket examples this way and wasn't able to spot any memory leak. If you know an example where repetitive action (clicking a link) that refreshes some component leads to radical increase of IE memory consumption (I've had situation when IE grew over 10MB every request) please let me know. > IE7 memory leak when components are updated via AJAX > > > Key: WICKET-1698 > URL: https://issues.apache.org/jira/browse/WICKET-1698 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.3, 1.4-M2 > Environment: WinXP SP3, IE7 >Reporter: Niels Boeger >Assignee: Matej Knopp > > I noticed a large increase in IE7s memory consumption when a wicket component > is updated via AJAX. > In my case, I used wicket to update the markup of a html table. The table > acts as datasource for a yui datatable. The markup update is triggered by a > "wicketAjaxGet" request on the client, and Wicket updates the markup of the > table. > Drip (http://www.outofhanwell.com/ieleak/) shows that old markup is not > garbage collected by IE7. > YUI does not seem to be the culprit, the problem occured even when I removed > all YUI code. > Using Drip on the AutoComplete example > (http://www.wicketstuff.org/wicket13/ajax/autocomplete) shows the same > behavior. > I tested this in my application with both Wicket 1.3.3 and Wicket 1.4-M2. > FF2 (Mac OS X & WinXP), FF3RC2 (WinXP) and Safari 3.1 (Mac OS X) run fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-715) rename classes and methods from *JavaScript* to *Javascript*
[ https://issues.apache.org/jira/browse/WICKET-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604697#action_12604697 ] Craig McIlwee commented on WICKET-715: -- If you have to pick between the 2, JavaScript (capital S) is actually the correct spelling. > rename classes and methods from *JavaScript* to *Javascript* > > > Key: WICKET-715 > URL: https://issues.apache.org/jira/browse/WICKET-715 > Project: Wicket > Issue Type: Task >Affects Versions: 1.4-M1 >Reporter: Gerolf Seitz >Priority: Minor > Fix For: 1.4-M3 > > > some classes are spelled *JavaScript* and some *Javascript*. same with > methods too. > for the sake of consistency the term "Javascript" should be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-767) Generify IModel
[
https://issues.apache.org/jira/browse/WICKET-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-767.
--
Resolution: Fixed
Fix Version/s: (was: 1.4-M3)
1.4-M1
Assignee: Igor Vaynberg
> Generify IModel
> ---
>
> Key: WICKET-767
> URL: https://issues.apache.org/jira/browse/WICKET-767
> Project: Wicket
> Issue Type: Wish
>Reporter: Willis Boyce
>Assignee: Igor Vaynberg
> Fix For: 1.4-M1
>
>
> I find myself writing custom IModel implementations that depend on the
> underlying object being some specific type. It would be nice if I could get
> some type safety using generics, e.g.
> class MyCustomModel implements IModel
> {
> MyCustomObject getObject(Component component) { ... }
> ...
> }
> I imagine that this has already been suggested, but I couldn't find a JIRA
> issue about it in the road map.
> I don't think that the core Wicket code would change too much, except in
> cases where the code actually cared what was in the model. Elsewhere it can
> just use IModel.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1699) NPE in RequestLogger
[ https://issues.apache.org/jira/browse/WICKET-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-1699. --- Resolution: Fixed Assignee: Igor Vaynberg > NPE in RequestLogger > > > Key: WICKET-1699 > URL: https://issues.apache.org/jira/browse/WICKET-1699 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-M2 >Reporter: Craig McIlwee >Assignee: Igor Vaynberg > Fix For: 1.4-M3 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > RequestLogger throws an NPE at line 200 because the field 'active' is never > assigned a value when the class is instantiated. In older versions (I am > migrating from 1.3.3) this field was just a native int so the value would > default to 0, but sometime between 1.3.3 and 1.4m2 it has changed to an > AtomicInteger and never assigned a value via new AtomicInteger() or new > AtomicInteger(someInt). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1312) Generic inter-component event mechanism
[ https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604683#action_12604683 ] Timo Rantalaiho commented on WICKET-1312: - Peter, thanks for the interesting idea, but surfing in the stack trace is really too much magic at least for my taste! Also checking the method from which the event got fired from (if I got that right) might complicate unit testing. > Generic inter-component event mechanism > --- > > Key: WICKET-1312 > URL: https://issues.apache.org/jira/browse/WICKET-1312 > Project: Wicket > Issue Type: New Feature > Components: wicket-extensions >Affects Versions: 1.3.0-final >Reporter: Timo Rantalaiho > Fix For: 1.5-M1 > > Attachments: event-handler-with-testcase.zip, > Generic_EventBroadcaster.patch, > Generic_EventBroadcaster_glued_in_Component.patch > > > The attached patch provides a generic mechanism for transmitting > inter-component events within a page. This has grown primarily from the need > to repaint all relevant ajax components after an event, but can be used also > in non-ajax environments such as after normal form submits. > The basic idea is to fire an IVisitor on the page of the component sending an > event, giving as an argument an event-specific listener interface that must > be implemented by the components willing to receive the events. They can then > do whatever they need such as add themselves to the AjaxRequestTarget that > can be supplied in the event. > Sometimes the basic Wicket mechanisms such as sharing a model are not enough; > particularly repainting all relevant components in Ajax events gets tedious > if the components are far away from each other in a complex DOM tree. > The benefits of this approach are > - loose coupling between the sending and receiving end > - however, because of strong static typing it's easy enough to find with an > IDE from where the events are broadcasted and where they are received > - good testability (EventBroadcaster can be mocked on the sending end, and > event handlers tested directly on the receiving end, possibly with mock > events) > - no need the keep references to Component instances or their paths (which > could have been problematic on repeaters) > (This is not a real observer or listener pattern implementation because the > components cannot register and unregister themselves dynamically, but > "registering" is handled statically on a class basis by implementing the > relevant event receiver interface.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1312) Generic inter-component event mechanism
[ https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timo Rantalaiho updated WICKET-1312: Fix Version/s: (was: 1.4-M3) 1.5-M1 Nope, 1.5 is the current plan, if 1.4 goes according to the current plan :) > Generic inter-component event mechanism > --- > > Key: WICKET-1312 > URL: https://issues.apache.org/jira/browse/WICKET-1312 > Project: Wicket > Issue Type: New Feature > Components: wicket-extensions >Affects Versions: 1.3.0-final >Reporter: Timo Rantalaiho > Fix For: 1.5-M1 > > Attachments: event-handler-with-testcase.zip, > Generic_EventBroadcaster.patch, > Generic_EventBroadcaster_glued_in_Component.patch > > > The attached patch provides a generic mechanism for transmitting > inter-component events within a page. This has grown primarily from the need > to repaint all relevant ajax components after an event, but can be used also > in non-ajax environments such as after normal form submits. > The basic idea is to fire an IVisitor on the page of the component sending an > event, giving as an argument an event-specific listener interface that must > be implemented by the components willing to receive the events. They can then > do whatever they need such as add themselves to the AjaxRequestTarget that > can be supplied in the event. > Sometimes the basic Wicket mechanisms such as sharing a model are not enough; > particularly repainting all relevant components in Ajax events gets tedious > if the components are far away from each other in a complex DOM tree. > The benefits of this approach are > - loose coupling between the sending and receiving end > - however, because of strong static typing it's easy enough to find with an > IDE from where the events are broadcasted and where they are received > - good testability (EventBroadcaster can be mocked on the sending end, and > event handlers tested directly on the receiving end, possibly with mock > events) > - no need the keep references to Component instances or their paths (which > could have been problematic on repeaters) > (This is not a real observer or listener pattern implementation because the > components cannot register and unregister themselves dynamically, but > "registering" is handled statically on a class basis by implementing the > relevant event receiver interface.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-713) AbstractAjaxBehavior can not be reused.
[
https://issues.apache.org/jira/browse/WICKET-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604679#action_12604679
]
Timo Rantalaiho commented on WICKET-713:
Martin, is there a practical need to reuse the same Behavior instance? Do you
have (or did you have :)) a concrete example?
Others, what do you think?
> AbstractAjaxBehavior can not be reused.
> ---
>
> Key: WICKET-713
> URL: https://issues.apache.org/jira/browse/WICKET-713
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Reporter: Martin Funk
> Fix For: 1.4-M3
>
>
> AbstractAjaxBehavior is receiving a Component upon bind, this is keept even
> when the Behavior is removed from the Component
> so if the Behavior is added again it throws a
> IllegalStateException("this kind of handler
> cannot be attached to "
> + "multiple components; it is already
> attached to component " + this.component
> + ", but component " + hostComponent +
> " wants to be attached too");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1696) CaptchaImageResource - should take an IModel instead of String for captcha-text
[ https://issues.apache.org/jira/browse/WICKET-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604677#action_12604677 ] Stefan Simik commented on WICKET-1696: -- Sure ;) thanx I changed the fix version. > CaptchaImageResource - should take an IModel instead of String for > captcha-text > --- > > Key: WICKET-1696 > URL: https://issues.apache.org/jira/browse/WICKET-1696 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Reporter: Stefan Simik > Fix For: 1.4-M3 > > Original Estimate: 0.33h > Remaining Estimate: 0.33h > > CaptchaImageResource - should take an IModel instead of String for > captcha-text -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-767) Generify IModel
[
https://issues.apache.org/jira/browse/WICKET-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604676#action_12604676
]
James Carman commented on WICKET-767:
-
Isn't this already done? I'm pretty sure the consensus is that we at least
need to generify IModel and it's already done. So, are we good to
resolve/close this?
> Generify IModel
> ---
>
> Key: WICKET-767
> URL: https://issues.apache.org/jira/browse/WICKET-767
> Project: Wicket
> Issue Type: Wish
>Reporter: Willis Boyce
> Fix For: 1.4-M3
>
>
> I find myself writing custom IModel implementations that depend on the
> underlying object being some specific type. It would be nice if I could get
> some type safety using generics, e.g.
> class MyCustomModel implements IModel
> {
> MyCustomObject getObject(Component component) { ... }
> ...
> }
> I imagine that this has already been suggested, but I couldn't find a JIRA
> issue about it in the road map.
> I don't think that the core Wicket code would change too much, except in
> cases where the code actually cared what was in the model. Elsewhere it can
> just use IModel.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1696) CaptchaImageResource - should take an IModel instead of String for captcha-text
[ https://issues.apache.org/jira/browse/WICKET-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Simik updated WICKET-1696: - Fix Version/s: (was: 1.4-M2) 1.4-M3 > CaptchaImageResource - should take an IModel instead of String for > captcha-text > --- > > Key: WICKET-1696 > URL: https://issues.apache.org/jira/browse/WICKET-1696 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Reporter: Stefan Simik > Fix For: 1.4-M3 > > Original Estimate: 0.33h > Remaining Estimate: 0.33h > > CaptchaImageResource - should take an IModel instead of String for > captcha-text -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-693) What to do with the wicket dtd?
[ https://issues.apache.org/jira/browse/WICKET-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604675#action_12604675 ] Timo Rantalaiho commented on WICKET-693: Is there a way to put them here http://wicket.apache.org/wicket-1.0-xhtml11.dtd http://wicket.apache.org/wicket-1.1-xhtml11.dtd http://wicket.apache.org/wicket-1.2-xhtml11.dtd http://wicket.apache.org/wicket-1.3-xhtml11.dtd http://wicket.apache.org/wicket-1.4-xhtml11.dtd http://wicket.apache.org/wicket-1.5-xhtml11.dtd ... for each release? And would it make any sense?-) > What to do with the wicket dtd? > --- > > Key: WICKET-693 > URL: https://issues.apache.org/jira/browse/WICKET-693 > Project: Wicket > Issue Type: Bug > Components: site, wicket >Reporter: Martijn Dashorst > Fix For: 1.4-M3 > > > The current dtd is located at the wicket.sf.net site, and may not even work. > We need to come up with a solution for the wicket dtd and fix this for the > future: > ./jdk-1.4/wicket/src/site/resources/DTD/wicket-1.0-xhtml11.dtd: SYSTEM > "http://wicket.sourceforge.net/DTD/wicket-xhtml1.dtd"; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1699) NPE in RequestLogger
[ https://issues.apache.org/jira/browse/WICKET-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604672#action_12604672 ] James Carman commented on WICKET-1699: -- In case anyone's interested, it looks like this was fixed in revision 661205. > NPE in RequestLogger > > > Key: WICKET-1699 > URL: https://issues.apache.org/jira/browse/WICKET-1699 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-M2 >Reporter: Craig McIlwee > Fix For: 1.4-M3 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > RequestLogger throws an NPE at line 200 because the field 'active' is never > assigned a value when the class is instantiated. In older versions (I am > migrating from 1.3.3) this field was just a native int so the value would > default to 0, but sometime between 1.3.3 and 1.4m2 it has changed to an > AtomicInteger and never assigned a value via new AtomicInteger() or new > AtomicInteger(someInt). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1312) Generic inter-component event mechanism
[ https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604674#action_12604674 ] James Carman commented on WICKET-1312: -- Are we going to introduce this stuff in 1.4? I thought 1.4 was all about generification? > Generic inter-component event mechanism > --- > > Key: WICKET-1312 > URL: https://issues.apache.org/jira/browse/WICKET-1312 > Project: Wicket > Issue Type: New Feature > Components: wicket-extensions >Affects Versions: 1.3.0-final >Reporter: Timo Rantalaiho > Fix For: 1.4-M3 > > Attachments: event-handler-with-testcase.zip, > Generic_EventBroadcaster.patch, > Generic_EventBroadcaster_glued_in_Component.patch > > > The attached patch provides a generic mechanism for transmitting > inter-component events within a page. This has grown primarily from the need > to repaint all relevant ajax components after an event, but can be used also > in non-ajax environments such as after normal form submits. > The basic idea is to fire an IVisitor on the page of the component sending an > event, giving as an argument an event-specific listener interface that must > be implemented by the components willing to receive the events. They can then > do whatever they need such as add themselves to the AjaxRequestTarget that > can be supplied in the event. > Sometimes the basic Wicket mechanisms such as sharing a model are not enough; > particularly repainting all relevant components in Ajax events gets tedious > if the components are far away from each other in a complex DOM tree. > The benefits of this approach are > - loose coupling between the sending and receiving end > - however, because of strong static typing it's easy enough to find with an > IDE from where the events are broadcasted and where they are received > - good testability (EventBroadcaster can be mocked on the sending end, and > event handlers tested directly on the receiving end, possibly with mock > events) > - no need the keep references to Component instances or their paths (which > could have been problematic on repeaters) > (This is not a real observer or listener pattern implementation because the > components cannot register and unregister themselves dynamically, but > "registering" is handled statically on a class basis by implementing the > relevant event receiver interface.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1699) NPE in RequestLogger
[ https://issues.apache.org/jira/browse/WICKET-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604671#action_12604671 ] James Carman commented on WICKET-1699: -- Looks like Igor already fixed this one. Can someone please resolve/close it? > NPE in RequestLogger > > > Key: WICKET-1699 > URL: https://issues.apache.org/jira/browse/WICKET-1699 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-M2 >Reporter: Craig McIlwee > Fix For: 1.4-M3 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > RequestLogger throws an NPE at line 200 because the field 'active' is never > assigned a value when the class is instantiated. In older versions (I am > migrating from 1.3.3) this field was just a native int so the value would > default to 0, but sometime between 1.3.3 and 1.4m2 it has changed to an > AtomicInteger and never assigned a value via new AtomicInteger() or new > AtomicInteger(someInt). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-550) Use WebRequestEncoder everywhere a query string is constructed
[ https://issues.apache.org/jira/browse/WICKET-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604670#action_12604670 ] Timo Rantalaiho commented on WICKET-550: So the idea is that WebRequestEncoder should always create a properly encoded query string with ?:s and &:s in their place? Does WebRequestEncoder need some changes to be usable everywhere? I tried using it in MockHttpServletRequest.getQueryString(), and a couple of tests started failing right away, something to do with null values. I got it working in RequestCycle.urlFor() though, and committed that. But I couldn't easily find other relevant placed where WebRequestEncoder could be used right away; for example in RequestCycle.urlFor() you need a non-encoding version of essentially the same stuff in some other situation... It seems that to get this cleaned up properly, we need a WicketUrl or some such class that can encapsulate the different URL mungling. > Use WebRequestEncoder everywhere a query string is constructed > -- > > Key: WICKET-550 > URL: https://issues.apache.org/jira/browse/WICKET-550 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta1 >Reporter: Jean-Baptiste Quenot > Fix For: 1.4-M3 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r667288 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestCycle.java
Author: thrantal
Date: Thu Jun 12 15:41:55 2008
New Revision: 667288
URL: http://svn.apache.org/viewvc?rev=667288&view=rev
Log:
WICKET-550: Changed one place to use WebRequestEncoder. However, just a bit
above there is code that nearly duplicates it. Probably custom URL objects
would be needed for better solution.
- no functional changes
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestCycle.java
Modified: wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestCycle.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestCycle.java?rev=667288&r1=667287&r2=667288&view=diff
==
--- wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestCycle.java
(original)
+++ wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestCycle.java Thu
Jun 12 15:41:55 2008
@@ -18,17 +18,18 @@
import java.util.Iterator;
import java.util.Map;
+import java.util.Map.Entry;
import org.apache.wicket.behavior.IBehavior;
import org.apache.wicket.protocol.http.BufferedWebResponse;
import org.apache.wicket.protocol.http.IRequestLogger;
import org.apache.wicket.protocol.http.PageExpiredException;
-import org.apache.wicket.protocol.http.WicketURLEncoder;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.apache.wicket.request.AbstractRequestCycleProcessor;
import org.apache.wicket.request.ClientInfo;
import org.apache.wicket.request.IRequestCycleProcessor;
import org.apache.wicket.request.RequestParameters;
+import org.apache.wicket.request.target.coding.WebRequestEncoder;
import
org.apache.wicket.request.target.component.BookmarkableListenerInterfaceRequestTarget;
import
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget;
import org.apache.wicket.request.target.component.ComponentRequestTarget;
@@ -865,7 +866,6 @@
// to do the endoding. This leads to
double encoding
// - Doug Donohoe
// @see
https://issues.apache.org/jira/browse/WICKET-1627
- //
pageParameters.add(encodeQueryStringItem(key), encodeQueryStringItem(value));
pageParameters.add(key, value);
}
}
@@ -893,17 +893,13 @@
if (params != null)
{
AppendingStringBuffer buff = new
AppendingStringBuffer(url);
- Iterator> it =
params.entrySet().iterator();
- while (it.hasNext())
- {
- final Map.Entry entry =
it.next();
- final String key = entry.getKey();
- final String value =
entry.getValue().toString();
- buff.append("&");
- buff.append(encodeQueryStringItem(key));
- buff.append("=");
-
buff.append(encodeQueryStringItem(value));
- }
+WebRequestEncoder encoder = new WebRequestEncoder(buff);
+for (Entry stringObjectEntry :
params.entrySet())
+{
+final String key = stringObjectEntry.getKey();
+final String value =
stringObjectEntry.getValue().toString();
+encoder.addValue(key, value);
+}
url = buff;
}
@@ -911,19 +907,7 @@
}
}
- /**
-* Url encodes value using UTF-8
-*
-* @param value
-*value to encode
-* @return encoded value
-*/
- private static String encodeQueryStringItem(String value)
- {
- return WicketURLEncoder.QUERY_INSTANCE.encode(value);
- }
-
- /**
+/**
* Returns a URL that references a given interface on a component. When
the URL is requested
* from the server at a later time, the interface will be called. A URL
returned by this method
* will not be stable across sessions and cannot be bookmarked by a
user.
[jira] Commented: (WICKET-1696) CaptchaImageResource - should take an IModel instead of String for captcha-text
[ https://issues.apache.org/jira/browse/WICKET-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604666#action_12604666 ] James Carman commented on WICKET-1696: -- Should this be moved to m3, since m2 is already out the door? > CaptchaImageResource - should take an IModel instead of String for > captcha-text > --- > > Key: WICKET-1696 > URL: https://issues.apache.org/jira/browse/WICKET-1696 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Reporter: Stefan Simik > Fix For: 1.4-M2 > > Original Estimate: 0.33h > Remaining Estimate: 0.33h > > CaptchaImageResource - should take an IModel instead of String for > captcha-text -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1694) wicket complains that ValueMap$NullSafeKeyComparator is not serializable
[ https://issues.apache.org/jira/browse/WICKET-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Bille Jensen resolved WICKET-1694. Resolution: Fixed > wicket complains that ValueMap$NullSafeKeyComparator is not serializable > > > Key: WICKET-1694 > URL: https://issues.apache.org/jira/browse/WICKET-1694 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-M3 >Reporter: Peter Ertl >Assignee: Frank Bille Jensen > Fix For: 1.4-M3 > > Attachments: let-null-safe-key-comparator-implement-serializable.patch > > > wicket complains that ValueMap$NullSafeKeyComparator is not serializable: > 2070 ERROR [btpool0-19] org.apache.wicket.util.lang.Objects - Error > serializing object class testapp.pages.ContactPage [object=[Page class = > testapp.pages.ContactPage, id = 0, version = 0]] > org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: > Unable to serialize class: > org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator > Field hierarchy is: > 0 [class=testapp.pages.ContactPage, path=0] > java.lang.Object org.apache.wicket.Component.data > [class=[Lorg.apache.wicket.MetaDataEntry;] > java.lang.Object org.apache.wicket.Component.data[0] > [class=org.apache.wicket.MetaDataEntry] > java.lang.Object org.apache.wicket.MetaDataEntry.object > [class=org.apache.wicket.PageParameters] > private java.util.Comparator java.util.TreeMap.comparator > [class=org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator] <- > field that is not serializable > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:349) > at > org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) > at > org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395) > at > org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) > at > org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:687) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298) > at > org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:127) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298) > at > org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1100) > at > org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:200) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327) > at org.apache.wicket.Session.requestDetached(Session.java:1391) > at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1384) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.BoundedThreadPo
svn commit: r667263 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/util/value/ValueMap.java test/java/org/apache/wicket/util/value/ValueMapTest.java
Author: frankbille
Date: Thu Jun 12 15:10:02 2008
New Revision: 667263
URL: http://svn.apache.org/viewvc?rev=667263&view=rev
Log:
WICKET-1694: wicket complains that ValueMap$NullSafeKeyComparator is not
serializable
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/util/value/ValueMap.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/value/ValueMapTest.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/util/value/ValueMap.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/util/value/ValueMap.java?rev=667263&r1=667262&r2=667263&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/util/value/ValueMap.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/util/value/ValueMap.java
Thu Jun 12 15:10:02 2008
@@ -16,6 +16,7 @@
*/
package org.apache.wicket.util.value;
+import java.io.Serializable;
import java.lang.reflect.Array;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
@@ -53,8 +54,8 @@
* The makeImmutable method will make the underlying
Map immutable.
* Further attempts to change the Map will result in a
RuntimeException.
*
- * The toString method converts a ValueMap object to
a readable
- * key/value string for diagnostics.
+ * The toString method converts a ValueMap object to
a readable key/value
+ * string for diagnostics.
*
* @author Jonathan Locke
* @author Doug Donohoe
@@ -70,8 +71,10 @@
* [EMAIL PROTECTED] HashMap}, so we must provide a null safe
comparator to avoid null pointer exceptions
* with null keys.
*/
- private static class NullSafeKeyComparator implements Comparator
+ private static class NullSafeKeyComparator implements
Comparator, Serializable
{
+ private static final long serialVersionUID = 1L;
+
public int compare(String o1, String o2)
{
int compare = 0;
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/value/ValueMapTest.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/util/value/ValueMapTest.java?rev=667263&r1=667262&r2=667263&view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/value/ValueMapTest.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/value/ValueMapTest.java
Thu Jun 12 15:10:02 2008
@@ -16,7 +16,10 @@
*/
package org.apache.wicket.util.value;
+import java.io.NotSerializableException;
+
import junit.framework.TestCase;
+import org.apache.wicket.util.io.SerializableChecker;
import org.apache.wicket.util.time.Time;
import org.apache.wicket.util.time.Duration;
@@ -228,4 +231,15 @@
assertNull(vm.getAsDuration("duration.missing"));
assertEquals(defDuration, vm.getAsDuration("duration.missing",
defDuration));
}
+
+ /**
+* Make sure that ValueMap is serializable.
+*
+* @throws Exception
+*/
+ public void testSerializable() throws Exception
+ {
+ SerializableChecker checker = new SerializableChecker(new
NotSerializableException());
+ checker.writeObject(new ValueMap());
+ }
}
svn commit: r667260 - in /wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload: FileUploadFieldTest.java MockPageWithFormAndUploadField.java
Author: thrantal
Date: Thu Jun 12 15:04:38 2008
New Revision: 667260
URL: http://svn.apache.org/viewvc?rev=667260&view=rev
Log:
Cleaned up some raw types, added missing @Override, removed redundant javadoc
- no functional changes
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/MockPageWithFormAndUploadField.java
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java?rev=667260&r1=667259&r2=667260&view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
Thu Jun 12 15:04:38 2008
@@ -53,8 +53,6 @@
/**
* Test that detach closes the streams
-*
-* @throws Exception
*/
public void testInternalDetach() throws Exception
{
@@ -64,7 +62,7 @@
{
private static final long serialVersionUID = 1L;
- public Page getTestPage()
+ public Page getTestPage()
{
return page;
}
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/MockPageWithFormAndUploadField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/MockPageWithFormAndUploadField.java?rev=667260&r1=667259&r2=667260&view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/MockPageWithFormAndUploadField.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/MockPageWithFormAndUploadField.java
Thu Jun 12 15:04:38 2008
@@ -28,7 +28,7 @@
{
private static final long serialVersionUID = 1L;
- private final Form form;
+ private final Form form;
private final FileUploadField fileUploadField;
private FileUpload fileUpload;
@@ -44,7 +44,8 @@
*/
private static final long serialVersionUID = 1L;
- protected void onSubmit()
+ @Override
+protected void onSubmit()
{
fileUpload = fileUploadField.getFileUpload();
}
@@ -57,7 +58,7 @@
/**
* @return The form to attach the FileUploadField to.
*/
- public Form getForm()
+ public Form getForm()
{
return form;
}
[jira] Commented: (WICKET-306) XML License Header Tests fail with Unicode BOM
[ https://issues.apache.org/jira/browse/WICKET-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604655#action_12604655 ] Timo Rantalaiho commented on WICKET-306: What is the impact of this bug? Am I missing something, or is it just that if you add a UTF-8 XML file with a BOM in the project, the build will fail? If that is the case, maybe it is an acceptable workaround to fix such files by hand with the way that Jean-Baptiste presents, until we move to Java 6. The build server should let us know if that happens. > XML License Header Tests fail with Unicode BOM > -- > > Key: WICKET-306 > URL: https://issues.apache.org/jira/browse/WICKET-306 > Project: Wicket > Issue Type: Bug > Components: wicket >Reporter: Jean-Baptiste Quenot > Fix For: 1.4-M3 > > > License header tests use FileReader, which is subject to a JDK bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4508058 > Namely, if the XML file is encoded using UTF-8 *and* has a BOM (this is > optional), license check fails. > We might integrate Unicode Reader from > http://koti.mbnet.fi/akini/java/unicodereader/ provided that the license is > ASL compatible. > A workaround is to remove the optional Unicode BOM. I do that in Vim by > using "set nobomb" and writing the file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1684) FileUploadField should return FileUpload as its converted input
[
https://issues.apache.org/jira/browse/WICKET-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timo Rantalaiho resolved WICKET-1684.
-
Resolution: Fixed
Fixed in trunk (1.4). Thanks for reporting!
> FileUploadField should return FileUpload as its converted input
> ---
>
> Key: WICKET-1684
> URL: https://issues.apache.org/jira/browse/WICKET-1684
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-M2
>Reporter: Ned Collyer
>Assignee: Timo Rantalaiho
>Priority: Minor
> Fix For: 1.4-M3
>
>
> FileUploadField should return FileUpload as its converted input so the file
> can be validated.
> Eg,
> @Override
> protected void convertInput() {
> setConvertedInput(getFileUpload());
> }
> Apparently MultiFileUploadField handles this (I've checked, it appears to be
> in the convertValue method).
> For more context see
> http://www.nabble.com/Best-way-of-validating-FileUploadField-td17662018.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r667232 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
Author: thrantal
Date: Thu Jun 12 14:21:04 2008
New Revision: 667232
URL: http://svn.apache.org/viewvc?rev=667232&view=rev
Log:
WICKET-1684: Changed converting input to create the FileUpload object, the same
way as MultiFileUploadField already does. Previously converted input was the
filename, which can now be found from the FileUpload object.
Now validators (that operate on converted input) can access the actual file
contents in validation.
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java?rev=667232&r1=667231&r2=667232&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
Thu Jun 12 14:21:04 2008
@@ -22,6 +22,7 @@
import org.apache.wicket.markup.html.form.FormComponent;
import org.apache.wicket.model.IModel;
import org.apache.wicket.protocol.http.IMultipartWebRequest;
+import org.apache.wicket.util.convert.ConversionException;
import org.apache.wicket.util.upload.FileItem;
/**
@@ -130,7 +131,18 @@
return null;
}
- /**
+@Override
+protected FileUpload convertValue(String[] value) throws
ConversionException
+{
+final String[] filenames = getInputAsArray();
+if (filenames == null)
+{
+return null;
+}
+return getFileUpload();
+}
+
+/**
* @see org.apache.wicket.markup.html.form.FormComponent#isMultiPart()
*/
@Override
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java?rev=667232&r1=667231&r2=667232&view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/form/upload/FileUploadFieldTest.java
Thu Jun 12 14:21:04 2008
@@ -17,16 +17,22 @@
package org.apache.wicket.markup.html.form.upload;
import java.io.BufferedOutputStream;
+import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
+import java.util.HashSet;
+import java.util.Set;
+import org.apache.wicket.Component.IVisitor;
import org.apache.wicket.Page;
import org.apache.wicket.WicketTestCase;
import org.apache.wicket.util.file.File;
import org.apache.wicket.util.tester.FormTester;
import org.apache.wicket.util.tester.ITestPageSource;
+import org.apache.wicket.validation.IValidatable;
+import org.apache.wicket.validation.IValidator;
/**
@@ -75,13 +81,7 @@
// know the path of (e.g. the big DTD this test used
previously). This enables
// us to run the test out of a JAR file if need be, and
also with an unknown
// running directory (e.g. when run from wicket-parent).
- tmp = new
File(java.io.File.createTempFile(this.getClass().getName(), ".txt"));
- OutputStream os = new BufferedOutputStream(new
FileOutputStream(tmp));
- for (int i = 0; i < 1000; i++)
- {
- os.write("test test test test
test\n".getBytes());
- }
- os.close();
+tmp = writeTestFile(1000);
// Let's upload the dtd file. It's large enough to
avoid being in memory.
FormTester formtester = tester.newFormTester("form");
@@ -124,4 +124,95 @@
}
}
}
+
+public void testFileUploadCanBeValidated() throws IOException
+{
+final Set validatedComponents = new
HashSet();
+
+final File tmpFile = writeTestFile(1);
+tmpFile.deleteOnExit();
+
+final IValidator testValidator = new IValidator()
+{
+public void validate(IValidatable validatable)
+{
+validatedComponents.add(validatable);
+assertEquals(FileUpload.class,
validatable.getValue().getClass());
+FileUpload upload = (FileUpload) validatable.getValue();
+assertEquals(tmpFile.get
[jira] Issue Comment Edited: (WICKET-1698) IE7 memory leak when components are updated via AJAX
[
https://issues.apache.org/jira/browse/WICKET-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604616#action_12604616
]
nbo edited comment on WICKET-1698 at 6/12/08 12:21 PM:
Thanks for your fast response.
Concerning the AutoComplete example: I intended to refer to the
protected void onSubmit(AjaxRequestTarget target)
{
target.addComponent(label);
}
part of the very bottom of AutoCompletePage.java. Wickets JavaDoc talks about
updating instead of replacing for AjaxRequestTarget.onSubmit(), sorry if I was
misleading.
Below is a link to a screenshot from Drip showing the leaking elements of the
AutoComplete example app running in a local jetty. For that, I disabled Wicket
AJAX debugging by setting "getDebugSettings().setAjaxDebugModeEnabled(false);"
in the Ajax application (was true before). I double-checked that, and the
Wicket AJAX Debug link is not visible on the web page.
Screenshot: http://img225.imageshack.us/my.php?image=dripae4.png
was (Author: nbo):
Thanks for your fast response.
Concerning the AutoComplete example: I intended to refer to the
protected void onSubmit(AjaxRequestTarget target)
{
target.addComponent(label);
}
part of the very bottom of AutoCompletePage.java. Wickets JavaDoc talks about
updating instead of replacing for AjaxRequestTarget.onSubmit(), sorry if I was
misleading.
I added a screenshot from Drip showing the leaking elements of the AutoComplete
example app running in a local jetty. For that, I disabled Wicket AJAX
debugging by setting "getDebugSettings().setAjaxDebugModeEnabled(false);" in
the Ajax application (was true before). I double-checked that, and the Wicket
AJAX Debug link is not visible on the web page.
> IE7 memory leak when components are updated via AJAX
>
>
> Key: WICKET-1698
> URL: https://issues.apache.org/jira/browse/WICKET-1698
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3, 1.4-M2
> Environment: WinXP SP3, IE7
>Reporter: Niels Boeger
>Assignee: Matej Knopp
>
> I noticed a large increase in IE7s memory consumption when a wicket component
> is updated via AJAX.
> In my case, I used wicket to update the markup of a html table. The table
> acts as datasource for a yui datatable. The markup update is triggered by a
> "wicketAjaxGet" request on the client, and Wicket updates the markup of the
> table.
> Drip (http://www.outofhanwell.com/ieleak/) shows that old markup is not
> garbage collected by IE7.
> YUI does not seem to be the culprit, the problem occured even when I removed
> all YUI code.
> Using Drip on the AutoComplete example
> (http://www.wicketstuff.org/wicket13/ajax/autocomplete) shows the same
> behavior.
> I tested this in my application with both Wicket 1.3.3 and Wicket 1.4-M2.
> FF2 (Mac OS X & WinXP), FF3RC2 (WinXP) and Safari 3.1 (Mac OS X) run fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1698) IE7 memory leak when components are updated via AJAX
[
https://issues.apache.org/jira/browse/WICKET-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604616#action_12604616
]
Niels Boeger commented on WICKET-1698:
--
Thanks for your fast response.
Concerning the AutoComplete example: I intended to refer to the
protected void onSubmit(AjaxRequestTarget target)
{
target.addComponent(label);
}
part of the very bottom of AutoCompletePage.java. Wickets JavaDoc talks about
updating instead of replacing for AjaxRequestTarget.onSubmit(), sorry if I was
misleading.
I added a screenshot from Drip showing the leaking elements of the AutoComplete
example app running in a local jetty. For that, I disabled Wicket AJAX
debugging by setting "getDebugSettings().setAjaxDebugModeEnabled(false);" in
the Ajax application (was true before). I double-checked that, and the Wicket
AJAX Debug link is not visible on the web page.
> IE7 memory leak when components are updated via AJAX
>
>
> Key: WICKET-1698
> URL: https://issues.apache.org/jira/browse/WICKET-1698
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3, 1.4-M2
> Environment: WinXP SP3, IE7
>Reporter: Niels Boeger
>Assignee: Matej Knopp
>
> I noticed a large increase in IE7s memory consumption when a wicket component
> is updated via AJAX.
> In my case, I used wicket to update the markup of a html table. The table
> acts as datasource for a yui datatable. The markup update is triggered by a
> "wicketAjaxGet" request on the client, and Wicket updates the markup of the
> table.
> Drip (http://www.outofhanwell.com/ieleak/) shows that old markup is not
> garbage collected by IE7.
> YUI does not seem to be the culprit, the problem occured even when I removed
> all YUI code.
> Using Drip on the AutoComplete example
> (http://www.wicketstuff.org/wicket13/ajax/autocomplete) shows the same
> behavior.
> I tested this in my application with both Wicket 1.3.3 and Wicket 1.4-M2.
> FF2 (Mac OS X & WinXP), FF3RC2 (WinXP) and Safari 3.1 (Mac OS X) run fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1700) Make functionality of ContextImage a behavior so that other types of components can utilize its functionality
Make functionality of ContextImage a behavior so that other types of components can utilize its functionality - Key: WICKET-1700 URL: https://issues.apache.org/jira/browse/WICKET-1700 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-M2 Environment: N/A Reporter: Will Hoover Priority: Trivial It would be better if ContextImage was a behavior rather than an actual component. For instance, if you have an html input of type=image (or a link for that matter) you can still utilize the behavior whereas a component you cannot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1684) FileUploadField should return FileUpload as its converted input
[
https://issues.apache.org/jira/browse/WICKET-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timo Rantalaiho reassigned WICKET-1684:
---
Assignee: Timo Rantalaiho
> FileUploadField should return FileUpload as its converted input
> ---
>
> Key: WICKET-1684
> URL: https://issues.apache.org/jira/browse/WICKET-1684
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-M2
>Reporter: Ned Collyer
>Assignee: Timo Rantalaiho
>Priority: Minor
> Fix For: 1.4-M3
>
>
> FileUploadField should return FileUpload as its converted input so the file
> can be validated.
> Eg,
> @Override
> protected void convertInput() {
> setConvertedInput(getFileUpload());
> }
> Apparently MultiFileUploadField handles this (I've checked, it appears to be
> in the convertValue method).
> For more context see
> http://www.nabble.com/Best-way-of-validating-FileUploadField-td17662018.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1699) NPE in RequestLogger
NPE in RequestLogger Key: WICKET-1699 URL: https://issues.apache.org/jira/browse/WICKET-1699 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-M2 Reporter: Craig McIlwee Fix For: 1.4-M3 RequestLogger throws an NPE at line 200 because the field 'active' is never assigned a value when the class is instantiated. In older versions (I am migrating from 1.3.3) this field was just a native int so the value would default to 0, but sometime between 1.3.3 and 1.4m2 it has changed to an AtomicInteger and never assigned a value via new AtomicInteger() or new AtomicInteger(someInt). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1698) IE7 memory leak when components are updated via AJAX
[ https://issues.apache.org/jira/browse/WICKET-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604569#action_12604569 ] Matej Knopp commented on WICKET-1698: - This doesn't really makes sense, at least not of the autocomplete example because it doesn't replace any markup. Are you sure you didn't test it in development mode? (with the debug console turned on) > IE7 memory leak when components are updated via AJAX > > > Key: WICKET-1698 > URL: https://issues.apache.org/jira/browse/WICKET-1698 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.3, 1.4-M2 > Environment: WinXP SP3, IE7 >Reporter: Niels Boeger >Assignee: Matej Knopp > > I noticed a large increase in IE7s memory consumption when a wicket component > is updated via AJAX. > In my case, I used wicket to update the markup of a html table. The table > acts as datasource for a yui datatable. The markup update is triggered by a > "wicketAjaxGet" request on the client, and Wicket updates the markup of the > table. > Drip (http://www.outofhanwell.com/ieleak/) shows that old markup is not > garbage collected by IE7. > YUI does not seem to be the culprit, the problem occured even when I removed > all YUI code. > Using Drip on the AutoComplete example > (http://www.wicketstuff.org/wicket13/ajax/autocomplete) shows the same > behavior. > I tested this in my application with both Wicket 1.3.3 and Wicket 1.4-M2. > FF2 (Mac OS X & WinXP), FF3RC2 (WinXP) and Safari 3.1 (Mac OS X) run fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1698) IE7 memory leak when components are updated via AJAX
[ https://issues.apache.org/jira/browse/WICKET-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg reassigned WICKET-1698: - Assignee: Matej Knopp > IE7 memory leak when components are updated via AJAX > > > Key: WICKET-1698 > URL: https://issues.apache.org/jira/browse/WICKET-1698 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.3, 1.4-M2 > Environment: WinXP SP3, IE7 >Reporter: Niels Boeger >Assignee: Matej Knopp > > I noticed a large increase in IE7s memory consumption when a wicket component > is updated via AJAX. > In my case, I used wicket to update the markup of a html table. The table > acts as datasource for a yui datatable. The markup update is triggered by a > "wicketAjaxGet" request on the client, and Wicket updates the markup of the > table. > Drip (http://www.outofhanwell.com/ieleak/) shows that old markup is not > garbage collected by IE7. > YUI does not seem to be the culprit, the problem occured even when I removed > all YUI code. > Using Drip on the AutoComplete example > (http://www.wicketstuff.org/wicket13/ajax/autocomplete) shows the same > behavior. > I tested this in my application with both Wicket 1.3.3 and Wicket 1.4-M2. > FF2 (Mac OS X & WinXP), FF3RC2 (WinXP) and Safari 3.1 (Mac OS X) run fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: Portal HowTo (page edited)
Page Edited : WICKET : Portal HowTo Portal HowTo has been edited by Ate Douma (Jun 12, 2008). (View changes) Content: Bookmarkable link Table of contents PortletResourceURLFactory ServletContextProvider WicketPortlet web.xml Enabling portlet support portlet.xml To get you started, I'll give the important configuration (and portal runtime) settings/requirements inline here. These will eventually end up tidied up, but for the moment, this is it... PortletResourceURLFactory First of all, you need to make sure the portal (e.g. Liferay ) provides an implementation of the Apache Portals Bridges PortletResourceURLFactory interface, see: PortletResourceURLFactory The related jar containing this interface, portal-bridges-common-1.0.3.jar (available from repo1.maven.org) needs to be in your portlet classpath directly or provided in the shared classpath of your portal. You will have to check if your portal provides support for these kind of RenderURLs which allows direct access to a portlet and full control over its response (like setting content type etc.). A ResourceURL will be a standard JSR-286 (Portlet API 2.0) feature but as it isn't yet released (Oct'07 - it will be soon) for which I created this temporary interface to allow using it in a JSR-186 container as well, as long as a portal provides a propetairy mapping for it. Jetspeed 2 does, and AFAIK, most other portals do as well, you just need to find out how to map this for Liferay and provide (or use) their proprietary api to handle it. ServletContextProvider Secondly, you need also to provide an implementation of the Apache Portals Bridges ServletContextProvider interface, see: ServletContextProvider That I know Liferay already provides as I know it provides support for the Apache Portals Struts Bridge which uses the same interface. Note: this interface also is provided with the portal-bridges-common-1.0.3.jar (and earlier). BTW: this inteface also won't be needed anymore for proper JSR-286 containers. Once they are available I'll upgrade the Wicket Portlet support to really work out-of-the-box and portal specific configurations won't be needed then. WicketPortlet The implementations of these two interfaces need to be provided to the WicketPortlet. There are three ways of doing that, the simplest is providing a WicketPortlet.properties file in the classpath under package org.apache.wicket.protocol.http.portlet. The one I provide with Jetspeed 2 (out-of-the-box through a shared library) contains the following: # Default Jetspeed-2 provided WicketPortlet ServletContextProvider and PortletResourceURLFactory org.apache.portals.bridges.common.ServletContextProvider=org.apache.jetspeed.portlet.ServletContextProviderImpl org.apache.portals.bridges.common.PortletResourceURLFactory=org.apache.jetspeed.portlet.PortletResourceURLFactoryImpl Another way of defining these (maybe easier for testing) is providing them as portlet init parameters (named "ServletContextProvider" and "PortletResourceURLFactory") or even as web.xml context param using their full class name just as in the properties file. Defining these through WicketPortlet.properties though will allow you to keep this portal specific configuration out of your application and thus be more portable. web.xml You will also need to modify the wicket filter mapping in your web.xml to support handling both direct requests as well include dispatch requests, e.g. AjaxApplication /ajax/* REQUEST INCLUDE Note: this requires at least a Servlet 2.4 descriptor just as in the wicket-examples application. Enabling portlet support By default portlet support will *not* be enabled (as of wicket 1.3.0-beta5), because even when deployed in a portlet supporting web container, a Wicket application might not or should not be used as portlet. So, you'll have to provide a configuration setting to let WicketFilter detect if it actually is running in a Portlet Context. This can be done using a boolean (true|false) value on three different levels: as filter parameter, web.xml context parameter, or finally as property in the above described WicketPortlet.properties. WicketFilter will check for such a configuration in the above order. To define this on filter level (possibly overriding a setting on web.xml or WicketPortlet.properties level): MyWicketApplication org.apache.wicket.protocol.http.WicketFilter detectPortletContext true ... To define this on web.xml context level as default for the whole of the web application (possibly overriding a setting on WicketPortlet.properties level): org.apache.wicket.detectPortletContext true Finally, you can also set this globally through the classpath in WicketPortlet.properties: org.apache.wicket.detectPortletC
[CONF] Apache Wicket: Portal HowTo (page edited)
Page Edited : WICKET : Portal HowTo Portal HowTo has been edited by John (Jun 12, 2008). Change summary: added note (View changes) Content: Bookmarkable link Table of contents PortletResourceURLFactory ServletContextProvider WicketPortlet web.xml Enabling portlet support portlet.xml To get you started, I'll give the important configuration (and portal runtime) settings/requirements inline here. These will eventually end up tidied up, but for the moment, this is it... PortletResourceURLFactory First of all, you need to make sure the portal (e.g. Liferay ) provides an implementation of the Apache Portals Bridges PortletResourceURLFactory interface, see: PortletResourceURLFactory The related jar containing this interface, portal-bridges-common-1.0.3.jar (available from repo1.maven.org) needs to be in your portlet classpath directly or provided in the shared classpath of your portal. You will have to check if your portal provides support for these kind of RenderURLs which allows direct access to a portlet and full control over its response (like setting content type etc.). A ResourceURL will be a standard JSR-286 (Portlet API 2.0) feature but as it isn't yet released (Oct'07 - it will be soon) for which I created this temporary interface to allow using it in a JSR-186 container as well, as long as a portal provides a propetairy mapping for it. Jetspeed 2 does, and AFAIK, most other portals do as well, you just need to find out how to map this for Liferay and provide (or use) their proprietary api to handle it. ServletContextProvider Secondly, you need also to provide an implementation of the Apache Portals Bridges ServletContextProvider interface, see: ServletContextProvider That I know Liferay already provides as I know it provides support for the Apache Portals Struts Bridge which uses the same interface. Note: this interface also is provided with the portal-bridges-common-1.0.3.jar (and earlier). BTW: this inteface also won't be needed anymore for proper JSR-286 containers. Once they are available I'll upgrade the Wicket Portlet support to really work out-of-the-box and portal specific configurations won't be needed then. WicketPortlet The implementations of these two interfaces need to be provided to the WicketPortlet. There are three ways of doing that, the simplest is providing a WicketPortlet.properties file in the classpath under package org.apache.wicket.protocol.http.portlet. The one I provide with Jetspeed 2 (out-of-the-box through a shared library) contains the following: # Default Jetspeed-2 provided WicketPortlet ServletContextProvider and PortletResourceURLFactory org.apache.portals.bridges.common.ServletContextProvider=org.apache.jetspeed.portlet.ServletContextProviderImpl org.apache.portals.bridges.common.PortletResourceURLFactory=org.apache.jetspeed.portlet.PortletResourceURLFactoryImpl Another way of defining these (maybe easier for testing) is providing them as portlet init parameters (named "ServletContextProvider" and "PortletResourceURLFactory") or even as web.xml context param using their full class name just as in the properties file. Defining these through WicketPortlet.properties though will allow you to keep this portal specific configuration out of your application and thus be more portable. web.xml You will also need to modify the wicket filter mapping in your web.xml to support handling both direct requests as well include dispatch requests, e.g. AjaxApplication /ajax/* REQUEST INCLUDE Note: this requires at least a Servlet 2.4 descriptor just as in the wicket-examples application. Enabling portlet support By default portlet support will *not* be enabled (as of wicket 1.3.0-beta5), because even when deployed in a portlet supporting web container, a Wicket application might not or should not be used as portlet. So, you'll have to provide a configuration setting to let WicketFilter detect if it actually is running in a Portlet Context. This can be done using a boolean (true|false) value on three different levels: as filter parameter, web.xml context parameter, or finally as property in the above described WicketPortlet.properties. WicketFilter will check for such a configuration in the above order. To define this on filter level (possibly overriding a setting on web.xml or WicketPortlet.properties level): MyWicketApplication org.apache.wicket.protocol.http.WicketFilter detectPortletContext true ... To define this on web.xml context level as default for the whole of the web application (possibly overriding a setting on WicketPortlet.properties level): org.apache.wicket.detectPortletContext true Finally, you can also set this globally through the classpath in WicketPortlet.proper
[jira] Commented: (WICKET-1558) WicketTester.startPage(page) throws "No requestCycle is currently set"
[
https://issues.apache.org/jira/browse/WICKET-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604507#action_12604507
]
Martin Grigorov commented on WICKET-1558:
-
Just for the history: using wicketTester.clickLink(String, true) (i.e. AJAX
request) will detach the RequestCycle at the end of the call and thus it will
be 'null' from now on.
This is valid for Wicket 1.3.2.
> WicketTester.startPage(page) throws "No requestCycle is currently set"
> --
>
> Key: WICKET-1558
> URL: https://issues.apache.org/jira/browse/WICKET-1558
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3
> Environment: Eclipse 3.3.1.1 on Ubuntu 7.10
>Reporter: Federico Fanton
>Assignee: Maurice Marrink
>Priority: Minor
> Fix For: 1.3.4
>
> Attachments: testreqcycle.zip
>
>
> I'm receiving a strange message with WicketTester in 1.3.3.. Whenever I use
> startPage(Page) I get a
> "there was an error cleaning up target [EMAIL PROTECTED] class =
> org.apache.wicket.util.tester.DummyHomePage, id = 1, version =
> 0]->testPage->interface
> org.apache.wicket.markup.html.link.ILinkListener.ILinkListener (request
> paramaters: [RequestParameters componentPath=1:testPage pageMapName=null
> versionNumber=0 interfaceName=ILinkListener componentId=null behaviorId=null
> urlDepth=-1 parameters={} onlyProcessIfPathActive=false])."
> followed by
> "No requestcycle is currently set!"
> To reproduce, just use a QuickStart with a completely static Homepage.html
> (no wicket:id's) and an empty Homepage.class (just a "Homepage extends
> WebPage"), while the test itself is
> new WicketTester().startPage(new HomePage());
> with
> log4j.logger.org.apache.wicket=DEBUG
> inside log4j.properties, to enable logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1698) IE7 memory leak when components are updated via AJAX
IE7 memory leak when components are updated via AJAX Key: WICKET-1698 URL: https://issues.apache.org/jira/browse/WICKET-1698 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-M2, 1.3.3 Environment: WinXP SP3, IE7 Reporter: Niels Boeger I noticed a large increase in IE7s memory consumption when a wicket component is updated via AJAX. In my case, I used wicket to update the markup of a html table. The table acts as datasource for a yui datatable. The markup update is triggered by a "wicketAjaxGet" request on the client, and Wicket updates the markup of the table. Drip (http://www.outofhanwell.com/ieleak/) shows that old markup is not garbage collected by IE7. YUI does not seem to be the culprit, the problem occured even when I removed all YUI code. Using Drip on the AutoComplete example (http://www.wicketstuff.org/wicket13/ajax/autocomplete) shows the same behavior. I tested this in my application with both Wicket 1.3.3 and Wicket 1.4-M2. FF2 (Mac OS X & WinXP), FF3RC2 (WinXP) and Safari 3.1 (Mac OS X) run fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1697) Bad caching in tag for the same key in same markup structure
Bad caching in tag for the same key in same markup structure - Key: WICKET-1697 URL: https://issues.apache.org/jira/browse/WICKET-1697 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-M2 Environment: Wicket 1.4-M2, Java 1.6, Windows Reporter: Karel Cabel Priority: Minor wicket:message tag constructs the same key string (into cache) for same text key in the same 'element structure' in different pages. So if you load string in one page, this string will not change in other page until you change language etc. Example: you have two independent pages (in different packages) with own *.properties files (with 'title' key) and each page has HTML markup: In this case, Localizer.java in line 210 will produce the same key (for 'title') for two independent pages. Because there is no parent div in markup file, cache key will be like this: "title-org.apache.wicket.markup.resolver.MarkupInheritanceResolver$TransparentWebMarkupContainer:_extend11-org.apache.wicket.markup.resolver.MarkupInheritanceResolver$TransparentWebMarkupContainer:_child10-cs-null" but same for BOTH pages. Problem is, that this cache key is constructed via parent tags in HTML (up to page) and if you have the same parents and same key attribute in message tag, it will always hit cached string from other pages. The only way to avoid this is to use different message keys in different pages. But this is very bad for us. I think, that one good solution is to append page name into cache string - it will be like namespace in XML... Bye (perfect work with Wicket!) Karel, Prague -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1671) Performance problem with detach (Component.isAuto)
[ https://issues.apache.org/jira/browse/WICKET-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604434#action_12604434 ] Ari Suutari commented on WICKET-1671: - Would it be possible for Component.add to propaganate FLAG_AUTO to children if the parent already has it ? This way Component.isAuto wouldn't have to check the component tree upwards every time, which would fix this. Now, isAuto traverses the component tree up every time it is called (and it is called in detach a lot, since it traverses component tree from up to down) and for most of time components don't have FLAG_AUTO so this just wastes a lot of time. This issue is very visible on pages which have a lot of images, for example, since one page render results in browser requesting those images - a lot of requests, a lot of detach calls and a lot of isAuto calls - page renders very slowly. > Performance problem with detach (Component.isAuto) > -- > > Key: WICKET-1671 > URL: https://issues.apache.org/jira/browse/WICKET-1671 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.3 > Environment: Tomcat 5.5.23 > Windows XP/JDK 1.6.0_03 > Windows 2003/JDK 1.5 >Reporter: Heikki Uotinen >Assignee: Johan Compagner > Attachments: detach.zip > > > We have an application that uses AjaxSelfUpdatingTimerBehavior to update a > panel that has several child components. > Application has a performance problem and profiler shows that the most time > is consumed in Component.isAuto method. > It seems that isAuto flag is checked up and down the component tree. > There is attached a simple demonstration about the problem and screenshots of > the profiler displays. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
