[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-tabpanelfocusedCommentId=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.
[jira] Created: (WICKET-1697) Bad caching in wicket:message tag for the same key in same markup structure
Bad caching in wicket:message 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: wicket:extend wicket:message key=title 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] 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] 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-tabpanelfocusedCommentId=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.
[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. filter-mapping filter-nameAjaxApplication/filter-name url-pattern/ajax/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping 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 (truefalse) 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): filter filter-nameMyWicketApplication/filter-name filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class init-param param-namedetectPortletContext/param-name param-valuetrue/param-value /init-param ... /filter To define this on web.xml context level as default for
[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. filter-mapping filter-nameAjaxApplication/filter-name url-pattern/ajax/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping 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 (truefalse) 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): filter filter-nameMyWicketApplication/filter-name filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class init-param param-namedetectPortletContext/param-name param-valuetrue/param-value /init-param ... /filter To define this on web.xml context level as default for the whole of the web application
[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.
[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-tabpanelfocusedCommentId=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] 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] 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-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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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.
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=667232view=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=667232r1=667231r2=667232view=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=667232r1=667231r2=667232view=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 SetIValidatable validatedComponents = new
HashSetIValidatable();
+
+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();
+
[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.
[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-tabpanelfocusedCommentId=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.
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=667260view=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=667260r1=667259r2=667260view=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=667260r1=667259r2=667260view=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;
}
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=667263view=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=667263r1=667262r2=667263view=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 codemakeImmutable/code method will make the underlying
codeMap/code immutable.
* Further attempts to change the codeMap/code will result in a
codeRuntimeException/code.
* p
- * The codetoString/code method converts a codeValueMap/code object to
a readable
- * key/value string for diagnostics.
+ * The codetoString/code method converts a codeValueMap/code 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 ComparatorString
+ private static class NullSafeKeyComparator implements
ComparatorString, 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=667263r1=667262r2=667263view=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());
+ }
}
[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.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) Caused by: java.io.NotSerializableException:
[jira] Commented: (WICKET-1696) CaptchaImageResource - should take an IModelString instead of String for captcha-text
[ https://issues.apache.org/jira/browse/WICKET-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 IModelString 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 IModelString 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.
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=667288view=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=667288r1=667287r2=667288view=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);
- IteratorMap.EntryString, Object it =
params.entrySet().iterator();
- while (it.hasNext())
- {
- final Map.EntryString, Object 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 (EntryString, Object 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-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-tabpanelfocusedCommentId=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.
[jira] Commented: (WICKET-1699) NPE in RequestLogger
[ https://issues.apache.org/jira/browse/WICKET-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1699) NPE in RequestLogger
[ https://issues.apache.org/jira/browse/WICKET-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-693) What to do with the wicket dtd?
[ https://issues.apache.org/jira/browse/WICKET-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Updated: (WICKET-1696) CaptchaImageResource - should take an IModelString 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 IModelString 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 IModelString 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-1696) CaptchaImageResource - should take an IModelString instead of String for captcha-text
[ https://issues.apache.org/jira/browse/WICKET-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604677#action_12604677 ] Stefan Simik commented on WICKET-1696: -- Sure ;) thanx I changed the fix version. CaptchaImageResource - should take an IModelString 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 IModelString 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-713) AbstractAjaxBehavior can not be reused.
[ https://issues.apache.org/jira/browse/WICKET-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-1312) Generic inter-component event mechanism
[ https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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] 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 IModelMyCustomObject
{
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] 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-tabpanelfocusedCommentId=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.
[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 RD 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
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=667340view=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=667340r1=667339r2=667340view=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
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=667341view=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=667341r1=667340r2=667341view=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 SetIValidatable validatedComponents = new
HashSetIValidatable();
-
-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
IVisitorFileUploadField()
-{
-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 SetIValidatable validatedComponents = new
HashSetIValidatable();
+
+
