[jira] Commented: (WICKET-1439) DownloadLink cannot support chinese file name.
[ https://issues.apache.org/jira/browse/WICKET-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582124#action_12582124 ] Ding Zhaolei commented on WICKET-1439: -- if we can auto check the File.getFileName() is UTF-8, gb2312, iso8859-1, or something else. we can make Downloadlink more better. > DownloadLink cannot support chinese file name. > -- > > Key: WICKET-1439 > URL: https://issues.apache.org/jira/browse/WICKET-1439 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.2 >Reporter: Ding Zhaolei >Priority: Minor > Fix For: 1.5-M1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1439) DownloadLink cannot support chinese file name.
[
https://issues.apache.org/jira/browse/WICKET-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582122#action_12582122
]
Ding Zhaolei commented on WICKET-1439:
--
if UTF8 everywhere, why i use
fileName = new String(fileName.getBytes("gb2312"), "UTF-8");
and on download dialog box of IE6, it show a wrong filename?
so i think, we must convert fileName to iso8859-1.
> DownloadLink cannot support chinese file name.
> --
>
> Key: WICKET-1439
> URL: https://issues.apache.org/jira/browse/WICKET-1439
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
>Reporter: Ding Zhaolei
>Priority: Minor
> Fix For: 1.5-M1
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1445) StreamCorruptedException/PageStore/Serialization broken because ObjectOutputStream was not flushed
[ https://issues.apache.org/jira/browse/WICKET-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582105#action_12582105 ] David Leangen commented on WICKET-1445: --- I didn't see anything go by regarding the NPE that happens after application of this patch. Has the NPE been fixed, too? > StreamCorruptedException/PageStore/Serialization broken because > ObjectOutputStream was not flushed > -- > > Key: WICKET-1445 > URL: https://issues.apache.org/jira/browse/WICKET-1445 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.1, 1.3.2 >Reporter: Niclas Hedhman >Assignee: Igor Vaynberg > Fix For: 1.3.3 > > Attachments: wicket-close-stream.patch > > > The Objects.objectToByteArray() method incorrectly forgets to flush/close the > ObjectOutputStream it uses. This can create corrupt object streams. -- 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 inside (page edited)
Page Edited : WICKET : Wicket inside Wicket inside has been edited by Sualeh Fatehi (Mar 25, 2008). (View changes) Content: This page and its child pages is an attempt to describe some aspects of how Wicket internals work. It's written for Wicket 1.3 though most things should apply to other versions as well. You can read pages in the following order: Lifecycle of a Wicket Application Request processing overview Request cycle and request cycle processor Request coding strategy Request targets Component hierarchy Pages Page rendering Component rendering Page maps User code context When reading anything of the above it may be also a good idea to look at java docs for described classes and browse Wicket sources. After all these pages are only representation of the real thing, which is the Wicket source code. Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[jira] Issue Comment Edited: (WICKET-1239) java.lang.IllegalAccessError when changing AjaxEditableLabel
[ https://issues.apache.org/jira/browse/WICKET-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582074#action_12582074 ] egulatee edited comment on WICKET-1239 at 3/25/08 3:44 PM: --- This bug is happening on Wicket 1.3.2 running on Tomcat on Mac OS X 10.5.2 (jdk 1.6), full stack trace follows: SEVERE: Servlet.service() for servlet HelloWorldApplication threw exception java.lang.IllegalAccessError: tried to access method org.apache.wicket.Component.onModelChanging()V from class org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$1 at org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$1.onModelChanging(AjaxEditableLabel.java:294) at org.apache.wicket.Component.modelChanging(Component.java:2097) at org.apache.wicket.Component.setModelObject(Component.java:2863) at org.apache.wicket.markup.html.form.FormComponent.updateModel(FormComponent.java:1016) at org.apache.wicket.markup.html.form.FormComponent.processInput(FormComponent.java:898) at org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$EditorAjaxBehavior.respond(AjaxEditableLabel.java:122) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:288) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:100) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:121) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:111) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) Furthermore I extended AjaxEditableLabel and overrode suggested methods. See attached file. was (Author: egulatee): This bug is happening on Wicket 1.3.2 running on Tomcat on Mac OS X 10.5.2 (jdk 1.6), full stack trace follows: SEVERE: Servlet.service() for servlet HelloWorldApplication threw exception java.lang.IllegalAccessError: tried to access method org.apache.wicket.Component.onModelChanging()V from class org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$1 at org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$1.onModelChanging(AjaxEditableLabel.java:294) at org.apache.wicket.Component.modelChanging(Component.java:2097) at org.apache.wicket.Component.setModelObject(Component.java:2863) at org.apache.wicket.markup.html.form.FormComponent.updateModel(FormComponent.java:1016) at org.apache.wicket.markup.html.form.FormComponent.processInput(FormComponent.java:898) at org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$EditorAjaxBehavior.respond(AjaxEditableLabel.java:122) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehav
[jira] Updated: (WICKET-1239) java.lang.IllegalAccessError when changing AjaxEditableLabel
[
https://issues.apache.org/jira/browse/WICKET-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Gulatee updated WICKET-1239:
-
Attachment: code.java
> java.lang.IllegalAccessError when changing AjaxEditableLabel
> -
>
> Key: WICKET-1239
> URL: https://issues.apache.org/jira/browse/WICKET-1239
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 1.3.0-rc2, 1.3.0-final
> Environment: Windows XP Pro SP2, Java 1.6.0_03-b05
>Reporter: Artur Wronski
>Assignee: Gerolf Seitz
> Fix For: 1.3.2
>
> Attachments: code.java
>
>
> When changing AjaxEditableLabel system throws:
> java.lang.IllegalAccessError: tried to access method
> org.apache.wicket.Component.onModelChanging()V from class
> org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$1
> at
> org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$1.onModelChanging
> (AjaxEditableLabel.java:273)
> at org.apache.wicket.Component.modelChanging(Component.java:2058)
> at org.apache.wicket.Component.setModelObject(Component.java:2823)
> at org.apache.wicket.markup.html.form.FormComponent.updateModel(
> FormComponent.java:992)
> at org.apache.wicket.markup.html.form.FormComponent.processInput(
> FormComponent.java:874)
> [...]
> The probem is in methd:
> protected FormComponent newEditor(MarkupContainer parent, String
> componentId, IModel model)
> {
> TextField editor = new TextField(componentId, model)
> {
> private static final long serialVersionUID = 1L;
> protected void onModelChanged()
> {
> super.onModelChanged();
> AjaxEditableLabel.this.onModelChanged();
> //here is a bug
> }
> protected void onModelChanging()
> {
> super.onModelChanging();
> AjaxEditableLabel.this.onModelChanging();
> //here is a bug
> }
> };
> editor.setOutputMarkupId(true);
> editor.setVisible(false);
> editor.add(new EditorAjaxBehavior());
> return editor;
> }
> AjaxEditableLabel.this.XX is not visible.
> Artur
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1239) java.lang.IllegalAccessError when changing AjaxEditableLabel
[
https://issues.apache.org/jira/browse/WICKET-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582074#action_12582074
]
Eric Gulatee commented on WICKET-1239:
--
This bug is happening on Wicket 1.3.2 running on Tomcat on Mac OS X 10.5.2 (jdk
1.6), full stack trace follows:
SEVERE: Servlet.service() for servlet HelloWorldApplication threw exception
java.lang.IllegalAccessError: tried to access method
org.apache.wicket.Component.onModelChanging()V from class
org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$1
at
org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$1.onModelChanging(AjaxEditableLabel.java:294)
at org.apache.wicket.Component.modelChanging(Component.java:2097)
at org.apache.wicket.Component.setModelObject(Component.java:2863)
at
org.apache.wicket.markup.html.form.FormComponent.updateModel(FormComponent.java:1016)
at
org.apache.wicket.markup.html.form.FormComponent.processInput(FormComponent.java:898)
at
org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$EditorAjaxBehavior.respond(AjaxEditableLabel.java:122)
at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:288)
at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:100)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354)
at
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:111)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:637)
Furthermore I extended AjaxEditableLabel an overrode suggested methods:
package da.web.wicket.cart.buyer.panel;
import java.text.SimpleDateFormat;
import java.util.Date;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel;
import
org.apache.wicket.extensions.markup.html.repeater.data.table.PropertyColumn;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.repeater.Item;
import org.apache.wicket.model.IModel;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import da.service.CartManagement;
import wicket.component.model.DatePropertyColumn;
public class EditableQuantityPropertyColumn extends PropertyColumn {
CartManagement cartmanagement;
/**
*
*/
private static final long serialVersionUID = 1L;
static Logger logger =
LoggerFactory.getLogger(DatePropertyColumn.class);
public EditableQuantityPropertyColumn(IModel model, String sortOrder,
String propertyExpression) {
super(model, sortOrder, propertyExpression);
}
public void populateItem(Item item, String componentId, IModel model) {
[jira] Commented: (WICKET-599) Add Development Mode dashboard widget when deployed in development mode
[ https://issues.apache.org/jira/browse/WICKET-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582065#action_12582065 ] Martijn Dashorst commented on WICKET-599: - see also WICKET-670 > Add Development Mode dashboard widget when deployed in development mode > --- > > Key: WICKET-599 > URL: https://issues.apache.org/jira/browse/WICKET-599 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.0-beta1 >Reporter: Martijn Dashorst > Fix For: 1.5-M1 > > Attachments: screenshot-1.jpg > > > It is considered bad practise to deploy your wicket application in > development mode in a production environment. Because several features > beneficial to development will make an application behave less than optimal > when confronted with lots of users and requests. > The idea is to extend the Wicket Ajax Debug link and make it a full fledged > panel that is *always* visible when working in development mode. There will > not be a setting to turn this off. If someone wants to have the development > features available in a production environment, these can be enabled using > the settings object. > Another idea, thanks to Korbinian Bachl is to add the Inspector Bug to this > widget, to enable introspection of the components on the page. > The widget should be movable (so it does not obscure other markup elements), > and it should have a hide link to enable screen shots whilst still in > development mode (very useful when writing articles and books). > A screen shot for this feature can be seen attached to this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-670) Bring back the inspector!
[ https://issues.apache.org/jira/browse/WICKET-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582066#action_12582066 ] Martijn Dashorst commented on WICKET-670: - see also wicket-599 > Bring back the inspector! > - > > Key: WICKET-670 > URL: https://issues.apache.org/jira/browse/WICKET-670 > Project: Wicket > Issue Type: Wish > Components: wicket >Affects Versions: 1.4-M1 >Reporter: Jonathan Locke >Priority: Minor > Fix For: 1.5-M1 > > > My copy of the inspector is completely broken. It's a shame that this useful > tool is not really supported anymore. It gives people a sense of confidence > when they can navigate their wicket session and see all the components with > the inspector. > To bring the inspector back, we could do the following things: > 1. fix the inspector > - it needs to factor out the stack trace metadata so sizes of things are > more accurate > - my inspector causes every page viewed after using it to fail with a page > expired exception (!) > 2. add a security setting setInspectorEnabled() which defaults to false > (disabled) and unless > the inspector is explicitly enabled, the constructor of every publicly > accessible bookmarkable > page in the inspector package throws an IllegalStateException() with an > explanation of what > you must do to safely use the inspector in your application (add security to > the pages via > wicket-auth-roles or some other means and call setInspectorEnabled(true)). > then we can all enjoy the return of the inspector! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-757) FormComponent.rawInput needs a better name
[ https://issues.apache.org/jira/browse/WICKET-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-757: Fix Version/s: (was: 1.4-M1) 1.5-M1 > FormComponent.rawInput needs a better name > -- > > Key: WICKET-757 > URL: https://issues.apache.org/jira/browse/WICKET-757 > Project: Wicket > Issue Type: Wish > Components: wicket >Affects Versions: 1.2.6 >Reporter: Willis Boyce >Priority: Minor > Fix For: 1.5-M1 > > > It took me a while looking through the code to figure out that the "raw" > input isn't really the raw input. The *real* raw input is what comes from > the getInputAsArray method. rawInput seems to be a kind of holding place for > the form-submitted value that, if present, overrides the value in the model, > so that the form can re-display the user's input even if it failed validation > or conversion and therefore cannot be stored in the model. It's really a > tentative or proposed value. > Also, some more comments about what exactly NO_RAW_VALUE indicates would be > helpful. It seems to indicate that the form-submitted value has been cleared > and that getValue should return the value from the model. If you change the > "raw" input to something else, then maybe this can be called USE_MODEL_VALUE > or something like that instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-670) Bring back the inspector!
[ https://issues.apache.org/jira/browse/WICKET-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-670: Fix Version/s: (was: 1.4-M1) 1.5-M1 > Bring back the inspector! > - > > Key: WICKET-670 > URL: https://issues.apache.org/jira/browse/WICKET-670 > Project: Wicket > Issue Type: Wish > Components: wicket >Affects Versions: 1.4-M1 >Reporter: Jonathan Locke >Priority: Minor > Fix For: 1.5-M1 > > > My copy of the inspector is completely broken. It's a shame that this useful > tool is not really supported anymore. It gives people a sense of confidence > when they can navigate their wicket session and see all the components with > the inspector. > To bring the inspector back, we could do the following things: > 1. fix the inspector > - it needs to factor out the stack trace metadata so sizes of things are > more accurate > - my inspector causes every page viewed after using it to fail with a page > expired exception (!) > 2. add a security setting setInspectorEnabled() which defaults to false > (disabled) and unless > the inspector is explicitly enabled, the constructor of every publicly > accessible bookmarkable > page in the inspector package throws an IllegalStateException() with an > explanation of what > you must do to safely use the inspector in your application (add security to > the pages via > wicket-auth-roles or some other means and call setInspectorEnabled(true)). > then we can all enjoy the return of the inspector! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-598) Support jetty continuations in wicket
[ https://issues.apache.org/jira/browse/WICKET-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-598: Fix Version/s: (was: 1.4-M1) 1.5-M1 > Support jetty continuations in wicket > - > > Key: WICKET-598 > URL: https://issues.apache.org/jira/browse/WICKET-598 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Peter Ertl >Assignee: Eelco Hillenius > Fix For: 1.5-M1 > > Attachments: jetty-continuations.patch > > > Using jetty continuations does not work on wicket. > info about jetty continuations: > http://docs.codehaus.org/display/JETTY/Continuations > Calling jetty's >continuation.suspend(timeout); > will fail as it raises an RetryRequest exception that is caught by wicket. > It should be let through instead so jetty server will be able to handle it. > I am no continuations expert but letting through the exception seems to be > enough to make this feature work and have a wonderful push model support > inside wicket :-) > I will attach a patch that fixes the issue... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-599) Add Development Mode dashboard widget when deployed in development mode
[ https://issues.apache.org/jira/browse/WICKET-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-599: Fix Version/s: (was: 1.4-M1) 1.5-M1 > Add Development Mode dashboard widget when deployed in development mode > --- > > Key: WICKET-599 > URL: https://issues.apache.org/jira/browse/WICKET-599 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.0-beta1 >Reporter: Martijn Dashorst > Fix For: 1.5-M1 > > Attachments: screenshot-1.jpg > > > It is considered bad practise to deploy your wicket application in > development mode in a production environment. Because several features > beneficial to development will make an application behave less than optimal > when confronted with lots of users and requests. > The idea is to extend the Wicket Ajax Debug link and make it a full fledged > panel that is *always* visible when working in development mode. There will > not be a setting to turn this off. If someone wants to have the development > features available in a production environment, these can be enabled using > the settings object. > Another idea, thanks to Korbinian Bachl is to add the Inspector Bug to this > widget, to enable introspection of the components on the page. > The widget should be movable (so it does not obscure other markup elements), > and it should have a hide link to enable screen shots whilst still in > development mode (very useful when writing articles and books). > A screen shot for this feature can be seen attached to this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-574) WicketTester does not bind created Session to SessionStore
[ https://issues.apache.org/jira/browse/WICKET-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-574: Fix Version/s: (was: 1.4-M1) 1.5-M1 > WicketTester does not bind created Session to SessionStore > -- > > Key: WICKET-574 > URL: https://issues.apache.org/jira/browse/WICKET-574 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta1 >Reporter: Gerry Lowe >Priority: Minor > Fix For: 1.5-M1 > > > The WicketTester constructor, via a call to > MockWebApplication.createRequestCycle(), creates a new session but fails to > bind it: > this.wicketSession = (WebSession) Session.findOrCreate(); > This means that the session subsequently gets over-written by a new one > created in a later call to WicketTester.startPage(). This causes problems > for any unit tests which want to set up session data after instantiating a > WicketTester, but before calling WicketTester.startPage(). > The MockWebApplication.createRequestCycle() should probably bind the session > immediately after creating it: > this.wicketSession = (WebSession) Session.findOrCreate(); > getApplication().getSessionStore().bind(getWicketRequest(), > wicketSession); > Then subsequent calls to startPage() will use this session rather than create > a new one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-563) Let Application create error pages
[ https://issues.apache.org/jira/browse/WICKET-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-563: Fix Version/s: (was: 1.4-M1) 1.5-M1 > Let Application create error pages > -- > > Key: WICKET-563 > URL: https://issues.apache.org/jira/browse/WICKET-563 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.3.0-beta1 >Reporter: Bart Molenkamp > Fix For: 1.5-M1 > > Attachments: AbstractRequestCycleProcessor.java.patch, > Application.java.patch > > > Improvement to simplify error page creation. Error pages are now created by > the Application, by: > - onAuthorizationException() - for authorization exceptions > - onPageExpiredException() - for pages that are expired > - onRuntimeException() - for any other runtime exception > Whether or not to show the stacktrace in the page is now determined in > Application.onRuntimeException() (based on the getUnexpectedExceptionDisplay > setting). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-363) Push behavior to handle server side events
[ https://issues.apache.org/jira/browse/WICKET-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-363: Fix Version/s: (was: 1.4-M1) 1.5-M1 > Push behavior to handle server side events > -- > > Key: WICKET-363 > URL: https://issues.apache.org/jira/browse/WICKET-363 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.0-beta1 >Reporter: Xavier Hanin > Fix For: 1.5-M1 > > Attachments: push-wicket-examples-patch.txt, push-wicket-patch.txt > > > It would be nice to have some kind of server side push mechanism in wicket. > Something similar to what is possible with AjaxRequestTarget, but triggered > by server side events instead of client side events. > I've already discussed that on the user mailing list: > http://www.nabble.com/server-side-triggered-page-refresh-%28aka-push%29-tf3321420.html#a9234009 > http://www.nabble.com/Pushing-data-to-the-Ajax-client-in-wicket--tf3354017.html > I will attach a patch implementing a basic push behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-96) Mechanism for extensible JS-contributing behaviors
[ https://issues.apache.org/jira/browse/WICKET-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-96: --- Fix Version/s: (was: 1.4-M1) 1.5-M1 > Mechanism for extensible JS-contributing behaviors > -- > > Key: WICKET-96 > URL: https://issues.apache.org/jira/browse/WICKET-96 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-beta4 >Reporter: Gili > Fix For: 1.5-M1 > > > Currently if a behavior contributes javascript code which takes control of a > control's event (i.e. onKeyPressed) there is no way to layer another behavior > on top of it such that if the first behavior does not consume the keypress > then the next behavior can make use of it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-160) Use GWT javascript generation for client side validations
[ https://issues.apache.org/jira/browse/WICKET-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-160: Fix Version/s: (was: 1.4-M1) 1.5-M1 > Use GWT javascript generation for client side validations > - > > Key: WICKET-160 > URL: https://issues.apache.org/jira/browse/WICKET-160 > Project: Wicket > Issue Type: New Feature >Reporter: Martijn Dashorst > Fix For: 1.5-M1 > > > GWT uses java to javascript compilation to generate code that runs inside the > browser. Using the same technology (it is Apache Licensed!) we can > automatically transform the serverside validators to client side. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1206) Change BaseWicketTester.getTagByXXX return value from TagTester to TagTester[]
[ https://issues.apache.org/jira/browse/WICKET-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Bille Jensen updated WICKET-1206: --- Fix Version/s: (was: 1.4-M1) 1.5-M1 > Change BaseWicketTester.getTagByXXX return value from TagTester to TagTester[] > -- > > Key: WICKET-1206 > URL: https://issues.apache.org/jira/browse/WICKET-1206 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 >Reporter: Craig McIlwee >Assignee: Frank Bille Jensen >Priority: Minor > Fix For: 1.5-M1 > > Attachments: MultipleTagTester.java > > > When using the org.apache.wicket.markup.repeater.data.DataView, each row in > the table has the same wicket:id. I am trying to use the TagTester to ensure > that each tag has the correct attributes, in this case class="odd" and > class="even". Since getTagByWicketId and getTagById only return a single > TagTester, a tester for the same markup tag is returned each time, making it > impossible to test any row other than the first. > Example HTML output: > > <- TagTester returned is > always for this tag > > > > > > > > > > > Proposed solution: change the return value to TagTester[] so that one call > will return all of the tags with that wicket:id -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r640984 - /wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
Author: knopp
Date: Tue Mar 25 14:07:13 2008
New Revision: 640984
URL: http://svn.apache.org/viewvc?rev=640984&view=rev
Log:
use convenience wrap method
Modified:
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
Modified:
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java?rev=640984&r1=640983&r2=640984&view=diff
==
---
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
(original)
+++
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
Tue Mar 25 14:07:13 2008
@@ -34,7 +34,6 @@
import org.apache.wicket.markup.html.panel.Panel;
import org.apache.wicket.markup.html.resources.CompressedResourceReference;
import org.apache.wicket.markup.html.resources.JavascriptResourceReference;
-import org.apache.wicket.model.IComponentAssignedModel;
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.Model;
import org.apache.wicket.protocol.http.WebRequest;
@@ -608,9 +607,7 @@
*/
public void setTitle(IModel title)
{
- if (title instanceof IComponentAssignedModel) {
- title =
((IComponentAssignedModel)title).wrapOnAssignment(this);
- }
+ title = wrap(title);
this.title = title;
}
svn commit: r640978 - /wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
Author: knopp
Date: Tue Mar 25 14:01:46 2008
New Revision: 640978
URL: http://svn.apache.org/viewvc?rev=640978&view=rev
Log:
Check for IComponentAssignedModel in #setTitle and detach title model
Modified:
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
Modified:
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java?rev=640978&r1=640977&r2=640978&view=diff
==
---
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
(original)
+++
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
Tue Mar 25 14:01:46 2008
@@ -34,6 +34,7 @@
import org.apache.wicket.markup.html.panel.Panel;
import org.apache.wicket.markup.html.resources.CompressedResourceReference;
import org.apache.wicket.markup.html.resources.JavascriptResourceReference;
+import org.apache.wicket.model.IComponentAssignedModel;
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.Model;
import org.apache.wicket.protocol.http.WebRequest;
@@ -607,6 +608,9 @@
*/
public void setTitle(IModel title)
{
+ if (title instanceof IComponentAssignedModel) {
+ title =
((IComponentAssignedModel)title).wrapOnAssignment(this);
+ }
this.title = title;
}
@@ -1034,4 +1038,12 @@
private PageCreator pageCreator = null;
private CloseButtonCallback closeButtonCallback = null;
private WindowClosedCallback windowClosedCallback = null;
+
+ protected void onDetach()
+ {
+ super.onDetach();
+ if (this.title != null) {
+ this.title.detach();
+ }
+ }
}
[jira] Created: (WICKET-1450) Ajax Re-render does not work after AbstractRestartResponseException()
Ajax Re-render does not work after AbstractRestartResponseException()
-
Key: WICKET-1450
URL: https://issues.apache.org/jira/browse/WICKET-1450
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Environment: Windows XP Java 1.6.0_05-b13
Reporter: Matthew Young
To handle possible exception in Model#getObject(): I do
1) make note of exception has occurred (and subsequently only return some error
value and not cause exception thrown again),
2) register an error feedback message,
3) calll page.detach() (for clean up and reset?, I'm not sure but I know this
makes FeedbackPanelErrorMessage reload message from session) and
4) throw new AbstractRestartResponseException() to re-render response with the
new error message from the model shown.
I'm finding that this works perfectly in non-Ajax. But in Ajax, there are 2
problems:
1) the error message register in step 2) above is not rendered in the
FeedbackPanel
2) the Ajax response is incomplete, it's missing the label component in my test
case and missing the closing tag.
Test case below: if you enter "blowup" in the text field, the label's model
will do the steps outline above. Run this in non-Ajax and you will see two
error messages as expected. Run in Ajax, you will see the problem (open Wicket
Ajax Debug panel to see).
= = = = HomePage.html:
message will be here
FEEDBACK
= = = = = HomePage.java:
public class HomePage extends WebPage {
private static final long serialVersionUID = 1L;
private String word;
public HomePage(final PageParameters parameters) {
add(new FeedbackPanel("feedback") {
private static final long serialVersionUID = 1L;
@Override protected void onBeforeRender() {
System.out.println("= = = = FeedbackPanel
onBeforeRender()");
System.out.println(" FeedbackbackMessageModel =
" + getFeedbackMessagesModel().getObject());
super.onBeforeRender();
}
}.setOutputMarkupPlaceholderTag(true));
// if the word "blowup" is entered,
//this register a error message and throw
IModel model = new Model() {
private static final long serialVersionUID = 1L;
@Override public Object getObject() {
if (word != null && word.equals("blowup")) {
word = "-w-e-b-l-e-w-u-p-";
HomePage.this.fatal("[2/2]This message
is from Model.");
getPage().detach();
System.out.println("! ! ! ! ! throwing
new AbstractRestartResponseException()");
throw new
AbstractRestartResponseException() {
private static final long
serialVersionUID = 1L;
};
} else {
return "The word is: \"" + (word ==
null ? " n u l l " : word) + "\"";
}
}
};
add(new Label("message", model) {
private static final long serialVersionUID = 1L;
@Override protected void onBeforeRender() {
System.out.println("= = = = Label onBeforeRender(),
model = " + getModel().getObject());
super.onBeforeRender();
}
}.setOutputMarkupId(true));
Form form = new Form("form", new CompoundPropertyModel(this));
add(form);
form.add(new TextField("word").setRequired(true));
AjaxFallbackButton submitButton = new
AjaxFallbackButton("submitButton", form) {
private static final long serialVersionUID = 1L;
@Override protected void onSubmit(AjaxRequestTarget target,
Form f) {
if (word != null && word.equals("blowup")) {
HomePage.this.error("[1/2]This message is from
onSubmit. There should also be a message from model");
}
if (target != null) {
target.addComponent(HomePage.this.get("feedback"));
// clear error feedback if any
target.addComponent(HomePage.this.get("message"));
}
}
@Override protected void onError(AjaxRequestTarget target, Form
f) {
target.addComponent(HomePage.this.get("feedback"));
// show updated error feedback
}
};
form.add(submitButto
[jira] Resolved: (WICKET-1448) SubmitLink bypass jquery submit eventhandler
[
https://issues.apache.org/jira/browse/WICKET-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-1448.
---
Resolution: Won't Fix
Fix Version/s: 1.3.3
Assignee: Igor Vaynberg
i dont know how jquery hooks into the event, but we are already doing
everything possible from our side. submitlink properly calls form.onsubmit() if
there is one, and properly treats its return value. call to form.onsubmit() is
followed by form.submit(). i am not sure what exactly more we can be doing on
our side. if you have a patch i am all ears.
> if:
>
> response.renderOnDomReadyJavascript("document.getElementById('"+component.getMarkupId()+"').onsubmit
> = function(){alert('x');return false;}");
> the alert will show and the form is not submmitted
that is correct behavior because you return false from onsubmit() the form is
not submitted. if you return true you will see the alert and the form will be
submitted.
> SubmitLink bypass jquery submit eventhandler
>
>
> Key: WICKET-1448
> URL: https://issues.apache.org/jira/browse/WICKET-1448
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
>Reporter: xiefei
>Assignee: Igor Vaynberg
> Fix For: 1.3.3
>
>
> submit
> if:
>
> response.renderOnDomReadyJavascript("jQuery('#"+component.getMarkupId()+"').submit(function(){alert('x');return
> false;})");
> the alert will not show when submitLink is clicked, and the form is submitted
> if:
>
> response.renderOnDomReadyJavascript("document.getElementById('"+component.getMarkupId()+"').onsubmit
> = function(){alert('x');return false;}");
> the alert will show and the form is not submmitted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581978#action_12581978
]
Will Hoover commented on WICKET-1449:
-
Well, judging by the number of people that have posted the question on the
forum (I counted 3 including myself) I would hardly say that it is JUST me.
Besides, we all know that not everyone that experiences the problem will report
the issue ;o)
Any application that has an out-of the-box functionality that completely breaks
the application in a commonly used browser seems like a critical issue to me,
but from this point on I will only use priority of Major and below... Sorry for
placing this issue in Critical priority status :o)
> './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
> --
>
> Key: WICKET-1449
> URL: https://issues.apache.org/jira/browse/WICKET-1449
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Wicket 1.3.2
> JBoss 4.0/Jetty 6.1.7
> JDK 1.6.0_03
>Reporter: Will Hoover
>Assignee: Alastair Maw
> Fix For: 1.3.3
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> SYNOPSIS:
> 1) Web application is using the root context ("/")
> 1) form.add(new Button("mybutton"));
> 2) Button is clicked on any WebPage that is NOT MOUNTED
> ISSUE:
> WebRequestCodingStrategy.encode appends './' to the URL. The page is
> redirected to "http://www.mysite.com/./"; It works fine in Firefox and Opera,
> but in IE an HTTP 404 ('.' page is not found) is rendered.
> Mounting the home page to something like '/home' solved the problem ('./' is
> not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581976#action_12581976
]
Martijn Dashorst commented on WICKET-1449:
--
when you are the only one to notice this as a bug, then it is not critical.
Critical means nobody can work with a product or a security issue. Anything
else has less priority.
> './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
> --
>
> Key: WICKET-1449
> URL: https://issues.apache.org/jira/browse/WICKET-1449
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Wicket 1.3.2
> JBoss 4.0/Jetty 6.1.7
> JDK 1.6.0_03
>Reporter: Will Hoover
>Assignee: Alastair Maw
> Fix For: 1.3.3
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> SYNOPSIS:
> 1) Web application is using the root context ("/")
> 1) form.add(new Button("mybutton"));
> 2) Button is clicked on any WebPage that is NOT MOUNTED
> ISSUE:
> WebRequestCodingStrategy.encode appends './' to the URL. The page is
> redirected to "http://www.mysite.com/./"; It works fine in Firefox and Opera,
> but in IE an HTTP 404 ('.' page is not found) is rendered.
> Mounting the home page to something like '/home' solved the problem ('./' is
> not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581975#action_12581975
]
Will Hoover commented on WICKET-1449:
-
Also... Isn't an "absolute blocker" supposed to use "Blocker" priority not
"Critical"? ;o)
> './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
> --
>
> Key: WICKET-1449
> URL: https://issues.apache.org/jira/browse/WICKET-1449
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Wicket 1.3.2
> JBoss 4.0/Jetty 6.1.7
> JDK 1.6.0_03
>Reporter: Will Hoover
>Assignee: Alastair Maw
> Fix For: 1.3.3
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> SYNOPSIS:
> 1) Web application is using the root context ("/")
> 1) form.add(new Button("mybutton"));
> 2) Button is clicked on any WebPage that is NOT MOUNTED
> ISSUE:
> WebRequestCodingStrategy.encode appends './' to the URL. The page is
> redirected to "http://www.mysite.com/./"; It works fine in Firefox and Opera,
> but in IE an HTTP 404 ('.' page is not found) is rendered.
> Mounting the home page to something like '/home' solved the problem ('./' is
> not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581973#action_12581973
]
Will Hoover commented on WICKET-1449:
-
Default behavior that causes a malfunction in the whole application seems like
a good candidate for an "absolute blocker" :o)
> './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
> --
>
> Key: WICKET-1449
> URL: https://issues.apache.org/jira/browse/WICKET-1449
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Wicket 1.3.2
> JBoss 4.0/Jetty 6.1.7
> JDK 1.6.0_03
>Reporter: Will Hoover
>Assignee: Alastair Maw
> Fix For: 1.3.3
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> SYNOPSIS:
> 1) Web application is using the root context ("/")
> 1) form.add(new Button("mybutton"));
> 2) Button is clicked on any WebPage that is NOT MOUNTED
> ISSUE:
> WebRequestCodingStrategy.encode appends './' to the URL. The page is
> redirected to "http://www.mysite.com/./"; It works fine in Firefox and Opera,
> but in IE an HTTP 404 ('.' page is not found) is rendered.
> Mounting the home page to something like '/home' solved the problem ('./' is
> not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: Best Practices and Gotchas (page edited)
Page Edited :
WICKET :
Best Practices and Gotchas
Best Practices and Gotchas
has been edited by Alex Jacoby
(Mar 25, 2008).
Change summary:
Added advice on debugging NotSerializableException
(View changes)
Content:
This page will contain the accumulated thoughts on what the wicket best practices are. It will also list situations that cause erroneus behaviours and are hard to track down.
Table of contents
Best Practices
Html Template Declaration
Wicket Servlet Mapping
Wicket 1.1.x & 1.2.x
Wicket 1.3.x
More info
Anonymous Inner classes
Debugging NotSerializableException
Gotchas
Empty URL Parameter in CSS Style ( background-image: url(""); )
BODY:onLoad in Panel not added without wicket:head
Adding wicket:head to a Page
Starting download after form submission (Wicket 1.1)
Starting download after form submission (Wicket 1.2)
Starting download after form submission (Wicket 2.0)
PackageResources and relative paths
PBEWithMD5AndDES not found
Adding id attribute to a tag
Avoid using open-close tags (i.e. )
More Potential IssuesInternalCloningError — Potential Serialization Issue
Best Practices
Html Template Declaration
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
"http://www.w3.org/1999/xhtml"
xmlns:wicket="http://wicket.apache.org/"
xml:lang="en"
lang="en">
Wicket Servlet Mapping
Wicket 1.1.x & 1.2.x
It is best to map the servlet as /app/* instead of /*. The /app/* mapping allows static resources to be handled by the webserver as opposed to the wicket servlet.
You may experience difficulties with form POSTs if you map to /*. For example, if a GET request on a Wicket form produces a URL like http://www.examplehost.com/examplecontext/?wicket:interface=wicket-0:2:3, you will find that Wicket writes an action="" attribute to the | element. Because of the missing / before the ?, the container may not recognise the resulting POST as a request for the Wicket servlet. This behaviour has been observed with:
Jetty 6
mod_jk when mounted to accept requests for a subdirectory beneath the root web directory (i.e. "JkMount /* exampleworker" works but not "JkMount /examplesubdirectory/* exampleworker")
Wicket 1.3.x
To avoid this issue with Wicket 1.3, the recommandation has been changed to use a ServletFilter rather than a servlet - See the Migrate-1.3 page for details of the changes required.
More info
(Thanks, Igor)
Usually static resources are handled by the application server. The server knows it is serving a file and thus sets the last modified date of the resource to the last modified date of a file.
So, for example, let's say you have /myapp/images/foo.gif and you map your wicket servlet to /*
What happens is that when a request comes in for /myapp/images/foo.gif it will match the wicket servlet - so now it is wicket servlet's job to serve this file to the browser. now we are nice enough to provide support for this - but obviously we cannot do as good a job as the application server which has a lot more context.
So for 1.1 & 1.2, we recommend mapping the servlet to something like /app/* so that foo.gif will be processed by the application server and only wicket-specific requests are processed by the servlet.
For 1.3 and onward, what we do is instead of using a servlet, use a filter.
The advantage of a filter is that, unlike a servlet, it can choose not to process the request and let whatever is next in chain try. So when using a wicket filter and a request comes in for foo.gif the filter can choose not to process it because it knows it is not a wicket-related request. Since the filter didnt process it, it falls on to the application server to try, and then it works.
Anonymous Inner classes
Don't do this:
class MyPage extends WebPage {
private MyVeryLargeObject subject;
//
public MyPage() {
// get my very large object from database
subject = MyVeryLargeObjectDao.get();
// ...
form.add(new TextField("name", new PropertyModel(MyPage.this, "some.very.large.navigational.structure.name"));
}
}
The 'subject' instance of the MyVeryLargeObjectDao class will be serialized into the session with each page version. This can get out of hand, because with some business object models, the attached object can become very large. For this we introduced DetachableModels, which will retrieve the data from the database when needed, and will clean up when the data is not needed (at the end of the request for instance).
The other thing to avoid is anonymous or nested instances of IModel. Usually you share an instance of a model between two page instances. If you create an anonymous or nested instance of IModel, then you automatically ge
[jira] Updated: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst updated WICKET-1449:
-
Priority: Major (was: Critical)
USE CRITICAL ONLY FOR ABSOLUTE BLOCKERS!
> './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
> --
>
> Key: WICKET-1449
> URL: https://issues.apache.org/jira/browse/WICKET-1449
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Wicket 1.3.2
> JBoss 4.0/Jetty 6.1.7
> JDK 1.6.0_03
>Reporter: Will Hoover
>Assignee: Alastair Maw
> Fix For: 1.3.3
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> SYNOPSIS:
> 1) Web application is using the root context ("/")
> 1) form.add(new Button("mybutton"));
> 2) Button is clicked on any WebPage that is NOT MOUNTED
> ISSUE:
> WebRequestCodingStrategy.encode appends './' to the URL. The page is
> redirected to "http://www.mysite.com/./"; It works fine in Firefox and Opera,
> but in IE an HTTP 404 ('.' page is not found) is rendered.
> Mounting the home page to something like '/home' solved the problem ('./' is
> not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner updated WICKET-1449:
Fix Version/s: 1.3.3
> './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
> --
>
> Key: WICKET-1449
> URL: https://issues.apache.org/jira/browse/WICKET-1449
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Wicket 1.3.2
> JBoss 4.0/Jetty 6.1.7
> JDK 1.6.0_03
>Reporter: Will Hoover
>Assignee: Alastair Maw
>Priority: Critical
> Fix For: 1.3.3
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> SYNOPSIS:
> 1) Web application is using the root context ("/")
> 1) form.add(new Button("mybutton"));
> 2) Button is clicked on any WebPage that is NOT MOUNTED
> ISSUE:
> WebRequestCodingStrategy.encode appends './' to the URL. The page is
> redirected to "http://www.mysite.com/./"; It works fine in Firefox and Opera,
> but in IE an HTTP 404 ('.' page is not found) is rendered.
> Mounting the home page to something like '/home' solved the problem ('./' is
> not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner reassigned WICKET-1449:
---
Assignee: Alastair Maw
> './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
> --
>
> Key: WICKET-1449
> URL: https://issues.apache.org/jira/browse/WICKET-1449
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Wicket 1.3.2
> JBoss 4.0/Jetty 6.1.7
> JDK 1.6.0_03
>Reporter: Will Hoover
>Assignee: Alastair Maw
>Priority: Critical
> Fix For: 1.3.3
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> SYNOPSIS:
> 1) Web application is using the root context ("/")
> 1) form.add(new Button("mybutton"));
> 2) Button is clicked on any WebPage that is NOT MOUNTED
> ISSUE:
> WebRequestCodingStrategy.encode appends './' to the URL. The page is
> redirected to "http://www.mysite.com/./"; It works fine in Firefox and Opera,
> but in IE an HTTP 404 ('.' page is not found) is rendered.
> Mounting the home page to something like '/home' solved the problem ('./' is
> not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
'./' appended to URL causes HTTP 404 in Internet Explorer (using root context)
--
Key: WICKET-1449
URL: https://issues.apache.org/jira/browse/WICKET-1449
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Environment: Wicket 1.3.2
JBoss 4.0/Jetty 6.1.7
JDK 1.6.0_03
Reporter: Will Hoover
Priority: Critical
SYNOPSIS:
1) Web application is using the root context ("/")
1) form.add(new Button("mybutton"));
2) Button is clicked on any WebPage that is NOT MOUNTED
ISSUE:
WebRequestCodingStrategy.encode appends './' to the URL. The page is redirected
to "http://www.mysite.com/./"; It works fine in Firefox and Opera, but in IE an
HTTP 404 ('.' page is not found) is rendered.
Mounting the home page to something like '/home' solved the problem ('./' is
not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1448) SubmitLink bypass jquery submit eventhandler
[
https://issues.apache.org/jira/browse/WICKET-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiefei updated WICKET-1448:
---
Description:
submit
if:
response.renderOnDomReadyJavascript("jQuery('#"+component.getMarkupId()+"').submit(function(){alert('x');return
false;})");
the alert will not show when submitLink is clicked, and the form is submitted
if:
response.renderOnDomReadyJavascript("document.getElementById('"+component.getMarkupId()+"').onsubmit
= function(){alert('x');return false;}");
the alert will show and the form is not submmitted
was:
submit
if:
response.renderOnDomReadyJavascript("jQuery('"+component.getMarkupId()+"').submit(function(){alert('x');return
false;})");
the alert will not show when submitLink is clicked, and the form is submitted
if:
response.renderOnDomReadyJavascript("document.getElementById('"+component.getMarkupId()+"').onsubmit
= function(){alert('x');return false;}");
the alert will show and the form is not submmitted
> SubmitLink bypass jquery submit eventhandler
>
>
> Key: WICKET-1448
> URL: https://issues.apache.org/jira/browse/WICKET-1448
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
>Reporter: xiefei
>
> submit
> if:
>
> response.renderOnDomReadyJavascript("jQuery('#"+component.getMarkupId()+"').submit(function(){alert('x');return
> false;})");
> the alert will not show when submitLink is clicked, and the form is submitted
> if:
>
> response.renderOnDomReadyJavascript("document.getElementById('"+component.getMarkupId()+"').onsubmit
> = function(){alert('x');return false;}");
> the alert will show and the form is not submmitted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1448) SubmitLink bypass jquery submit eventhandler
SubmitLink bypass jquery submit eventhandler
Key: WICKET-1448
URL: https://issues.apache.org/jira/browse/WICKET-1448
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Reporter: xiefei
submit
if:
response.renderOnDomReadyJavascript("jQuery('"+component.getMarkupId()+"').submit(function(){alert('x');return
false;})");
the alert will not show when submitLink is clicked, and the form is submitted
if:
response.renderOnDomReadyJavascript("document.getElementById('"+component.getMarkupId()+"').onsubmit
= function(){alert('x');return false;}");
the alert will show and the form is not submmitted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1446) Lazy registration in SharedResourceRequestTarget fails
[ https://issues.apache.org/jira/browse/WICKET-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-1446. --- Resolution: Fixed Assignee: Johan Compagner i fixed this issue but created a new one WICKET-1447 because i think not all problems are fixed and we need to make the api of SharedResources a bet better. because a get() and an add() with both a String argument that are not the same thing is confusing. > Lazy registration in SharedResourceRequestTarget fails > -- > > Key: WICKET-1446 > URL: https://issues.apache.org/jira/browse/WICKET-1446 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.2 >Reporter: Tony Vegas >Assignee: Johan Compagner > Fix For: 1.3.3 > > > The lazy registration of shared resources which are not of scope > org.apache.wicket.Application fails. > It fails because registers SharedResourceRequestTarget the resource with > sharedResources.add(resourceKey, packageResource); > but should use > sharedResources.add(scope, path,null,null, packageResource); > The problem is that add(final String name, final Resource resource) expects a > name for the resource and not the complete resource key. > As consequence the resource is registered again and again with scope > org.apache.wicket.Application. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1447) Lazy registration in SharedResourceRequestTarget: check if locale/style works and better api: SharedResources.get() -> SharedResource.getByResourceKey()/putByResourceKey?
Lazy registration in SharedResourceRequestTarget: check if locale/style works and better api: SharedResources.get() -> SharedResource.getByResourceKey()/putByResourceKey? -- Key: WICKET-1447 URL: https://issues.apache.org/jira/browse/WICKET-1447 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.2 Reporter: Johan Compagner Assignee: Johan Compagner Fix For: 1.4-M1 see also WICKET-1446 Lazy registration can still be wrong for the wrong resources if the path contains style and locale information.. Also the API of SharedREsources is a bit confusing, you have add(name,Resource) and get(key) where name and key are really different things i think we should look if we rename get(key) to getByResourceKey and then also add a putByResourceKey that can then be used if needed by SharedResourceRequestTarget. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r640771 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/resource/SharedResourceRequestTarget.java
Author: jcompagner
Date: Tue Mar 25 04:19:33 2008
New Revision: 640771
URL: http://svn.apache.org/viewvc?rev=640771&view=rev
Log:
fix for WICKET-1446 Lazy registration in SharedResourceRequestTarget fails
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/resource/SharedResourceRequestTarget.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/resource/SharedResourceRequestTarget.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/resource/SharedResourceRequestTarget.java?rev=640771&r1=640770&r2=640771&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/resource/SharedResourceRequestTarget.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/resource/SharedResourceRequestTarget.java
Tue Mar 25 04:19:33 2008
@@ -61,7 +61,7 @@
else if (requestParameters.getResourceKey() == null)
{
throw new
IllegalArgumentException("requestParameters.getResourceKey() "
- + "may not be null");
+ + "may not be null");
}
}
@@ -81,7 +81,7 @@
{
SharedResourceRequestTarget that =
(SharedResourceRequestTarget)obj;
return getRequestParameters().getResourceKey().equals(
-
that.getRequestParameters().getResourceKey());
+ that.getRequestParameters().getResourceKey());
}
return false;
}
@@ -150,7 +150,7 @@
PackageResource packageResource =
PackageResource.get(scope, path);
if (sharedResources.get(resourceKey) ==
null)
{
-
sharedResources.add(resourceKey, packageResource);
+ sharedResources.add(scope,
path, null, null, packageResource);
}
resource = packageResource;
}
@@ -170,7 +170,7 @@
if (response instanceof WebResponse)
{
((WebResponse)response).getHttpServletResponse().setStatus(
-
HttpServletResponse.SC_NOT_FOUND);
+ HttpServletResponse.SC_NOT_FOUND);
log.error("shared resource " + resourceKey + "
not found");
return;
}
@@ -196,6 +196,6 @@
public String toString()
{
return "[SharedResourceRequestTarget@" + hashCode() + ",
resourceKey=" +
- getRequestParameters().getResourceKey() + "]";
+ getRequestParameters().getResourceKey() + "]";
}
}
[jira] Created: (WICKET-1446) Lazy registration in SharedResourceRequestTarget fails
Lazy registration in SharedResourceRequestTarget fails -- Key: WICKET-1446 URL: https://issues.apache.org/jira/browse/WICKET-1446 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.2 Reporter: Tony Vegas Fix For: 1.3.3 The lazy registration of shared resources which are not of scope org.apache.wicket.Application fails. It fails because registers SharedResourceRequestTarget the resource with sharedResources.add(resourceKey, packageResource); but should use sharedResources.add(scope, path,null,null, packageResource); The problem is that add(final String name, final Resource resource) expects a name for the resource and not the complete resource key. As consequence the resource is registered again and again with scope org.apache.wicket.Application. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1439) DownloadLink cannot support chinese file name.
[ https://issues.apache.org/jira/browse/WICKET-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581858#action_12581858 ] Johan Compagner commented on WICKET-1439: - i am more interested in which one goes wrong (a unit test or something) because we should try to use UTF8 everywhere and then chinese shouldnt be a problem. > DownloadLink cannot support chinese file name. > -- > > Key: WICKET-1439 > URL: https://issues.apache.org/jira/browse/WICKET-1439 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.2 >Reporter: Ding Zhaolei >Priority: Minor > Fix For: 1.5-M1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1439) DownloadLink cannot support chinese file name.
[
https://issues.apache.org/jira/browse/WICKET-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581853#action_12581853
]
Ding Zhaolei commented on WICKET-1439:
--
i use as:
String fileName = file.getName();
try {
fileName = new String(fileName.getBytes("gb2312"),
"iso8859-1");
} catch (UnsupportedEncodingException ex) {
Logger.getLogger(ArchivesUploadForm.class.getName()).log(Level.SEVERE, null,
ex);
}
item.add(downloadLink = new DownloadLink("file", file,
fileName));
and it is ok.
> DownloadLink cannot support chinese file name.
> --
>
> Key: WICKET-1439
> URL: https://issues.apache.org/jira/browse/WICKET-1439
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
>Reporter: Ding Zhaolei
>Priority: Minor
> Fix For: 1.5-M1
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1445) StreamCorruptedException/PageStore/Serialization broken because ObjectOutputStream was not flushed
[
https://issues.apache.org/jira/browse/WICKET-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581840#action_12581840
]
Johan Compagner commented on WICKET-1445:
-
not really, we dont rape to much (if you dont look at the Wicket In and
OutputStreams :) )
That one is just one extra delegate so that we can exactly say what object and
what field is going wrong, because that is really lacking in OOS.
Maybe the construct isnt that nice instead of this:
final ObjectOutputStream oos = new ObjectOutputStream(out);
return new ObjectOutputStream()
{
protected void writeObjectOverride(final Object
obj) throws IOException
{
it should be this
return new ObjectOutputStream()
{
final ObjectOutputStream oos = new
ObjectOutputStream(out);
protected void writeObjectOverride(final Object
obj) throws IOException
Then it is much more clear that we just wrap 1 in another and then you also see
that we really need to flush and close the inner one because that is our state.
{
> StreamCorruptedException/PageStore/Serialization broken because
> ObjectOutputStream was not flushed
> --
>
> Key: WICKET-1445
> URL: https://issues.apache.org/jira/browse/WICKET-1445
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.1, 1.3.2
>Reporter: Niclas Hedhman
>Assignee: Igor Vaynberg
> Fix For: 1.3.3
>
> Attachments: wicket-close-stream.patch
>
>
> The Objects.objectToByteArray() method incorrectly forgets to flush/close the
> ObjectOutputStream it uses. This can create corrupt object streams.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1445) StreamCorruptedException/PageStore/Serialization broken because ObjectOutputStream was not flushed
[ https://issues.apache.org/jira/browse/WICKET-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581838#action_12581838 ] Niclas Hedhman commented on WICKET-1445: But honestly, you guys are raping the intention of the serialization system... > StreamCorruptedException/PageStore/Serialization broken because > ObjectOutputStream was not flushed > -- > > Key: WICKET-1445 > URL: https://issues.apache.org/jira/browse/WICKET-1445 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.1, 1.3.2 >Reporter: Niclas Hedhman >Assignee: Igor Vaynberg > Fix For: 1.3.3 > > Attachments: wicket-close-stream.patch > > > The Objects.objectToByteArray() method incorrectly forgets to flush/close the > ObjectOutputStream it uses. This can create corrupt object streams. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r640743 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
Author: jcompagner
Date: Tue Mar 25 01:44:37 2008
New Revision: 640743
URL: http://svn.apache.org/viewvc?rev=640743&view=rev
Log:
super.flush/close shouldnt be done, an overridden OOS has no internal state at
all.
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java?rev=640743&r1=640742&r2=640743&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
Tue Mar 25 01:44:37 2008
@@ -139,13 +139,11 @@
public void flush() throws IOException
{
oos.flush();
- super.flush();
}
public void close() throws IOException
{
oos.close();
- super.close();
}
};
}
svn commit: r640742 - in /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util: io/IObjectStreamFactory.java lang/Objects.java
Author: jcompagner
Date: Tue Mar 25 01:39:12 2008
New Revision: 640742
URL: http://svn.apache.org/viewvc?rev=640742&view=rev
Log:
also close the read (byteToObject) so that the OIS can clean itself.
also according to doc the writeObjectOverride is expected to be final
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/lang/Objects.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java?rev=640742&r1=640741&r2=640742&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
Tue Mar 25 01:39:12 2008
@@ -110,7 +110,7 @@
final ObjectOutputStream oos = new
ObjectOutputStream(out);
return new ObjectOutputStream()
{
- protected void writeObjectOverride(final Object
obj) throws IOException
+ protected final void writeObjectOverride(final
Object obj) throws IOException
{
try
{
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/lang/Objects.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/lang/Objects.java?rev=640742&r1=640741&r2=640742&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/lang/Objects.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/lang/Objects.java
Tue Mar 25 01:39:12 2008
@@ -386,12 +386,18 @@
try
{
final ByteArrayInputStream in = new
ByteArrayInputStream(data);
+ ObjectInputStream ois = null;
try
{
- return
objectStreamFactory.newObjectInputStream(in).readObject();
+ ois =
objectStreamFactory.newObjectInputStream(in);
+ return ois.readObject();
}
finally
{
+ if (ois != null)
+ {
+ ois.close();
+ }
in.close();
}
}
svn commit: r640740 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
Author: jcompagner
Date: Tue Mar 25 01:31:42 2008
New Revision: 640740
URL: http://svn.apache.org/viewvc?rev=640740&view=rev
Log:
extra methods for delegating flush and close to the actual stream.
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java?rev=640740&r1=640739&r2=640740&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/io/IObjectStreamFactory.java
Tue Mar 25 01:31:42 2008
@@ -135,6 +135,18 @@
throw e;
}
}
+
+ public void flush() throws IOException
+ {
+ oos.flush();
+ super.flush();
+ }
+
+ public void close() throws IOException
+ {
+ oos.close();
+ super.close();
+ }
};
}
}
[jira] Commented: (WICKET-1445) StreamCorruptedException/PageStore/Serialization broken because ObjectOutputStream was not flushed
[ https://issues.apache.org/jira/browse/WICKET-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581830#action_12581830 ] Johan Compagner commented on WICKET-1445: - thats for our SerializableChecker so that people gets a nice result where it exactly goes wrong And i guess you mean why make a new ObjectOutputStream and then another one to do that? That has to be only a default constructor call sets the enableOverride = true; to the right value else you cant have the writeObjectOverride method.. i will fix this by adding 2 more methods, flush and close that will delegate also.. > StreamCorruptedException/PageStore/Serialization broken because > ObjectOutputStream was not flushed > -- > > Key: WICKET-1445 > URL: https://issues.apache.org/jira/browse/WICKET-1445 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.1, 1.3.2 >Reporter: Niclas Hedhman >Assignee: Igor Vaynberg > Fix For: 1.3.3 > > Attachments: wicket-close-stream.patch > > > The Objects.objectToByteArray() method incorrectly forgets to flush/close the > ObjectOutputStream it uses. This can create corrupt object streams. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1445) StreamCorruptedException/PageStore/Serialization broken because ObjectOutputStream was not flushed
[
https://issues.apache.org/jira/browse/WICKET-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581823#action_12581823
]
Niclas Hedhman commented on WICKET-1445:
Actually, not quite that fast...
IObjectStreamFactory has the weirdest construct
What on earth's name is this for? And the close() of the patch above will now
instead be a NPE.
I think Eelco need to explain himself.
public ObjectOutputStream newObjectOutputStream(final OutputStream out) throws
IOException
{
final ObjectOutputStream oos = new ObjectOutputStream(out);
return new ObjectOutputStream()
{
protected void writeObjectOverride(final Object obj) throws IOException
{
try
{
oos.writeObject(obj);
}
catch (IOException e)
{
if (SerializableChecker.isAvailable())
{
// trigger serialization again, but this time gather
// some more info
new
SerializableChecker((NotSerializableException)e).writeObject(obj);
// if we get here, we didn't fail, while we
// should;
throw e;
}
throw e;
}
catch (RuntimeException e)
{
log.error("error writing object " + obj + ": " +
e.getMessage(), e);
throw e;
}
}
};
}
> StreamCorruptedException/PageStore/Serialization broken because
> ObjectOutputStream was not flushed
> --
>
> Key: WICKET-1445
> URL: https://issues.apache.org/jira/browse/WICKET-1445
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.1, 1.3.2
>Reporter: Niclas Hedhman
>Assignee: Igor Vaynberg
> Fix For: 1.3.3
>
> Attachments: wicket-close-stream.patch
>
>
> The Objects.objectToByteArray() method incorrectly forgets to flush/close the
> ObjectOutputStream it uses. This can create corrupt object streams.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1403) Reinjection fails after Server restart
[
https://issues.apache.org/jira/browse/WICKET-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581817#action_12581817
]
uwe schaefer commented on WICKET-1403:
--
This is not at all specific to Resin. I chose resin because i know how to
enable persistent sessions there.
You can take a fresh downloaded tomcat 6.0.16, deploy the war there and see the
exact same behavior (seems persistent sessions are enabled by default with
tomcat 6.0.16)
It would be a tremendous step forward, if we could use persistent sessions in
development (for turnaround time).
> Reinjection fails after Server restart
> --
>
> Key: WICKET-1403
> URL: https://issues.apache.org/jira/browse/WICKET-1403
> Project: Wicket
> Issue Type: Bug
> Components: wicket-guice
>Affects Versions: 1.3.1
> Environment: Resin 3.1.5 with persistent pagestore
>Reporter: uwe schaefer
>Assignee: Alastair Maw
>Priority: Minor
> Attachments: example.zip
>
>
> Please see attached testcase.
> Steps to reproduce:
> * start it with mvn resin:run, go to http://localhost:8080/example
> * click a few times
> * stop & restart
> * reload the page (everything fine here (means reload obviously succeeds)
> * click again, you´ll face
> {code}
> Caused by: java.lang.NullPointerException: type
> at com.google.inject.util.Objects.nonNull(Objects.java:35)
> at com.google.inject.TypeLiteral.(TypeLiteral.java:69)
> at
> com.google.inject.TypeLiteral$SimpleTypeLiteral.(TypeLiteral.java:181)
> at com.google.inject.TypeLiteral.get(TypeLiteral.java:169)
> at
> org.apache.wicket.guice.GuiceProxyTargetLocator.locateProxyTarget(GuiceProxyTargetLocator.java:61)
> at
> org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler.invoke(LazyInitProxyFactory.java:412)
> at org.apache.wicket.proxy.$Proxy13.foo(Unknown Source)
> at org.codesmell.HomePage$1.onClick(HomePage.java:25)
> at org.apache.wicket.markup.html.link.Link.onLinkClicked(Link.java:214)
> ... 21 more
> {code}
> GuiceProxyTargetLocator does not seem to be coded to cope with this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1445) StreamCorruptedException/PageStore/Serialization broken because ObjectOutputStream was not flushed
[ https://issues.apache.org/jira/browse/WICKET-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-1445: -- Summary: StreamCorruptedException/PageStore/Serialization broken because ObjectOutputStream was not flushed (was: PageStore/Serialization broken because ObjectOutputStream was not flushed) > StreamCorruptedException/PageStore/Serialization broken because > ObjectOutputStream was not flushed > -- > > Key: WICKET-1445 > URL: https://issues.apache.org/jira/browse/WICKET-1445 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.1, 1.3.2 >Reporter: Niclas Hedhman >Assignee: Igor Vaynberg > Fix For: 1.3.3 > > Attachments: wicket-close-stream.patch > > > The Objects.objectToByteArray() method incorrectly forgets to flush/close the > ObjectOutputStream it uses. This can create corrupt object streams. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
