date:20100828

Author: ivaynberg
Date: Sat Aug 28 05:59:26 2010
New Revision: 990320

URL: http://svn.apache.org/viewvc?rev=990320view=rev
Log:

Issue: WICKET-2793

Modified:

wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/request/target/coding/AbstractRequestTargetUrlCodingStrategy.java

Modified: 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/request/target/coding/AbstractRequestTargetUrlCodingStrategy.java
URL: 
http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/request/target/coding/AbstractRequestTargetUrlCodingStrategy.java?rev=990320r1=990319r2=990320view=diff
==
--- 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/request/target/coding/AbstractRequestTargetUrlCodingStrategy.java
 (original)
+++ 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/request/target/coding/AbstractRequestTargetUrlCodingStrategy.java
 Sat Aug 28 05:59:26 2010
@@ -119,7 +119,7 @@ public abstract class AbstractRequestTar
{
url.append(/);
}
-   url.append(key).append(/).append(escapedValue);
+   
url.append(urlEncodePathComponent(key)).append(/).append(escapedValue);
}
}
 
@@ -168,7 +168,7 @@ public abstract class AbstractRequestTar
{
String value = pairs[i + 1];
value = urlDecodePathComponent(value);
-   parameters.add(pairs[i], value);
+   parameters.add(urlDecodePathComponent(pairs[i]), value);
}

[jira] Resolved: (WICKET-2793) Incorrect decode parameters in AbstractRequestTargetUrlCodingStrategy#decodeParameters


 [ 
https://issues.apache.org/jira/browse/WICKET-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2793.
---

 Assignee: Igor Vaynberg
Fix Version/s: 1.4.11
   Resolution: Fixed

 Incorrect decode parameters in 
 AbstractRequestTargetUrlCodingStrategy#decodeParameters
 --

 Key: WICKET-2793
 URL: https://issues.apache.org/jira/browse/WICKET-2793
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7
 Environment: Java 1.5, Tomcat 5.5
Reporter: Igor Azarny
Assignee: Igor Vaynberg
 Fix For: 1.4.11

   Original Estimate: 24h
  Remaining Estimate: 24h

 In case of  utf-8 url (see example below) created ValueMap in 
 AbstractRequestTargetUrlCodingStrategy#decodeParameters is incorrect. 
 Each key-value pair contains not decoded key and decoded value.
 Proposed fix - line no 171 in 
 AbstractRequestTargetUrlCodingStrategy#decodeParameters
 parameters.add(pairs[i], value);
 shall be 
 parameters.add(urlDecodePathComponent(pairs[i]), value);
  
 Changes locally tested on 1.4.7 version - no failed test.  But I am not sure 
 is AbstractRequestTargetUrlCodingStrategy covered by test cases.
 And works correctly on tomcat.
 URL in browser
 http://jewelry.npa.com:8080/ws/shop/category/Браслеты/Колір_металу/Белый/Вставка/Бриллиант/Розмір/19.5/brand/Enigma/Проба/750/Матеріал/Золото/price/USD-31-60/Колір_вставки/Белый
 URL in Tomcat
 http://jewelry.npa.com:8080/ws/shop/category/%D0%91%D1%80%D0%B0%D1%81%D0%BB%D0%B5%D1%82%D1%8B/%D0%9A%D0%BE%D0%BB%D1%96%D1%80_%D0%BC%D0%B5%D1%82%D0%B0%D0%BB%D1%83/%D0%91%D0%B5%D0%BB%D1%8B%D0%B9/%D0%92%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0/%D0%91%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D0%B0%D0%BD%D1%82/%D0%A0%D0%BE%D0%B7%D0%BC%D1%96%D1%80/19.5/brand/Enigma/%D0%9F%D1%80%D0%BE%D0%B1%D0%B0/750/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D1%96%D0%B0%D0%BB/%D0%97%D0%BE%D0%BB%D0%BE%D1%82%D0%BE/price/USD-31-60/%D0%9A%D0%BE%D0%BB%D1%96%D1%80_%D0%B2%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B8/%D0%91%D0%B5%D0%BB%D1%8B%D0%B9

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WICKET-2502) WicketTester cannot handle consecutive RestartResponseException's


 [ 
https://issues.apache.org/jira/browse/WICKET-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2502.
---

  Assignee: Martin Grigorov
Resolution: Fixed

 WicketTester cannot handle consecutive RestartResponseException's
 -

 Key: WICKET-2502
 URL: https://issues.apache.org/jira/browse/WICKET-2502
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4-RC7
Reporter: Martin Makundi
Assignee: Martin Grigorov
Priority: Minor
 Attachments: Wicket-Quickstart.zip

   Original Estimate: 5h
  Remaining Estimate: 5h

 See attached quickstart junit test. WicketTester crashes (seizes from 
 running the tests) if there eare consecutive RestartResponseException's.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WICKET-2400) WicketTester does not work with AjaxSubmitLink


 [ 
https://issues.apache.org/jira/browse/WICKET-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2400.
---

  Assignee: Martin Grigorov
Resolution: Fixed

 WicketTester does not work with AjaxSubmitLink
 --

 Key: WICKET-2400
 URL: https://issues.apache.org/jira/browse/WICKET-2400
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4-RC7
Reporter: Martin Makundi
Assignee: Martin Grigorov
Priority: Minor
 Attachments: Wicket-Quickstart.zip

   Original Estimate: 5h
  Remaining Estimate: 5h

 AjaxSubmitLink does not work in 1.4-rc7
 See attached quickstart with unit test.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WICKET-2355) setGatherExtendedBrowserInfo doesn't work with Ajax


 [ 
https://issues.apache.org/jira/browse/WICKET-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2355.
---

  Assignee: Igor Vaynberg
Resolution: Incomplete

 setGatherExtendedBrowserInfo doesn't work with Ajax
 ---

 Key: WICKET-2355
 URL: https://issues.apache.org/jira/browse/WICKET-2355
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4-RC4
Reporter: Joseph Pachod
Assignee: Igor Vaynberg

 As said there : 
 http://www.nabble.com/Odd-behaviour-after-setGatherExtendedBrowserInfo(true)-td15457880.html#a15464392
  setGatherExtendedBrowserInfo doesn't play well with Ajax. = I'm as well 
 affected by this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WICKET-2962) Pages under Wicket projects are empty


 [ 
https://issues.apache.org/jira/browse/WICKET-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2962.
---

  Assignee: Martijn Dashorst
Resolution: Incomplete

 Pages under Wicket projects are empty
 -

 Key: WICKET-2962
 URL: https://issues.apache.org/jira/browse/WICKET-2962
 Project: Wicket
  Issue Type: Bug
  Components: site
Affects Versions: 1.4.9
 Environment: Firefox 3.6.7
 Ubuntu Linux 10
Reporter: Jens Rydholm
Assignee: Martijn Dashorst

 Various pages linked from the following URL are empty (except for the 
 heading) since the site update for the Wicket 1.4.9 release announcement:
 http://wicket.apache.org/learn/projects/
 The only exception is the Velocity page, which still works:
 http://wicket.apache.org/learn/projects/velocity.html
 The Auth/Roles page is completely missing instead of just empty:
 http://wicket.apache.org/learn/projects/authoroles.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WICKET-1739) Request.getPath() doesn't honor its contract for MockHttpServletRequest


 [ 
https://issues.apache.org/jira/browse/WICKET-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-1739.
---

  Assignee: Martin Grigorov
Resolution: Cannot Reproduce

seems  MockHttpServletRequest.getRequestURI() in latest also checks for query 
string and trims it

 Request.getPath() doesn't honor its contract for MockHttpServletRequest
 ---

 Key: WICKET-1739
 URL: https://issues.apache.org/jira/browse/WICKET-1739
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.4
 Environment: Linux, Jetty 6.1.x
Reporter: Martin Grigorov
Assignee: Martin Grigorov

 With SVN r655308 MockWebApplication.processRequestCycle(Class, 
 PageParameters) has been refactored and now each call to this method with 
 non-home page's class as parameter calls getServletRequest().setURL(path + 
 url); at line 452 (wicket 1.3.4). After this invocation all subsequent calls 
 with this stack trace :
 Thread [main] (Suspended) 
   MockHttpServletRequest.getRequestURI() line: 793
   MockWebApplication$1(WicketFilter).getRelativePath(HttpServletRequest) 
 line: 452
   ServletWebRequest.getPath() line: 144   
   WebRequestCodingStrategy.getRequestPath(Request) line: 988  
   WebRequestCodingStrategy.decode(Request) line: 196  
   ServletWebRequest(Request).getRequestParameters() line: 171 
   MyPage(Page).init() line: 1167  
... 
 returns not just the path but the query string is appended too (e.g. 
 /mount/path?someParam=value) and later on 
 o.a.w.request/target/coding/AbstractRequestTargetUrlCodingStrategy#matches(String)
  returns false (because there is query string at the end) and thus it could 
 not resolve the request target.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WICKET-3011) strange context shutdown issue on jetty 7


 [ 
https://issues.apache.org/jira/browse/WICKET-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-3011.
---

  Assignee: Peter Ertl
Resolution: Won't Fix

closing pending response from the jetty team

 strange context shutdown issue on jetty 7
 -

 Key: WICKET-3011
 URL: https://issues.apache.org/jira/browse/WICKET-3011
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Reporter: Peter Ertl
Assignee: Peter Ertl

 when using jetty 7, creating at least one http session and then shutting down 
 the web app context of the wicket web application the following happens:
 - (1) jetty destroys the wicket filter by calling 
 javax.servlet.Filter#destroy()
 - (2) the thread local mapping   application key --- application   will be 
 purged
 - (3) jetty calls 
 org.apache.wicket.session.SessionBindingListener.valueUnbound for the 
 expiring session:
 --code--
   public void valueUnbound(final HttpSessionBindingEvent evt)
   {
   if (log.isDebugEnabled())
   {
   log.debug(Session unbound:  + sessionId);
   }
 ///
 // THE APPLICATION WILL BE NULL SINCE THE WICKET FILTER 
 // ALREADY REMOVED IT FROM THE THREAD LOCAL
 ///
   Application application = 
 Application.get(applicationKey);
   
   if (application == null)
   {
 ///
 /// YOU WILL SEE THE MESSAGE BELOW
 ///
   log.error(Wicket application with name ' + 
 applicationKey + ' not found.);
   return;
   }
 ///
 /// NO LISTENERS WILL BE INVOKED
 ///
   ISessionStore sessionStore = 
 application.getSessionStore();
   if (sessionStore != null)
   {
   for (UnboundListener listener : 
 sessionStore.getUnboundListener())
   {
   listener.sessionUnbound(sessionId);
   }
   }
   }
 --code--
 Can somebody confirm the order jetty executes the handlers is right / wrong?
 In case it's wrong we should file a ticket at jetty.
 In case it's right we should fix that issue in wicket.
 Not fixing this incorrect behavior will mean the session unbound listeners 
 will not be called reliably.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (WICKET-2864) FileUpload and Wizard

2010-08-28 Thread Martin Hubert (JIRA)


 [ 
https://issues.apache.org/jira/browse/WICKET-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Hubert reopened WICKET-2864:
---


Sorry, still not working. 
I will attach my full test project. 


 FileUpload and Wizard
 -

 Key: WICKET-2864
 URL: https://issues.apache.org/jira/browse/WICKET-2864
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 1.4.8
 Environment: ubuntu10.4 / jdk1.6.0_20 / tomcat-6.0.20 / Eclipse 3.5.2
Reporter: Martin Hubert
Assignee: Igor Vaynberg

 FileUploadField is always null if not in last WizardStep. 
 public TestWizard() {
 ...
   model.add(new StepFu());
   model.add(new StepTxt());
 ...
 }
 works, but for 
 public TestWizard() {
 ...
   model.add(new StepTxt());
   model.add(new StepFu());
 ...
 }
 the FileUpload ist always null. 
 ===
 import java.io.Serializable;
 import org.apache.wicket.extensions.wizard.Wizard;
 import org.apache.wicket.extensions.wizard.WizardModel;
 import org.apache.wicket.extensions.wizard.WizardStep;
 import org.apache.wicket.markup.html.form.TextField;
 import org.apache.wicket.markup.html.form.upload.FileUpload;
 import org.apache.wicket.markup.html.form.upload.FileUploadField;
 import org.apache.wicket.model.CompoundPropertyModel;
 public class TestWizard extends Wizard {
   private static final long serialVersionUID = 1L;
   public TestWizard(String id) {
   super(id);
   TestBean bean = new TestBean();
   setDefaultModel(new CompoundPropertyModelTestBean(bean));
   WizardModel model = new WizardModel();
   model.add(new StepFu());
   model.add(new StepTxt());
   init(model);
   getForm().setMultiPart(true);
   }
   public class TestBean implements Serializable {
   private static final long serialVersionUID = 1L;
   private String _text1;
   private FileUpload _fu;
   public String getText1() {
   return _text1;
   }
   public void setText1(String text1) {
   _text1 = text1;
   }
   public FileUpload getFu() {
   return _fu;
   }
   public void setFu(FileUpload fu) {
   _fu = fu;
   }
   }
   
   private final class StepTxt extends WizardStep {
   private static final long serialVersionUID = 1L;
   public StepTxt() {
   add(new TextFieldString(text1));
   }
   }
   
   private final class StepFu extends WizardStep {
   private static final long serialVersionUID = 1L;
   public StepFu() {
   add(new FileUploadField(fu));
   }
   }
   
   @Override
   public void onFinish() {
   TestBean bean = (TestBean) getDefaultModelObject();
   
 System.out.println(***);
   System.out.println(text1:  + bean.getText1());
   System.out.println(fu: + bean.getFu());
   
 System.out.println(***);
   setResponsePage(getApplication().getHomePage());
   }
 }
 ===
 Tested with wicket-1.4.7 and wicket-1.4.8

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-2864) FileUpload and Wizard

2010-08-28 Thread Martin Hubert (JIRA)


 [ 
https://issues.apache.org/jira/browse/WICKET-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Hubert updated WICKET-2864:
--

Attachment: WicketWizardTest.tgz

I use the wicket-1.4 snapshot from yesterday (28 Aug)



 FileUpload and Wizard
 -

 Key: WICKET-2864
 URL: https://issues.apache.org/jira/browse/WICKET-2864
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 1.4.8
 Environment: ubuntu10.4 / jdk1.6.0_20 / tomcat-6.0.20 / Eclipse 3.5.2
Reporter: Martin Hubert
Assignee: Igor Vaynberg
 Attachments: WicketWizardTest.tgz


 FileUploadField is always null if not in last WizardStep. 
 public TestWizard() {
 ...
   model.add(new StepFu());
   model.add(new StepTxt());
 ...
 }
 works, but for 
 public TestWizard() {
 ...
   model.add(new StepTxt());
   model.add(new StepFu());
 ...
 }
 the FileUpload ist always null. 
 ===
 import java.io.Serializable;
 import org.apache.wicket.extensions.wizard.Wizard;
 import org.apache.wicket.extensions.wizard.WizardModel;
 import org.apache.wicket.extensions.wizard.WizardStep;
 import org.apache.wicket.markup.html.form.TextField;
 import org.apache.wicket.markup.html.form.upload.FileUpload;
 import org.apache.wicket.markup.html.form.upload.FileUploadField;
 import org.apache.wicket.model.CompoundPropertyModel;
 public class TestWizard extends Wizard {
   private static final long serialVersionUID = 1L;
   public TestWizard(String id) {
   super(id);
   TestBean bean = new TestBean();
   setDefaultModel(new CompoundPropertyModelTestBean(bean));
   WizardModel model = new WizardModel();
   model.add(new StepFu());
   model.add(new StepTxt());
   init(model);
   getForm().setMultiPart(true);
   }
   public class TestBean implements Serializable {
   private static final long serialVersionUID = 1L;
   private String _text1;
   private FileUpload _fu;
   public String getText1() {
   return _text1;
   }
   public void setText1(String text1) {
   _text1 = text1;
   }
   public FileUpload getFu() {
   return _fu;
   }
   public void setFu(FileUpload fu) {
   _fu = fu;
   }
   }
   
   private final class StepTxt extends WizardStep {
   private static final long serialVersionUID = 1L;
   public StepTxt() {
   add(new TextFieldString(text1));
   }
   }
   
   private final class StepFu extends WizardStep {
   private static final long serialVersionUID = 1L;
   public StepFu() {
   add(new FileUploadField(fu));
   }
   }
   
   @Override
   public void onFinish() {
   TestBean bean = (TestBean) getDefaultModelObject();
   
 System.out.println(***);
   System.out.println(text1:  + bean.getText1());
   System.out.println(fu: + bean.getFu());
   
 System.out.println(***);
   setResponsePage(getApplication().getHomePage());
   }
 }
 ===
 Tested with wicket-1.4.7 and wicket-1.4.8

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3021) Add timestamp part to resource filenames for better caching


 [ 
https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ertl updated WICKET-3021:
---

Description: 
Even though we have 
getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this still 
is far from perfect. It will add a query parameter to resource filenames so 
caches should invalidate when the parameter changes. However if caching is very 
aggressive altering the query param might not be enough. Then there will be 
stale resources left in the cache of the browser or some intermediate proxy. 
Users will complain and you have to tell them to press F5, clear the cache, or 
whatever :-(

So I decided to implement support for adding the timestamp of the resource as 
part of the filename.

When you have a resource link like

  link rel=stylesheet type=text/css 
href=wicket/resource/my.great.app.HomePage/css/style.css/

a timestamp (the last modified timestamp of the file) will be injected into the 
base name of the file

  link rel=stylesheet type=text/css 
href=wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css/

the format is

  [path-component]* / [base-filename] -ts [timestamp-in-milliseconds] 
(.extension)

The prefix -ts (TS = timestamp) is to avoid naming conflicts with filenames 
that already got with a numeric part before the extension.

Locales, style and variations are taken into consideration (e.g. style.css, 
style_de.css, style_en.css)

When running your test cases the MockApplication which WicketTester provides in 
the default case has timestamps disabled so you can check you rendered markup 
against some predictable url.

You can control and check timestamp behavior with

  getResourceSettings().setUseTimestampOnResources()

and 

  getResourceSettings().getUseTimestampOnResources()

Default behavior is 'enabled'

You should now be able to configure your resources caching to 'infinity' which 
will give you best network performance and utilization of proxies.



  was:
Even though we have 
getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this still 
is far from perfect. It will add a query parameter to resource filenames so 
caches should invalidate when the parameter changes. However if caching is very 
aggressive altering the query param might not be enough. Then there will be 
stale resources left in the cache of the browser or some intermediate proxy. 
Users will complain and you have to tell them to press F5, clear the cache, or 
whatever :-(

So I decided to implement support for adding the timestamp of the resource as 
part of the filename.

When you have a resource link like

  link rel=stylesheet type=text/css 
href=wicket/resource/my.great.app.HomePage/css/style.css/

a timestamp (the last modified timestamp of the file) will be injected into the 
base name of the url

  link rel=stylesheet type=text/css 
href=wicket/resource/my.great.app.HomePage/css/style.css-ts1282376261000.css/

the format is

  [path-component]* / [base-filename] -ts [timestamp-in-milliseconds] 
(.extension)

The prefix -ts (TS = timestamp) is to avoid naming conflicts with filenames 
that already got with a numeric part before the extension.

Locales, style and variations are taken into consideration (e.g. style.css, 
style_de.css, style_en.css)

When running your test cases the MockApplication which WicketTester provides in 
the default case has timestamps disabled so you can check you rendered markup 
against some predictable url.

You can control and check timestamp behavior with

  getResourceSettings().setUseTimestampOnResources()

and 

  getResourceSettings().getUseTimestampOnResources()

Default behavior is 'enabled'

You should now be able to configure your resources caching to 'infinity' which 
will give you best network performance and utilization of proxies.




 Add timestamp part to resource filenames for better caching
 ---

 Key: WICKET-3021
 URL: https://issues.apache.org/jira/browse/WICKET-3021
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.5-M1
Reporter: Peter Ertl
 Attachments: timestamp-for-resources.patch


 Even though we have 
 getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this 
 still is far from perfect. It will add a query parameter to resource 
 filenames so caches should invalidate when the parameter changes. However if 
 caching is very aggressive altering the query param might not be enough. Then 
 there will be stale resources left in the cache of the browser or some 
 intermediate proxy. Users will complain and you have to tell them to press 
 F5, clear the cache, or whatever :-(
 So I decided to implement support for adding the timestamp of the resource as 
 part of the filename.
 When you have a resource link like

[jira] Updated: (WICKET-3021) Add timestamp part to resource filenames for better caching


 [ 
https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ertl updated WICKET-3021:
---

Description: 
Even though we have 
getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this still 
is far from perfect. It will add a query parameter to resource filenames so 
caches should invalidate when the parameter changes. However if caching is very 
aggressive altering the query param might not be enough. Then there will be 
stale resources left in the cache of the browser or some intermediate proxy. 
Users will complain and you have to tell them to press F5, clear the cache, or 
whatever :-(

So I decided to implement support for adding the timestamp of the resource as 
part of the filename.

When you have a resource link like

  link rel=stylesheet type=text/css 
href=wicket/resource/my.great.app.HomePage/css/style.css/

a timestamp (the last modified timestamp of the file) will be injected into the 
base name of the file

  link rel=stylesheet type=text/css 
href=wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css/

the format is

  [path-component]* / [base-filename] -ts [timestamp-in-milliseconds] 
(.extension)

The prefix -ts (TS = timestamp) is to avoid naming conflicts with filenames 
that already got with a numeric part before the extension.

Locales, style and variations are taken into consideration (e.g. style.css, 
style_de.css, style_en.css)

When running your test cases the MockApplication which WicketTester provides in 
the default case has timestamps disabled so you can check you rendered markup 
against some predictable url.

You can control and check timestamp behavior with

  getResourceSettings().setUseTimestampOnResources()

and 

  getResourceSettings().getUseTimestampOnResources()

Default behavior is 'enabled'

You are now able to configure your resource caching for a very large lifetime 
(say 'infinite' :-) and get the best possible network performance and 
utilization of proxies.

  was:
Even though we have 
getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this still 
is far from perfect. It will add a query parameter to resource filenames so 
caches should invalidate when the parameter changes. However if caching is very 
aggressive altering the query param might not be enough. Then there will be 
stale resources left in the cache of the browser or some intermediate proxy. 
Users will complain and you have to tell them to press F5, clear the cache, or 
whatever :-(

So I decided to implement support for adding the timestamp of the resource as 
part of the filename.

When you have a resource link like

  link rel=stylesheet type=text/css 
href=wicket/resource/my.great.app.HomePage/css/style.css/

a timestamp (the last modified timestamp of the file) will be injected into the 
base name of the file

  link rel=stylesheet type=text/css 
href=wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css/

the format is

  [path-component]* / [base-filename] -ts [timestamp-in-milliseconds] 
(.extension)

The prefix -ts (TS = timestamp) is to avoid naming conflicts with filenames 
that already got with a numeric part before the extension.

Locales, style and variations are taken into consideration (e.g. style.css, 
style_de.css, style_en.css)

When running your test cases the MockApplication which WicketTester provides in 
the default case has timestamps disabled so you can check you rendered markup 
against some predictable url.

You can control and check timestamp behavior with

  getResourceSettings().setUseTimestampOnResources()

and 

  getResourceSettings().getUseTimestampOnResources()

Default behavior is 'enabled'

You should now be able to configure your resources caching to 'infinity' which 
will give you best network performance and utilization of proxies.




 Add timestamp part to resource filenames for better caching
 ---

 Key: WICKET-3021
 URL: https://issues.apache.org/jira/browse/WICKET-3021
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.5-M1
Reporter: Peter Ertl
 Attachments: timestamp-for-resources.patch


 Even though we have 
 getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this 
 still is far from perfect. It will add a query parameter to resource 
 filenames so caches should invalidate when the parameter changes. However if 
 caching is very aggressive altering the query param might not be enough. Then 
 there will be stale resources left in the cache of the browser or some 
 intermediate proxy. Users will complain and you have to tell them to press 
 F5, clear the cache, or whatever :-(
 So I decided to implement support for adding the timestamp of the resource as 
 part of the filename.
 When you have a

[jira] Commented: (WICKET-2777) HybridUrlCodingStrategy incorrectly decodes url parameters on redirect


[ 
https://issues.apache.org/jira/browse/WICKET-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903798#action_12903798
 ] 

Peter Ertl commented on WICKET-2777:


Please: 

- attach a quickstart
- check this behavior against the current version of wicket (it might be fixed 
already)

 HybridUrlCodingStrategy incorrectly decodes url parameters on redirect
 --

 Key: WICKET-2777
 URL: https://issues.apache.org/jira/browse/WICKET-2777
 Project: Wicket
  Issue Type: Bug
Affects Versions: 1.4.6, 1.4.7
Reporter: Pointbreak

 When using HybridUrlCodingStrategy and encoded parameters the following 
 happens:
 - In some cases HybridUrlCodingStrategy does a page-redirect to get an 
 explicit version nr (i.e. http://localhost/page gets redirected to 
 http://localhost/page.5).
 - However the redirect URL is not the same before the version nr as the 
 original URL, part of the URL path gets urldecoded, resulting in 
 page-parameters that are different from the ones in the original link.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-2987) WicketTester sets parameter map value of String, but Request returns String[] and causes ClassCastException

2010-08-28 Thread Jeremy Thomerson (JIRA)

[
https://issues.apache.org/jira/browse/WICKET-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903810#action_12903810
]

Jeremy Thomerson commented on WICKET-2987:
--

I'm planning on it. I was trying to get the client to create the quickstart.
I've been away from the office at training classes for two weeks, so I filed
this so that it wouldn't fall through the cracks. During that time, I was
encouraging them to create a quickstart for it. Either I'll do it or I'll
close it, but you don't need to worry about this one.

WicketTester sets parameter map value of String, but Request returns String[]
and causes ClassCastException
---

Key: WICKET-2987
URL: https://issues.apache.org/jira/browse/WICKET-2987
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.10, 1.5-M1
Reporter: Jeremy Thomerson
Assignee: Igor Vaynberg
Priority: Minor

This was sent to me from a client, and after a quick look, appears to be
valid:
Jeremy,

When FormTester is used and you add a component to it, the logic in
FormTester adds the component name and value into the MockHttpServletRequest
(which will be a String as the key and a String as a value). My issue with
this is that later, we have a RequestCodingStrategy which gets the
parameterMap from the Request which its typed as String, String[]. When we
iterate over this, we get a classcast exception when the String (From the
form) is attempted to be converted into a String[]. I think something needs
to improved in the Wicket Request object hierarchy to ensure this can't
happen. For now I have just changed my logic in the RequestCodingStrategy to
check for the String[] type.

--
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-2987) WicketTester sets parameter map value of String, but Request returns String[] and causes ClassCastException

2010-08-28 Thread Jeremy Thomerson (JIRA)

[
https://issues.apache.org/jira/browse/WICKET-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903810#action_12903810
]

Jeremy Thomerson edited comment on WICKET-2987 at 8/28/10 6:12 AM:
---

was (Author: jthomerson):
I'm planning on it. I was trying to get the client to create the
quickstart. I've been away from the office at training classes for two weeks,
so I filed this so that it wouldn't fall through the cracks. During that time,
I was encouraging them to create a quickstart for it. Either I'll do it or
I'll close it, but you don't need to worry about this one.

WicketTester sets parameter map value of String, but Request returns String[]
and causes ClassCastException
---

This was sent to me from a client, and after a quick look, appears to be
valid:
Jeremy,

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3024) HttpsRequestChecker inadvertently instantiates page when checking for annotation


 [ 
https://issues.apache.org/jira/browse/WICKET-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ertl updated WICKET-3024:
---

Attachment: https.patch

 HttpsRequestChecker inadvertently instantiates page when checking for 
 annotation
 

 Key: WICKET-3024
 URL: https://issues.apache.org/jira/browse/WICKET-3024
 Project: Wicket
  Issue Type: Bug
Reporter: Peter Ertl
 Attachments: https.patch


 when checking for https the page class unnecessarily instantiated which will 
 cause premature execution of the page constructor. In my case I threw a 
 redirect which was not handled properly. So this issue not only a matter on 
 efficiency but also erroneous.
 patch follows in a sec.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (WICKET-3024) HttpsRequestChecker inadvertently instantiates page when checking for annotation

HttpsRequestChecker inadvertently instantiates page when checking for annotation


 Key: WICKET-3024
 URL: https://issues.apache.org/jira/browse/WICKET-3024
 Project: Wicket
  Issue Type: Bug
Reporter: Peter Ertl
 Attachments: https.patch

when checking for https the page class unnecessarily instantiated which will 
cause premature execution of the page constructor. In my case I threw a 
redirect which was not handled properly. So this issue not only a matter on 
efficiency but also erroneous.

patch follows in a sec.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-3021) Add timestamp part to resource filenames for better caching

2010-08-28 Thread Alexandru Objelean (JIRA)


[ 
https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903820#action_12903820
 ] 

Alexandru Objelean commented on WICKET-3021:


Maybe a better approach would be to use a digest value (using MD5, CRC32 or 
anything else) instead of timestamp. This would ensure that the resources are 
not cached even when the application is deployed on multiple machines.

 Add timestamp part to resource filenames for better caching
 ---

 Key: WICKET-3021
 URL: https://issues.apache.org/jira/browse/WICKET-3021
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.5-M1
Reporter: Peter Ertl
 Attachments: timestamp-for-resources.patch


 Even though we have 
 getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this 
 still is far from perfect. It will add a query parameter to resource 
 filenames so caches should invalidate when the parameter changes. However if 
 caching is very aggressive altering the query param might not be enough. Then 
 there will be stale resources left in the cache of the browser or some 
 intermediate proxy. Users will complain and you have to tell them to press 
 F5, clear the cache, or whatever :-(
 So I decided to implement support for adding the timestamp of the resource as 
 part of the filename.
 When you have a resource link like
   link rel=stylesheet type=text/css 
 href=wicket/resource/my.great.app.HomePage/css/style.css/
 a timestamp (the last modified timestamp of the file) will be injected into 
 the base name of the file
   link rel=stylesheet type=text/css 
 href=wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css/
 the format is
   [path-component]* / [base-filename] -ts [timestamp-in-milliseconds] 
 (.extension)
 The prefix -ts (TS = timestamp) is to avoid naming conflicts with filenames 
 that already got with a numeric part before the extension.
 Locales, style and variations are taken into consideration (e.g. style.css, 
 style_de.css, style_en.css)
 When running your test cases the MockApplication which WicketTester provides 
 in the default case has timestamps disabled so you can check you rendered 
 markup against some predictable url.
 You can control and check timestamp behavior with
   getResourceSettings().setUseTimestampOnResources()
 and 
   getResourceSettings().getUseTimestampOnResources()
 Default behavior is 'enabled'
 You are now able to configure your resource caching for a very large lifetime 
 (say 'infinite' :-) and get the best possible network performance and 
 utilization of proxies.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-3021) Add timestamp part to resource filenames for better caching

[
https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903825#action_12903825
]

Peter Ertl commented on WICKET-3021:

I would consider this an alternate approach. Using MAC's sounds like a good
idea either. It is not that hard to add some kind of IResourceVersionProvider
once we get an basic version running errors-free.

However keep in mind that creating hashes is more expensive then getting the
last modified date of a file. So some kind of caching would be appropriate.
Even for the timestamps caching would eventually make sense. I consider this a
second step.

The timestamp that gets delivered from wicket resources comes straight out off
the jar file *afaik*. It should be the time of the file in the file system when
it was packaged. So the timestamp should be the equal when running the same jar
file on multiple cluster nodes.

Even in case the timestamps were different it would not matter. The whole
purpose of timestamps is not to be unique. They just have to change when the
files contents change. This will cause your browser to not look up the cache
for the resource.In fact it looks like a different resource as the file name is
different. The web application does not care about the timestamp but always
deliver the most current one (which is included in the jar).

Not hitting the cache when touching resources is all we want.

Conceptionally things will be the same when running an exploded jar. In that
case the timestamps are taken from the files in the file system.

Add timestamp part to resource filenames for better caching
---

Key: WICKET-3021
URL: https://issues.apache.org/jira/browse/WICKET-3021
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.5-M1
Reporter: Peter Ertl
Attachments: timestamp-for-resources.patch

Even though we have
getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this
still is far from perfect. It will add a query parameter to resource
filenames so caches should invalidate when the parameter changes. However if
caching is very aggressive altering the query param might not be enough. Then
there will be stale resources left in the cache of the browser or some
intermediate proxy. Users will complain and you have to tell them to press
F5, clear the cache, or whatever :-(
So I decided to implement support for adding the timestamp of the resource as
part of the filename.
When you have a resource link like
link rel=stylesheet type=text/css
href=wicket/resource/my.great.app.HomePage/css/style.css/
a timestamp (the last modified timestamp of the file) will be injected into
the base name of the file
link rel=stylesheet type=text/css
href=wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css/
the format is
[path-component]* / [base-filename] -ts [timestamp-in-milliseconds]
(.extension)
The prefix -ts (TS = timestamp) is to avoid naming conflicts with filenames
that already got with a numeric part before the extension.
Locales, style and variations are taken into consideration (e.g. style.css,
style_de.css, style_en.css)
When running your test cases the MockApplication which WicketTester provides
in the default case has timestamps disabled so you can check you rendered
markup against some predictable url.
You can control and check timestamp behavior with
getResourceSettings().setUseTimestampOnResources()
and
getResourceSettings().getUseTimestampOnResources()
Default behavior is 'enabled'
You are now able to configure your resource caching for a very large lifetime
(say 'infinite' :-) and get the best possible network performance and
utilization of proxies.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (WICKET-2987) WicketTester sets parameter map value of String, but Request returns String[] and causes ClassCastException


 [ 
https://issues.apache.org/jira/browse/WICKET-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg reopened WICKET-2987:
---

  Assignee: Jeremy Thomerson  (was: Igor Vaynberg)

 WicketTester sets parameter map value of String, but Request returns String[] 
 and causes ClassCastException
 ---

 Key: WICKET-2987
 URL: https://issues.apache.org/jira/browse/WICKET-2987
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.10, 1.5-M1
Reporter: Jeremy Thomerson
Assignee: Jeremy Thomerson
Priority: Minor

 This was sent to me from a client, and after a quick look, appears to be 
 valid:
 Jeremy,
  
 When FormTester is used and you add a component to it, the logic in 
 FormTester adds the component name and value into the MockHttpServletRequest 
 (which will be a String as the key and a String as a value). My issue with 
 this is that later, we have a RequestCodingStrategy which gets the 
 parameterMap from the Request which its typed as String, String[]. When we 
 iterate over this, we get a classcast exception when the String (From the 
 form) is attempted to be converted into a String[].  I think something needs 
 to improved in the Wicket Request object hierarchy to ensure this can't 
 happen. For now I have just changed my logic in the RequestCodingStrategy to 
 check for the String[] type.
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-2987) Investigate WicketTester sets parameter map value of String, but Request returns String[] and causes ClassCastException


 [ 
https://issues.apache.org/jira/browse/WICKET-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-2987:
--

Comment: was deleted

(was: whoops, wrong resolution)

 Investigate WicketTester sets parameter map value of String, but Request 
 returns String[] and causes ClassCastException
 ---

 Key: WICKET-2987
 URL: https://issues.apache.org/jira/browse/WICKET-2987
 Project: Wicket
  Issue Type: Task
  Components: wicket
Affects Versions: 1.4.10, 1.5-M1
Reporter: Jeremy Thomerson
Assignee: Jeremy Thomerson
Priority: Minor

 This was sent to me from a client, and after a quick look, appears to be 
 valid:
 Jeremy,
  
 When FormTester is used and you add a component to it, the logic in 
 FormTester adds the component name and value into the MockHttpServletRequest 
 (which will be a String as the key and a String as a value). My issue with 
 this is that later, we have a RequestCodingStrategy which gets the 
 parameterMap from the Request which its typed as String, String[]. When we 
 iterate over this, we get a classcast exception when the String (From the 
 form) is attempted to be converted into a String[].  I think something needs 
 to improved in the Wicket Request object hierarchy to ensure this can't 
 happen. For now I have just changed my logic in the RequestCodingStrategy to 
 check for the String[] type.
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-2987) Investigate WicketTester sets parameter map value of String, but Request returns String[] and causes ClassCastException


 [ 
https://issues.apache.org/jira/browse/WICKET-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-2987:
--

   Summary: Investigate WicketTester sets parameter map value of String, 
but Request returns String[] and causes ClassCastException  (was: WicketTester 
sets parameter map value of String, but Request returns String[] and causes 
ClassCastException)
Issue Type: Task  (was: Bug)

 Investigate WicketTester sets parameter map value of String, but Request 
 returns String[] and causes ClassCastException
 ---

 Key: WICKET-2987
 URL: https://issues.apache.org/jira/browse/WICKET-2987
 Project: Wicket
  Issue Type: Task
  Components: wicket
Affects Versions: 1.4.10, 1.5-M1
Reporter: Jeremy Thomerson
Assignee: Jeremy Thomerson
Priority: Minor

 This was sent to me from a client, and after a quick look, appears to be 
 valid:
 Jeremy,
  
 When FormTester is used and you add a component to it, the logic in 
 FormTester adds the component name and value into the MockHttpServletRequest 
 (which will be a String as the key and a String as a value). My issue with 
 this is that later, we have a RequestCodingStrategy which gets the 
 parameterMap from the Request which its typed as String, String[]. When we 
 iterate over this, we get a classcast exception when the String (From the 
 form) is attempted to be converted into a String[].  I think something needs 
 to improved in the Wicket Request object hierarchy to ensure this can't 
 happen. For now I have just changed my logic in the RequestCodingStrategy to 
 check for the String[] type.
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-2987) Investigate WicketTester sets parameter map value of String, but Request returns String[] and causes ClassCastException

[
https://issues.apache.org/jira/browse/WICKET-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Igor Vaynberg updated WICKET-2987:
--

Comment: was deleted

(was: tried with 1.4.10, when i enter 123456 in the second field i get:

* '123456' is not a valid Date.
* error

)

Investigate WicketTester sets parameter map value of String, but Request
returns String[] and causes ClassCastException
---

Key: WICKET-2987
URL: https://issues.apache.org/jira/browse/WICKET-2987
Project: Wicket
Issue Type: Task
Components: wicket
Affects Versions: 1.4.10, 1.5-M1
Reporter: Jeremy Thomerson
Assignee: Jeremy Thomerson
Priority: Minor

This was sent to me from a client, and after a quick look, appears to be
valid:
Jeremy,

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-2987) Investigate WicketTester sets parameter map value of String, but Request returns String[] and causes ClassCastException

[
https://issues.apache.org/jira/browse/WICKET-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903847#action_12903847
]

Igor Vaynberg commented on WICKET-2987:
---

now it wont fall through the cracks, but it also wont look like a bug no one
has ever bothered to look into. in the past few days ive closed a bunch of
stuff like this that was sitting there for YEARS. if i run a statistic on jira
that calculates average time to close a bug all this stuff makes wicket look
like a project where devs dont care about fixing bugs.

Investigate WicketTester sets parameter map value of String, but Request
returns String[] and causes ClassCastException
---

This was sent to me from a client, and after a quick look, appears to be
valid:
Jeremy,

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

svn commit: r990396 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java

Author: ivaynberg
Date: Sat Aug 28 17:49:03 2010
New Revision: 990396

URL: http://svn.apache.org/viewvc?rev=990396view=rev
Log:
javadoc

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=990396r1=990395r2=990396view=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
 Sat Aug 28 17:49:03 2010
@@ -30,6 +30,12 @@ import org.apache.wicket.util.upload.Fil
  * component is nested in a {...@link 
org.apache.wicket.markup.html.form.Form}, that has multipart ==
  * true, its model is updated with the {...@link 
org.apache.wicket.markup.html.form.upload.FileUpload}
  * for this component.
+ * p
+ * strongNOTE/strongThe model of this component is reset with {...@code 
null} at the end of the
+ * request because {...@link FileUpload} instances do not survive across 
requests since the input
+ * streams they point to will be closed. Because of this, the {...@link 
FileUpload} instance should be
+ * processed within the same request as the form containing it was submitted.
+ * /p
  * 
  * @author Eelco Hillenius
  */

svn commit: r990397 - /wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java

Author: ivaynberg
Date: Sat Aug 28 17:49:09 2010
New Revision: 990397

URL: http://svn.apache.org/viewvc?rev=990397view=rev
Log:
javadoc

Modified:

wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java

Modified: 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
URL: 
http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java?rev=990397r1=990396r2=990397view=diff
==
--- 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
 (original)
+++ 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java
 Sat Aug 28 17:49:09 2010
@@ -30,6 +30,12 @@ import org.apache.wicket.util.upload.Fil
  * component is nested in a {...@link 
org.apache.wicket.markup.html.form.Form}, that has multipart ==
  * true, its model is updated with the {...@link 
org.apache.wicket.markup.html.form.upload.FileUpload}
  * for this component.
+ * p
+ * strongNOTE/strongThe model of this component is reset with {...@code 
null} at the end of the
+ * request because {...@link FileUpload} instances do not survive across 
requests since the input
+ * streams they point to will be closed. Because of this, the {...@link 
FileUpload} instance should be
+ * processed within the same request as the form containing it was submitted.
+ * /p
  * 
  * @author Eelco Hillenius
  */

[jira] Resolved: (WICKET-2864) FileUpload and Wizard


 [ 
https://issues.apache.org/jira/browse/WICKET-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2864.
---

Resolution: Invalid

i have just added the following javadoc to FileUploadField

 * p
 * strongNOTE/strongThe model of this component is reset with {...@code 
null} at the end of the
 * request because {...@link FileUpload} instances do not survive across 
requests since the input
 * streams they point to will be closed. Because of this, the {...@link 
FileUpload} instance should be
 * processed within the same request as the form containing it was submitted.
 * /p

what you should so is in setFu(FileUpload) copy the file to some temporary 
location and store the path to the file in the dto so you can access it at the 
end of the wizard. cheers.

 FileUpload and Wizard
 -

 Key: WICKET-2864
 URL: https://issues.apache.org/jira/browse/WICKET-2864
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 1.4.8
 Environment: ubuntu10.4 / jdk1.6.0_20 / tomcat-6.0.20 / Eclipse 3.5.2
Reporter: Martin Hubert
Assignee: Igor Vaynberg
 Attachments: WicketWizardTest.tgz


 FileUploadField is always null if not in last WizardStep. 
 public TestWizard() {
 ...
   model.add(new StepFu());
   model.add(new StepTxt());
 ...
 }
 works, but for 
 public TestWizard() {
 ...
   model.add(new StepTxt());
   model.add(new StepFu());
 ...
 }
 the FileUpload ist always null. 
 ===
 import java.io.Serializable;
 import org.apache.wicket.extensions.wizard.Wizard;
 import org.apache.wicket.extensions.wizard.WizardModel;
 import org.apache.wicket.extensions.wizard.WizardStep;
 import org.apache.wicket.markup.html.form.TextField;
 import org.apache.wicket.markup.html.form.upload.FileUpload;
 import org.apache.wicket.markup.html.form.upload.FileUploadField;
 import org.apache.wicket.model.CompoundPropertyModel;
 public class TestWizard extends Wizard {
   private static final long serialVersionUID = 1L;
   public TestWizard(String id) {
   super(id);
   TestBean bean = new TestBean();
   setDefaultModel(new CompoundPropertyModelTestBean(bean));
   WizardModel model = new WizardModel();
   model.add(new StepFu());
   model.add(new StepTxt());
   init(model);
   getForm().setMultiPart(true);
   }
   public class TestBean implements Serializable {
   private static final long serialVersionUID = 1L;
   private String _text1;
   private FileUpload _fu;
   public String getText1() {
   return _text1;
   }
   public void setText1(String text1) {
   _text1 = text1;
   }
   public FileUpload getFu() {
   return _fu;
   }
   public void setFu(FileUpload fu) {
   _fu = fu;
   }
   }
   
   private final class StepTxt extends WizardStep {
   private static final long serialVersionUID = 1L;
   public StepTxt() {
   add(new TextFieldString(text1));
   }
   }
   
   private final class StepFu extends WizardStep {
   private static final long serialVersionUID = 1L;
   public StepFu() {
   add(new FileUploadField(fu));
   }
   }
   
   @Override
   public void onFinish() {
   TestBean bean = (TestBean) getDefaultModelObject();
   
 System.out.println(***);
   System.out.println(text1:  + bean.getText1());
   System.out.println(fu: + bean.getFu());
   
 System.out.println(***);
   setResponsePage(getApplication().getHomePage());
   }
 }
 ===
 Tested with wicket-1.4.7 and wicket-1.4.8

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WICKET-3022) All exceptions are handled by RequestCycle and no longer visible to WicketTester

2010-08-28 Thread Juergen Donnerstag (JIRA)


 [ 
https://issues.apache.org/jira/browse/WICKET-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Juergen Donnerstag resolved WICKET-3022.


 Assignee: Juergen Donnerstag
Fix Version/s: 1.5-M2
   Resolution: Fixed

 All exceptions are handled by RequestCycle and no longer visible to 
 WicketTester
 --

 Key: WICKET-3022
 URL: https://issues.apache.org/jira/browse/WICKET-3022
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5-M1
Reporter: Juergen Donnerstag
Assignee: Juergen Donnerstag
 Fix For: 1.5-M2


 Exceptions during render will no longer be detected by WicketTester, since 
 RequestCycle handles them all. Which is ok for normal processing, but bad for 
 WicketTester. We somehow need to make WicketTester aware of thrown exceptions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

svn commit: r990399 - in /wicket/trunk/wicket/src/main/java/org/apache/wicket: request/cycle/RequestCycle.java util/tester/BaseWicketTester.java

2010-08-28 Thread jdonnerstag

Author: jdonnerstag
Date: Sat Aug 28 17:53:46 2010
New Revision: 990399

URL: http://svn.apache.org/viewvc?rev=990399view=rev
Log:
fixed WICKET-3022: All exceptions are handled by RequestCycle and no longer 
visible to WicketTester
Issue: WICKET-3022

Modified:

wicket/trunk/wicket/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java

wicket/trunk/wicket/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java

Modified: 
wicket/trunk/wicket/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java?rev=990399r1=990398r2=990399view=diff
==
--- 
wicket/trunk/wicket/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java
 (original)
+++ 
wicket/trunk/wicket/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java
 Sat Aug 28 17:53:46 2010
@@ -204,12 +204,13 @@ public class RequestCycle extends Reques
}
 
/**
-* Processes the request.
+* Processes the request and detaches the {...@link RequestCycle}, but 
does not handle any
+* exceptions. Exceptions are not caught and thus are passed through to 
e.g. WicketTester.
 * 
 * @return codetrue/code if the request resolved to a Wicket 
request, codefalse/code
 * otherwise.
 */
-   public boolean processRequest()
+   public boolean processRequestAndDetachWithoutExceptionHandling()
{
try
{
@@ -220,58 +221,59 @@ public class RequestCycle extends Reques
executeRequestHandler(handler);
return true;
}
-
-   }
-   catch (Exception e)
-   {
-   IRequestHandler handler = handleException(e);
-   if (handler != null)
-   {
-   executeExceptionRequestHandler(handler, 
getExceptionRetryCount());
-   }
-   else
-   {
-   log.error(Error during request processing, e);
-   }
-   return true;
}
finally
{
set(null);
+   detach();
}
return false;
}
 
/**
-* Convenience method that processes the request and detaches the 
{...@link RequestCycle}.
+* Processes the request and detaches the {...@link RequestCycle}. 
Exceptions are caught and
+* managed.
+* 
+* @see #handleException(Exception)
+* @see #executeExceptionRequestHandler(IRequestHandler, int)
 * 
 * @return codetrue/code if the request resolved to a Wicket 
request, codefalse/code
 * otherwise.
 */
public boolean processRequestAndDetach()
{
-   boolean result;
try
{
-   result = processRequest();
+   return 
processRequestAndDetachWithoutExceptionHandling();
}
-   finally
+   catch (Exception e)
{
-   detach();
+   IRequestHandler handler = handleException(e);
+   if (handler != null)
+   {
+   return executeExceptionRequestHandler(handler, 
getExceptionRetryCount());
+   }
+   else
+   {
+   log.error(Error during request processing, e);
+   }
}
-   return result;
+   return false;
}
 
/**
 * 
 * @param handler
 * @param retryCount
+* @return False, in case all retry attempts failed and the request 
could not be handled
 */
-   private void executeExceptionRequestHandler(final IRequestHandler 
handler, final int retryCount)
+   private boolean executeExceptionRequestHandler(final IRequestHandler 
handler,
+   final int retryCount)
{
try
{
executeRequestHandler(handler);
+   return true;
}
catch (Exception e)
{
@@ -280,12 +282,12 @@ public class RequestCycle extends Reques
IRequestHandler next = handleException(e);
if (handler != null)
{
-   executeExceptionRequestHandler(next, 
retryCount - 1);
-   return;
+

[jira] Commented: (WICKET-3021) Add timestamp part to resource filenames for better caching


[ 
https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903852#action_12903852
 ] 

Igor Vaynberg commented on WICKET-3021:
---

this should replace 
getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() 

 Add timestamp part to resource filenames for better caching
 ---

 Key: WICKET-3021
 URL: https://issues.apache.org/jira/browse/WICKET-3021
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.5-M1
Reporter: Peter Ertl
 Attachments: timestamp-for-resources.patch


 Even though we have 
 getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this 
 still is far from perfect. It will add a query parameter to resource 
 filenames so caches should invalidate when the parameter changes. However if 
 caching is very aggressive altering the query param might not be enough. Then 
 there will be stale resources left in the cache of the browser or some 
 intermediate proxy. Users will complain and you have to tell them to press 
 F5, clear the cache, or whatever :-(
 So I decided to implement support for adding the timestamp of the resource as 
 part of the filename.
 When you have a resource link like
   link rel=stylesheet type=text/css 
 href=wicket/resource/my.great.app.HomePage/css/style.css/
 a timestamp (the last modified timestamp of the file) will be injected into 
 the base name of the file
   link rel=stylesheet type=text/css 
 href=wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css/
 the format is
   [path-component]* / [base-filename] -ts [timestamp-in-milliseconds] 
 (.extension)
 The prefix -ts (TS = timestamp) is to avoid naming conflicts with filenames 
 that already got with a numeric part before the extension.
 Locales, style and variations are taken into consideration (e.g. style.css, 
 style_de.css, style_en.css)
 When running your test cases the MockApplication which WicketTester provides 
 in the default case has timestamps disabled so you can check you rendered 
 markup against some predictable url.
 You can control and check timestamp behavior with
   getResourceSettings().setUseTimestampOnResources()
 and 
   getResourceSettings().getUseTimestampOnResources()
 Default behavior is 'enabled'
 You are now able to configure your resource caching for a very large lifetime 
 (say 'infinite' :-) and get the best possible network performance and 
 utilization of proxies.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-3021) Add timestamp part to resource filenames for better caching


[ 
https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903853#action_12903853
 ] 

Peter Ertl commented on WICKET-3021:


@igor: yes, and we should mention that in the migration notes (whoever 
maintains them).

 Add timestamp part to resource filenames for better caching
 ---

 Key: WICKET-3021
 URL: https://issues.apache.org/jira/browse/WICKET-3021
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.5-M1
Reporter: Peter Ertl
 Attachments: timestamp-for-resources.patch


 Even though we have 
 getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this 
 still is far from perfect. It will add a query parameter to resource 
 filenames so caches should invalidate when the parameter changes. However if 
 caching is very aggressive altering the query param might not be enough. Then 
 there will be stale resources left in the cache of the browser or some 
 intermediate proxy. Users will complain and you have to tell them to press 
 F5, clear the cache, or whatever :-(
 So I decided to implement support for adding the timestamp of the resource as 
 part of the filename.
 When you have a resource link like
   link rel=stylesheet type=text/css 
 href=wicket/resource/my.great.app.HomePage/css/style.css/
 a timestamp (the last modified timestamp of the file) will be injected into 
 the base name of the file
   link rel=stylesheet type=text/css 
 href=wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css/
 the format is
   [path-component]* / [base-filename] -ts [timestamp-in-milliseconds] 
 (.extension)
 The prefix -ts (TS = timestamp) is to avoid naming conflicts with filenames 
 that already got with a numeric part before the extension.
 Locales, style and variations are taken into consideration (e.g. style.css, 
 style_de.css, style_en.css)
 When running your test cases the MockApplication which WicketTester provides 
 in the default case has timestamps disabled so you can check you rendered 
 markup against some predictable url.
 You can control and check timestamp behavior with
   getResourceSettings().setUseTimestampOnResources()
 and 
   getResourceSettings().getUseTimestampOnResources()
 Default behavior is 'enabled'
 You are now able to configure your resource caching for a very large lifetime 
 (say 'infinite' :-) and get the best possible network performance and 
 utilization of proxies.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-2793) Incorrect decode parameters in AbstractRequestTargetUrlCodingStrategy#decodeParameters


[ 
https://issues.apache.org/jira/browse/WICKET-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903854#action_12903854
 ] 

Hudson commented on WICKET-2793:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 Incorrect decode parameters in 
 AbstractRequestTargetUrlCodingStrategy#decodeParameters
 --

 Key: WICKET-2793
 URL: https://issues.apache.org/jira/browse/WICKET-2793
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7
 Environment: Java 1.5, Tomcat 5.5
Reporter: Igor Azarny
Assignee: Igor Vaynberg
 Fix For: 1.4.11

   Original Estimate: 24h
  Remaining Estimate: 24h

 In case of  utf-8 url (see example below) created ValueMap in 
 AbstractRequestTargetUrlCodingStrategy#decodeParameters is incorrect. 
 Each key-value pair contains not decoded key and decoded value.
 Proposed fix - line no 171 in 
 AbstractRequestTargetUrlCodingStrategy#decodeParameters
 parameters.add(pairs[i], value);
 shall be 
 parameters.add(urlDecodePathComponent(pairs[i]), value);
  
 Changes locally tested on 1.4.7 version - no failed test.  But I am not sure 
 is AbstractRequestTargetUrlCodingStrategy covered by test cases.
 And works correctly on tomcat.
 URL in browser
 http://jewelry.npa.com:8080/ws/shop/category/Браслеты/Колір_металу/Белый/Вставка/Бриллиант/Розмір/19.5/brand/Enigma/Проба/750/Матеріал/Золото/price/USD-31-60/Колір_вставки/Белый
 URL in Tomcat
 http://jewelry.npa.com:8080/ws/shop/category/%D0%91%D1%80%D0%B0%D1%81%D0%BB%D0%B5%D1%82%D1%8B/%D0%9A%D0%BE%D0%BB%D1%96%D1%80_%D0%BC%D0%B5%D1%82%D0%B0%D0%BB%D1%83/%D0%91%D0%B5%D0%BB%D1%8B%D0%B9/%D0%92%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0/%D0%91%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D0%B0%D0%BD%D1%82/%D0%A0%D0%BE%D0%B7%D0%BC%D1%96%D1%80/19.5/brand/Enigma/%D0%9F%D1%80%D0%BE%D0%B1%D0%B0/750/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D1%96%D0%B0%D0%BB/%D0%97%D0%BE%D0%BB%D0%BE%D1%82%D0%BE/price/USD-31-60/%D0%9A%D0%BE%D0%BB%D1%96%D1%80_%D0%B2%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B8/%D0%91%D0%B5%D0%BB%D1%8B%D0%B9

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-1010) Contract of Session.attach() and Session.detach()


[ 
https://issues.apache.org/jira/browse/WICKET-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903860#action_12903860
 ] 

Hudson commented on WICKET-1010:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 Contract of Session.attach() and Session.detach()
 -

 Key: WICKET-1010
 URL: https://issues.apache.org/jira/browse/WICKET-1010
 Project: Wicket
  Issue Type: Bug
Reporter: Martin Funk
Assignee: Igor Vaynberg
 Fix For: 1.5-M1


 What is the contract of Session.attach() and Session.detach() ?
 Especially, is it intended that after a call to attach() that there will
 be at least one call to detach() before the request goes back to the client?
 If that's the case, then there might be a bug in Session and I propose
 the following patch on org.apache.wicket.Session 
 Index: .
 ===
 --- .(revision 579354)
 +++ .(working copy)
 @@ -305,6 +305,11 @@
  */
 public static void unset()
 {
 +Session session = (Session)current.get();
 +if (session != null)
 +{
 +session.detach();
 +}
 current.set(null);
 }
 In my current project well fell over this looking at:
 WicketFilter.getLastModified(final HttpServletRequest servletRequest)
 where cachable resources lead over Session.findOrCreate to 
 Session.set(Session) to Session.attach()
 but the Session.unset() doesn't lead to a Session.detach()
 Martin 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-1887) 404 error page customize - with specified url-pattern (not /*)


[ 
https://issues.apache.org/jira/browse/WICKET-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903863#action_12903863
 ] 

Hudson commented on WICKET-1887:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 404 error page customize - with specified url-pattern (not /*)
 --

 Key: WICKET-1887
 URL: https://issues.apache.org/jira/browse/WICKET-1887
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.4
 Environment: jetty 6.1.x
 Tomcat 6
 Gentoo linux
Reporter: Stanislav Dvorscak
Assignee: Igor Vaynberg
 Fix For: 1.4.11

 Attachments: wicket-bug.tar.gz


 The problem is with incorrect url, when I created own 404 page. 
 I attached the source, where can you see the problem. If you start the 
 application, and than you go to http://localhost:8080/app/404 - you can see 
 error test page, with own CSS file (NotFoundPage). It is function, but the 
 problem is, if you try to access any missing page. Than you can see the error 
 page (NotFoundPage), but the problem is, that the css style added by css 
 header contributer generates incorrect url. I try to understand the problem, 
 but I can see strange behavior. (It always returns the url, referenced to 
 root, but not to specified  url-pattern of web.xml).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-2851) Ajax responses do not update DOM correctly on Opera


[ 
https://issues.apache.org/jira/browse/WICKET-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903865#action_12903865
 ] 

Hudson commented on WICKET-2851:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 Ajax responses do not update DOM correctly on Opera
 ---

 Key: WICKET-2851
 URL: https://issues.apache.org/jira/browse/WICKET-2851
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.7
 Environment: This issue affects just Opera, my tested version is 
 10.52.
 Other browsers I tested but are not affected by the issue: Firefox 3.6.3, IE 
 8.0, Chrome 4.1.249.1059.
 Application was deployed on Apache Tomcat 5.5.28 and Jetty 6.1.6.
 Everything runs on MS Win 7 Ultimate x64.
Reporter: Martin Petras
Assignee: Igor Vaynberg
 Fix For: 1.4.11, 1.5-M2

 Attachments: test.zip


 Having following example:
 = HTML ==
 table
   trtdbutton wicket:id=btnShowHideShow/Hide/button/td/tr
   tr wicket:id=hidingContainertdsomething goes here.../td/tr
 /table
 = PAGE ==
 final Component hidingContainer;
 this.add(hidingContainer = new 
 WebMarkupContainer(hidingContainer).setOutputMarkupId(
   true).setOutputMarkupPlaceholderTag(true).setVisible(true));
   
 this.add(new AjaxFallbackLinkVoid(btnShowHide){
   @Override
   public void onClick(AjaxRequestTarget target) {
   hidingContainer.setVisible(!hidingContainer.isVisible());
   target.addComponent(hidingContainer);
   }
 });
 On Opera browser it works well only once. Afterwards it is not possible to 
 show/hide hidingContainer.
 Ajax response doesn't update hidingContainer's DOM properly. Response is 
 correct, however after replacing existing html code with an incomming html 
 the TR tag looses its ID attribute. Hence the following Ajax response fails 
 to update the TR tag and throws error:
 ERROR: Wicket.Ajax.Call.processComponent: Component with id 
 [[hidingContainer4]] a was not found while trying to perform markup update. 
 This problem occurs only when hidingContainer is in a TR tag. If replaced 
 with p, everything works like a charm.
 It must be a bug in the Opera browser but maybe there is any workaround that 
 may get it work.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-3018) CheckGroupSelector ignores disabled-state in Check


[ 
https://issues.apache.org/jira/browse/WICKET-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903861#action_12903861
 ] 

Hudson commented on WICKET-3018:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 CheckGroupSelector ignores disabled-state in Check
 --

 Key: WICKET-3018
 URL: https://issues.apache.org/jira/browse/WICKET-3018
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.9
Reporter: r...@audenaerde.org
Assignee: Igor Vaynberg
 Fix For: 1.4.11, 1.5-M2


 I have a list with Checks, in a CheckGroup. Some of the Checks are disabled 
 (gray in html). I also have a CheckGroupSelector. When clicking the 
 CheckGroupSelector, the disabled Checks are also modified. I expect them to 
 be left alone. 
 The javascript in the CheckGroupSelector is IMHO incorrect:
 it contains:
   for(var i=0;icb.length;i++) 
   { 
   cb[i].checked=this.checked; 
   } 
 and should be:
   for(var i=0;icb.length;i++) 
   { 
   if (!cb[i].disabled)
   {
   cb[i].checked=this.checked; 
   }
   } 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-2905) Select.isSelected fails when Wicket application is using REDIRECT_TO_RENDER render strategy.

[
https://issues.apache.org/jira/browse/WICKET-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903855#action_12903855
]

Hudson commented on WICKET-2905:

Integrated in Apache Wicket 1.4.x #129 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])

Select.isSelected fails when Wicket application is using REDIRECT_TO_RENDER
render strategy.

Key: WICKET-2905
URL: https://issues.apache.org/jira/browse/WICKET-2905
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Affects Versions: 1.4.9
Reporter: Liam Clarke-Hutchinson
Assignee: Igor Vaynberg
Priority: Minor
Fix For: 1.4.11, 1.5-M2

Attachments: select-bug_reproduction.zip, Select.patch

To reproduce using attached quick start:
1. Leave text field empty
2. Select a value in dropdown
3. Click submit link
4. The text field's validation will fail and the page will refresh with a
validation error message
5. The dropdown's selected value will always be the first in the option list,
no matter what value was selected in step 2.
As the dropdown is updating its model via the AJAX behaviour, the value
selected in step 2 should be the one selected when the page is redisplayed.
We can workaround this like so:
final Select select = new Select(select, New ModelString()) {
@Override
protected void convertInput() {
super.convertInput();
clearInput();
}
};
As this removes the rawInput from Select, Select.isSelected then evaluates
the models to determine the selected option. I have attached a patch in
universal diff format that fixes this behaviour, and have tested it under all
render strategies. I haven't written a unit test for this as the bug
ultimately relied on submitted values not being available in a request, and I
wasn't able to determine how to emulate this in a unit testing environment.
(Pointers more than welcome. :) )

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-1928) Enter key submits form in AjaxEditableMultiLineLabel on Safari


[ 
https://issues.apache.org/jira/browse/WICKET-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903864#action_12903864
 ] 

Hudson commented on WICKET-1928:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 Enter key submits form in AjaxEditableMultiLineLabel on Safari
 --

 Key: WICKET-1928
 URL: https://issues.apache.org/jira/browse/WICKET-1928
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4-M3
 Environment: Mac OSX
Reporter: Joakim Örtbrant
Assignee: Igor Vaynberg
 Fix For: 1.4.11, 1.5-M2


 Pressing the Enter key when editing a AjaxEditableMultiLineLabel submits the 
 form on Safari instead of inserting a new line

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-1094) Values over-escaped by FormTester


[ 
https://issues.apache.org/jira/browse/WICKET-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903856#action_12903856
 ] 

Hudson commented on WICKET-1094:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 Values over-escaped by FormTester
 -

 Key: WICKET-1094
 URL: https://issues.apache.org/jira/browse/WICKET-1094
 Project: Wicket
  Issue Type: Bug
Affects Versions: 1.3.0-beta4
Reporter: David Shepherdson
Assignee: Igor Vaynberg
 Fix For: 1.4.11, 1.5-M2


 FormTester's constructor contains code that visits all components on the form 
 and calls setFormComponentValue(formComponent, formComponent.getValue()) (or 
 variations thereof), to store the component's value in the servlet request 
 parameters. However, by default, FormComponent's getValue() method uses 
 Strings.escapeMarkup(...) to encode any special characters, such as angle 
 brackets. This is fine in a 'real' environment, where a Web browser will be 
 responsible for displaying the escaped characters with their proper values, 
 and so the proper value will be the one that comes through when the form is 
 submitted; however, in the Wicket test environment, there isn't anything to 
 do that extra level of 'un-escaping', meaning there's a danger of the form 
 components being given escaped values when the form is submitted.
 For example, we have a form that contains a text area, whose value contains a 
 URI enclosed in angle brackets, like so:
  http://test.com/ 
 When we submit the form with a Web browser, the value set on the model is 
 exactly that string -- ' http://test.com/ '. However, when we test our page 
 with FormTester, the FormTester constructor calls getValue() on the 
 component, which by default returns the escaped form:
 lt; http://test.com/ gt;
 When the form is submitted, this is the value set on the model, and so 
 comparisons to the original string fail.
 (Extra spaces inserted into the strings above to make them display properly 
 in JIRA.)
 However, if FormTester were to call setEscapeModelStrings(false) on the form 
 component before calling getValue() (and then restore the original escaping 
 setting afterwards), then the value that ends up being provided to the 
 component at the end would be the correct (unescaped) value, matching the 
 behaviour when using the page in a browser.
 We have worked around this issue by overriding FormTester with a class that 
 performs a second traversal of the form component hierarchy after calling the 
 FormTester constructor, replacing the incorrectly escaped values with the 
 proper ones (changes marked with '// O-P'):
 public OurFormTester(String path, Form workingForm, BaseWicketTester 
 wicketTester, boolean fillBlankString) {
 super(path, workingForm, wicketTester, fillBlankString);
 fixFormParameterValues(workingForm, fillBlankString);
 }
 
 protected void fixFormParameterValues(Form workingForm, final boolean 
 fillBlankString) {
 workingForm.visitFormComponents(new FormComponent.AbstractVisitor()
 {
 public void onFormComponent(final FormComponent formComponent)
 {
 // do nothing for invisible component
 if (!formComponent.isVisibleInHierarchy())
 {
 return;
 }
 // O-P Preserve old escaping value, then turn escaping off
 // so that values aren't escaped unnecessarily.
 boolean oldEscaping = formComponent.getEscapeModelStrings();
 formComponent.setEscapeModelStrings(false);
 
 // if component is text field and do not have exist value, 
 fill
 // blank String if required
 if (formComponent instanceof AbstractTextComponent)
 {
 if (Strings.isEmpty(formComponent.getValue()))
 {
 if (fillBlankString)
 {
 setFormComponentValue(formComponent, );
 }
 }
 else
 {
 setFormComponentValue(formComponent, 
 formComponent.getValue());
 }
 }
 else if ( (formComponent instanceof DropDownChoice) ||
 (formComponent instanceof RadioChoice) ||
 (formComponent instanceof CheckBox))
 {
 setFormComponentValue(formComponent, 
 formComponent.getValue());
 }
 else if (formComponent instanceof ListMultipleChoice)
 {

[jira] Commented: (WICKET-2401) AJAX indicator turns off when calls overlap


[ 
https://issues.apache.org/jira/browse/WICKET-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903857#action_12903857
 ] 

Hudson commented on WICKET-2401:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 AJAX indicator turns off when calls overlap
 ---

 Key: WICKET-2401
 URL: https://issues.apache.org/jira/browse/WICKET-2401
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.0
Reporter: John Patterson
Assignee: Igor Vaynberg
 Fix For: 1.4.11, 1.5-M2


 As discussed here 
 http://www.nabble.com/Ajax-indicator-turning-off-td24655744.html
 Overlapping AJAX calls result in the indicator being turned off when the 
 first call returns.  This patch keeps a count property directly on the 
 HTMLElement so when the element goes out of scope the count does not need to 
 be removed.  Each AJAX call increments the counter and each return decrements 
 the counter.
 Index: src/main/java/org/apache/wicket/ajax/wicket-ajax.js
 ===
 --- src/main/java/org/apache/wicket/ajax/wicket-ajax.js   (revision 
 797714)
 +++ src/main/java/org/apache/wicket/ajax/wicket-ajax.js   (working copy)
 @@ -2214,3 +2214,31 @@
   e.style.display = none;
   }
  }
 +
 +function wicketIncrementDisplay(id) {
 +var e=wicketGet(id);
 +if (typeof(e.wicketDisplayCount) ==undefined) {
 + e.wicketDisplayCount = 1;
 +} else {
 + e.wicketDisplayCount++;
 +}
 +
 + if (e.wicketDisplayCount  0) {
 + e.style.display = ;
 + }
 +}
 +
 +function wicketDecrementDisplay(id) {
 +var e=wicketGet(id);
 +if (typeof(e.wicketDisplayCount) ==undefined) {
 + e.wicketDisplayCount = 0;
 +} else {
 + e.wicketDisplayCount--;
 +}
 +
 + if (e.wicketDisplayCount = 0) {
 + e.style.display = none;
 + }
 +}
 +
 +
 Index: src/main/java/org/apache/wicket/ajax/AbstractDefaultAjaxBehavior.java
 ===
 --- src/main/java/org/apache/wicket/ajax/AbstractDefaultAjaxBehavior.java 
 (revision 797714)
 +++ src/main/java/org/apache/wicket/ajax/AbstractDefaultAjaxBehavior.java 
 (working copy)
 @@ -183,7 +183,7 @@
  
   if (!Strings.isEmpty(indicatorId))
   {
 - String hide = ;wicketHide(' + indicatorId + ');;
 + String hide = ;wicketDecrementDisplay(' + indicatorId 
 + ');;
   success = success + hide;
   failure = failure + hide;
   }
 @@ -240,7 +240,7 @@
  
   if (!Strings.isEmpty(indicatorId))
   {
 - call = new 
 AppendingStringBuffer(wicketShow(').append(indicatorId)
 + call = new 
 AppendingStringBuffer(wicketIncrementDisplay(').append(indicatorId)
   .append(');)
   .append(call);
   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-2783) FormTester.submit does not work with AjaxButtons


[ 
https://issues.apache.org/jira/browse/WICKET-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903858#action_12903858
 ] 

Hudson commented on WICKET-2783:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 FormTester.submit does not work with AjaxButtons
 

 Key: WICKET-2783
 URL: https://issues.apache.org/jira/browse/WICKET-2783
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.7
Reporter: Tony Wu
Assignee: Igor Vaynberg
 Fix For: 1.4.11, 1.5-M2

 Attachments: wicket-2783.tgz, wicket-ajax-submit-bug.zip


 FormTester.submit on an AjaxButton (AjaxFallbackButton) does not cause the 
 button's onSubmit function to run, nor the form's process function to run.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-3019) Add getPath to MarkupExceptions to aid in locatin affected components


[ 
https://issues.apache.org/jira/browse/WICKET-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903862#action_12903862
 ] 

Hudson commented on WICKET-3019:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 Add getPath to MarkupExceptions to aid in locatin affected components
 -

 Key: WICKET-3019
 URL: https://issues.apache.org/jira/browse/WICKET-3019
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 
 1.4.9, 1.4.10, 1.5-M1
Reporter: Clint Checketts
Assignee: Jeremy Thomerson
Priority: Trivial
 Fix For: 1.4.11, 1.5-M2

 Attachments: wicket-1.4.patch, wicket-1.5.patch

   Original Estimate: 0.08h
  Remaining Estimate: 0.08h

 Currently when a markup exception occurs it is in the format of:
 Component componentId must be applied to a tag of type 'select', not 'span 
 wicket:id=input' (line 0, column 0)
 The error message isn't very helpful when multiple components may have the 
 same ID. This occurs primarily with repeaters.
 The change could take place in the Component class in the 
 checkComponentTag/checkComponentTagAttribute method:
 findMarkupStream().throwMarkupException(
   Component  + getId() +  must be applied to a 
 tag of type ' + name + ', not  +
   tag.toUserDebugString()+ +getPath());

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-2712) Wrong relative URL's when using Java EE 6 container with ERROR dispatching


[ 
https://issues.apache.org/jira/browse/WICKET-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903866#action_12903866
 ] 

Hudson commented on WICKET-2712:


Integrated in Apache Wicket 1.4.x #129 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/129/])


 Wrong relative URL's when using Java EE 6 container with ERROR dispatching
 --

 Key: WICKET-2712
 URL: https://issues.apache.org/jira/browse/WICKET-2712
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.6
 Environment: Sun JDK 1.6.0u18, GlassFish v3 appserver
Reporter: Major Peter
Assignee: Igor Vaynberg
 Fix For: 1.4.11

 Attachments: quickstart.tar.gz

   Original Estimate: 2h
  Remaining Estimate: 2h

 In the Servlet API 3.0 spec [1] the ERROR dispatched pages requests does not 
 contain forward attributes, that's why in 
 ServletWebRequest#getRelativePathPrefixToWicketHandler() on the line #270 the 
 return value is null, and the relative urls are calculated wrong.
 Way to reproduce:
 create an error page which is mapped to /error/NotFound for instance (at 
 least on way deeper then the wicketfilter), and register the errorpage to 404 
 HTTP code. On the 404 page place a link to a wicket page or resource.
 Now if you check the result with GlassFish v3, then the links on the page 
 starts with error/NotFound/, but with GlassFish v2 this works flawlessly 
 (because it's a bug in it), see for more details [2] and [3].
 [1]: http://jcp.org/aboutJava/communityprocess/final/jsr315/index.html 
 section 10.9.1. on pages 102-103
 [2]: http://old.nabble.com/Mounting-problem-with-GlassFishv3-td27386691.html
 [3]: http://forums.java.net/jive/thread.jspa?threadID=73771tstart=0
 If needed I can attach a quickstart to the issue, which shows the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-3022) All exceptions are handled by RequestCycle and no longer visible to WicketTester


[ 
https://issues.apache.org/jira/browse/WICKET-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903870#action_12903870
 ] 

Hudson commented on WICKET-3022:


Integrated in Apache Wicket 1.5.x #272 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/272/])
fixed WICKET-3022: All exceptions are handled by RequestCycle and no longer 
visible to WicketTester
Issue: WICKET-3022


 All exceptions are handled by RequestCycle and no longer visible to 
 WicketTester
 --

 Key: WICKET-3022
 URL: https://issues.apache.org/jira/browse/WICKET-3022
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5-M1
Reporter: Juergen Donnerstag
Assignee: Juergen Donnerstag
 Fix For: 1.5-M2


 Exceptions during render will no longer be detected by WicketTester, since 
 RequestCycle handles them all. Which is ok for normal processing, but bad for 
 WicketTester. We somehow need to make WicketTester aware of thrown exceptions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context

2010-08-28 Thread Erik van Oosten (JIRA)


[ 
https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903873#action_12903873
 ] 

Erik van Oosten commented on WICKET-1355:
-

Thanks Igor. But indeed, lets just drop it. The situation in which this happens 
is too specific (and hard to reproduce), and apparently hard to solve in all 
browsers, to warrant large changes.

 Autocomplete window has wrong position in scrolled context
 --

 Key: WICKET-1355
 URL: https://issues.apache.org/jira/browse/WICKET-1355
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 1.3.1
Reporter: Erik van Oosten
Assignee: Igor Vaynberg
 Attachments: Safari autocomplete in Modal Window.jpg, 
 wicket-1355-wicket-1.3.x-autocomplete.patch, 
 wicket-1355-wicket-1.4.x-autocomplete.patch, wicket-autocomplete.js


 When the autocompleted field is located in a scrolled div, the drop-down 
 window is positioned too far down.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

svn commit: r990427 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/ main/java/org/apache/wicket/request/cycle/ main/java/org/apache/wicket/util/tester/ test/java/org/apache/wicket/markup/h

Author: ivaynberg
Date: Sat Aug 28 20:00:52 2010
New Revision: 990427

URL: http://svn.apache.org/viewvc?rev=990427view=rev
Log:
cleaner fix to 3022 that does not complicate the api
Issue: WICKET-3022

Modified:

wicket/trunk/wicket/src/main/java/org/apache/wicket/DefaultExceptionMapper.java

wicket/trunk/wicket/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java

wicket/trunk/wicket/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java

wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/basic/SimplePageExpectedResult_8.html

wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/border/BoxBorderTestPage_ExpectedResult_10.html

wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/parser/filter/HeaderSectionPageExpectedResult_13.html

Modified: 
wicket/trunk/wicket/src/main/java/org/apache/wicket/DefaultExceptionMapper.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/DefaultExceptionMapper.java?rev=990427r1=990426r2=990427view=diff
==
--- 
wicket/trunk/wicket/src/main/java/org/apache/wicket/DefaultExceptionMapper.java 
(original)
+++ 
wicket/trunk/wicket/src/main/java/org/apache/wicket/DefaultExceptionMapper.java 
Sat Aug 28 20:00:52 2010
@@ -26,6 +26,7 @@ import org.apache.wicket.request.handler
 import org.apache.wicket.request.handler.IPageRequestHandler;
 import org.apache.wicket.request.handler.PageProvider;
 import org.apache.wicket.request.handler.RenderPageRequestHandler;
+import org.apache.wicket.request.http.handler.ErrorCodeResponseHandler;
 import org.apache.wicket.request.mapper.StalePageException;
 import org.apache.wicket.settings.IExceptionSettings;
 import 
org.apache.wicket.settings.IExceptionSettings.UnexpectedExceptionDisplay;
@@ -47,8 +48,9 @@ public class DefaultExceptionMapper impl
private RenderPageRequestHandler.RedirectPolicy redirectPolicy = 
RenderPageRequestHandler.RedirectPolicy.NEVER_REDIRECT;
 
/**
-* get the redirect policy in case of error (controls if the URL 
changes in case of displaying an error)
-*
+* get the redirect policy in case of error (controls if the URL 
changes in case of displaying
+* an error)
+* 
 * @return redirect policy
 */
public RenderPageRequestHandler.RedirectPolicy getRedirectPolicy()
@@ -57,9 +59,11 @@ public class DefaultExceptionMapper impl
}
 
/**
-* set the redirect policy in case of error (you can control if the URL 
changes in case of displaying an error)
-*
-* @param redirectPolicy redirection policy
+* set the redirect policy in case of error (you can control if the URL 
changes in case of
+* displaying an error)
+* 
+* @param redirectPolicy
+*redirection policy
 */
public void setRedirectPolicy(RenderPageRequestHandler.RedirectPolicy 
redirectPolicy)
{
@@ -68,6 +72,22 @@ public class DefaultExceptionMapper impl
 
public IRequestHandler map(Exception e)
{
+   try
+   {
+   return internalMap(e);
+   }
+   catch (RuntimeException e2)
+   {
+   // hmmm, we were already handling an exception! give up
+   logger.error(unexpected exception when handling 
another exception:  + e.getMessage(),
+   e);
+   return new ErrorCodeResponseHandler(500);
+   }
+
+   }
+
+   private IRequestHandler internalMap(Exception e)
+   {
if (e instanceof StalePageException)
{
// If the page was stale, just rerender it
@@ -97,7 +117,8 @@ public class DefaultExceptionMapper impl
if 
(IExceptionSettings.SHOW_EXCEPTION_PAGE.equals(unexpectedExceptionDisplay))
{
Page currentPage = extractCurrentPage();
-   return createPageRequestHandler(new 
PageProvider(new ExceptionErrorPage(e,  currentPage)));
+   return createPageRequestHandler(new 
PageProvider(new ExceptionErrorPage(e,
+   currentPage)));
}
else if 
(IExceptionSettings.SHOW_INTERNAL_ERROR_PAGE.equals(unexpectedExceptionDisplay))
{

Modified: 
wicket/trunk/wicket/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java?rev=990427r1=990426r2=990427view=diff
==
---

[jira] Resolved: (WICKET-2178) IllegalStateException Thrown when removing a node from org.apache.wicket.extensions.markup.html.tree.Tree


 [ 
https://issues.apache.org/jira/browse/WICKET-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2178.
---

  Assignee: Igor Vaynberg
Resolution: Cannot Reproduce

works fine in 1.4.x

 IllegalStateException Thrown when removing a node from 
 org.apache.wicket.extensions.markup.html.tree.Tree
 -

 Key: WICKET-2178
 URL: https://issues.apache.org/jira/browse/WICKET-2178
 Project: Wicket
  Issue Type: Bug
  Components: wicket, wicket-extensions
Affects Versions: 1.3.5
 Environment: Redhat Linux 4 WS
 Java 1.6.0_12 (from Sun)
Reporter: Steven Katz
Assignee: Igor Vaynberg
 Attachments: treeproblem.tgz


 Source that replicates the problem is attached.  Extract with 'tar xvzf 
 treeproblem.tgz'
 The example works fine with wicket 1.3.4
 The page displays a Tree Component
 1) Expand the top node of the tree
 2) Select the first child node (or any node really)
 3) Press the Delete link
 Here is the contents of the eclipse console window:
 18:14:12.307 EVENT  Statistics on = false for org.mortbay.jetty.ser...@19c26f5
 18:14:12.333 EVENT  Starting Jetty/4.2.24
 18:14:12.421 EVENT  Started WebApplicationContext[/quickstart,src/webapp]
 18:14:12.587 WARN!! Delete existing temp dir /tmp/Jetty__8081__quickstart for 
 WebApplicationContext[/quickstart,src/webapp]
 INFO  - Application- [QuickStartApplication] init: Wicket 
 core library initializer
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IBehaviorListener, method=public abstract void 
 org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IBehaviorListener, method=public abstract void 
 org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IFormSubmitListener, method=public abstract 
 void org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IFormSubmitListener, method=public abstract 
 void org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=ILinkListener, method=public abstract void 
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=ILinkListener, method=public abstract void 
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IOnChangeListener, method=public abstract void 
 org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IOnChangeListener, method=public abstract void 
 org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IRedirectListener, method=public abstract void 
 org.apache.wicket.IRedirectListener.onRedirect()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IRedirectListener, method=public abstract void 
 org.apache.wicket.IRedirectListener.onRedirect()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IResourceListener, method=public abstract void 
 org.apache.wicket.IResourceListener.onResourceRequested()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IResourceListener, method=public abstract void 
 org.apache.wicket.IResourceListener.onResourceRequested()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IActivePageBehaviorListener, method=public 
 abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface 
 [RequestListenerInterface name=IActivePageBehaviorListener, method=public 
 abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - Application- [QuickStartApplication] init: Wicket 
 extensions initializer
 INFO  - WebApplication - [QuickStartApplication] Started Wicket 
 version 1.3.5 in development mode
 
 *** WARNING: Wicket is running in

[jira] Resolved: (WICKET-2379) Redirect fails wicketTest in rc7


 [ 
https://issues.apache.org/jira/browse/WICKET-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2379.
---

  Assignee: Igor Vaynberg
Resolution: Won't Fix

there are indeed problems with sending a 302 as a response to an ajax call. 
some browsers take over and handle it automatically, but we need to be able to 
do some processing steps before we redirect.

you can easily validate the url happens like this:

assertEquals(http://testUrl;, 
tester.getServletResponse().getHeader(Ajax-Location));

 Redirect fails wicketTest in rc7
 

 Key: WICKET-2379
 URL: https://issues.apache.org/jira/browse/WICKET-2379
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4-RC7
Reporter: Martin Makundi
Assignee: Igor Vaynberg
 Attachments: Wicket-Quickstart.zip

   Original Estimate: 2h
  Remaining Estimate: 2h

 1. click ajaxButton
 2. redirect in button onSubmit
 3. verify redirect in test FAILS
 See attached quickstart

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

svn commit: r990448 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/model/AbstractPropertyModel.java

Author: ivaynberg
Date: Sat Aug 28 21:16:59 2010
New Revision: 990448

URL: http://svn.apache.org/viewvc?rev=990448view=rev
Log:
additional check for property expression
Issue: WICKET-2919

Modified:

wicket/trunk/wicket/src/main/java/org/apache/wicket/model/AbstractPropertyModel.java

Modified: 
wicket/trunk/wicket/src/main/java/org/apache/wicket/model/AbstractPropertyModel.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/model/AbstractPropertyModel.java?rev=990448r1=990447r2=990448view=diff
==
--- 
wicket/trunk/wicket/src/main/java/org/apache/wicket/model/AbstractPropertyModel.java
 (original)
+++ 
wicket/trunk/wicket/src/main/java/org/apache/wicket/model/AbstractPropertyModel.java
 Sat Aug 28 21:16:59 2010
@@ -109,6 +109,11 @@ public abstract class AbstractPropertyMo
// Return a meaningful value for an empty property 
expression
return (T)getTarget();
}
+   else if (expression.startsWith(.))
+   {
+   throw new IllegalArgumentException(
+   Property expressions cannot start with a '.' 
character);
+   }
 
final Object target = getTarget();
if (target != null)

[jira] Resolved: (WICKET-2919) inconsistency in property expression when using . for self reference


 [ 
https://issues.apache.org/jira/browse/WICKET-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2919.
---

 Assignee: Igor Vaynberg
Fix Version/s: 1.5-M2
   Resolution: Fixed

1.5 will no longer allow property expressions that start with a .

in 1.4 we leave it as is in case someone depends on this feature

 inconsistency in property expression when using . for self reference
 

 Key: WICKET-2919
 URL: https://issues.apache.org/jira/browse/WICKET-2919
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.9
Reporter: Joseph Pachod
Assignee: Igor Vaynberg
Priority: Minor
 Fix For: 1.5-M2

 Attachments: PropertyModelTest.java


 Let's consider this class :
 class Container {
 String string = foo;
 ListString strings = Arrays.asList(new String[]{test});
 }
 This would work:
 new PropertyModelString(container, .string).getObject()
 = returns foo
 but this doesn't:
 new PropertyModelString(container, .strings[0]).getObject()
 it fails with
 org.apache.wicket.WicketRuntimeException: no get method defined for class: 
 class org.demo.PropertyModelTest$Container expression: strings
 Similarly, this doesn't work:
 new PropertyModelContainer(container, .).getObject()
 exception is :java.lang.StringIndexOutOfBoundsException: String index out of 
 range: 0
 In the end, should the dot being allowed for self reference ? It's already 
 used as the property separator, so it would be quite misleading.
 I've attached some proper junit test for these points.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WICKET-1768) WicketTester dependant on order of buttons being added with AjaxFallbackButton.setDefaultFormProcessing


 [ 
https://issues.apache.org/jira/browse/WICKET-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-1768.
---

  Assignee: Igor Vaynberg
Resolution: Cannot Reproduce

can no longer reproduce with 1.4.x

 WicketTester dependant on order of buttons being added with 
 AjaxFallbackButton.setDefaultFormProcessing
 ---

 Key: WICKET-1768
 URL: https://issues.apache.org/jira/browse/WICKET-1768
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4-M3
 Environment: winxp, jdk 1.5x
Reporter: Lars Vonk
Assignee: Igor Vaynberg
 Attachments: quickstart.zip


 I have a page with one form containing a radiogroup with one option and two 
 AjaxFallbackButtons. One of the two buttons has its defaultFormProcessing set 
 to false (because it does not need to submit the form). When I test the form 
 submission with the FormTester the order in which I add the buttons to the 
 form matter whether or not the selected radio choice is actually set on the 
 model object or not. If I add the button with the defaulFormProcessing = 
 false first is does not submit correctly, if I add it as last it does. 
 This behavior only occurs with the FormTester and not in the real environment.
 I attached a quickstart project. In the test class FormTest you'll find a 
 description how to replay the situation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-2722) RequestCycle.detach() recreates SessionData after logout

[
https://issues.apache.org/jira/browse/WICKET-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Peter Ertl updated WICKET-2722:
---

Attachment: req-logger.patch

This only seems to happen when using Session#invalidateNow() but not on
Session#invalidate().

Unless it's absolutely necessary you should always prefer Session#invalidate().

I attached a fix that should fix the problem.

@Hielke: Please test and give feedback once the fix got applied.

RequestCycle.detach() recreates SessionData after logout

Key: WICKET-2722
URL: https://issues.apache.org/jira/browse/WICKET-2722
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.6, 1.4.7, 1.4.8, 1.4.9
Environment: Wicket 1.4.6, Spring 2.5.6, Hibernate 3.3.1-GA, AspectJ
1.6.8, Eclipse 3.5.2, Windows 7 32bit
Reporter: Hielke Hoeve
Priority: Minor
Attachments: req-logger.patch

After every page request the RequestCycle asks the RequestLogger (if any) to
write the time taken etc to the logger (using the SessionData of the current
Session). If none exists then a new SessionData is created (RequestLogger
line 250). However when a user logs out the SessionData is destroyed, but the
page still has to detach and thus creates a new SessionData entity.
When we lookup the live sessions and peak sessions from RequestLogger,
the two numbers are (nearly) always the same. Which is wrong when all users
have logged out or closed their browser (no difference there).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (WICKET-2691) Apply fixes from the named issues to 1.5 when API stabalizes


 [ 
https://issues.apache.org/jira/browse/WICKET-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg closed WICKET-2691.
-

  Assignee: Igor Vaynberg
Resolution: Fixed

 Apply fixes from the named issues to 1.5 when API stabalizes
 

 Key: WICKET-2691
 URL: https://issues.apache.org/jira/browse/WICKET-2691
 Project: Wicket
  Issue Type: Bug
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 1.5-M2


 WICKET-2667

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

svn commit: r990458 - /wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/protocol/http/RequestLogger.java

Author: ivaynberg
Date: Sat Aug 28 22:23:41 2010
New Revision: 990458

URL: http://svn.apache.org/viewvc?rev=990458view=rev
Log:

Issue: WICKET-2722

Modified:

wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/protocol/http/RequestLogger.java

Modified: 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/protocol/http/RequestLogger.java
URL: 
http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/protocol/http/RequestLogger.java?rev=990458r1=990457r2=990458view=diff
==
--- 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/protocol/http/RequestLogger.java
 (original)
+++ 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/protocol/http/RequestLogger.java
 Sat Aug 28 22:23:41 2010
@@ -98,8 +98,6 @@ public class RequestLogger implements IR
 
private final MapString, SessionData liveSessions;
 
-   private final ThreadLocalRequestData currentRequest = new 
ThreadLocalRequestData();
-
private final AtomicInteger active = new AtomicInteger();
 
/**
@@ -161,7 +159,7 @@ public class RequestLogger implements IR
 
public SessionData[] getLiveSessions()
{
-   SessionData[] sessions = liveSessions.values().toArray(new 
SessionData[0]);
+   SessionData[] sessions = liveSessions.values().toArray(new 
SessionData[liveSessions.values().size()]);
Arrays.sort(sessions);
return sessions;
}
@@ -243,7 +241,7 @@ public class RequestLogger implements IR
if (sessionId != null)
{
SessionData sd = liveSessions.get(sessionId);
-   if (sd == null)
+   if (sd == null  
session.isSessionInvalidated() == false)
{
// passivated session or logger only 
started after it.
sessionCreated(sessionId);

[jira] Resolved: (WICKET-2722) RequestCycle.detach() recreates SessionData after logout


 [ 
https://issues.apache.org/jira/browse/WICKET-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-2722.
---

  Assignee: Peter Ertl
Resolution: Fixed

 RequestCycle.detach() recreates SessionData after logout
 

 Key: WICKET-2722
 URL: https://issues.apache.org/jira/browse/WICKET-2722
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.6, 1.4.7, 1.4.8, 1.4.9
 Environment: Wicket 1.4.6, Spring 2.5.6, Hibernate 3.3.1-GA, AspectJ 
 1.6.8, Eclipse 3.5.2, Windows 7 32bit
Reporter: Hielke Hoeve
Assignee: Peter Ertl
Priority: Minor
 Attachments: req-logger.patch


 After every page request the RequestCycle asks the RequestLogger (if any) to 
 write the time taken etc to the logger (using the SessionData of the current 
 Session). If none exists then a new SessionData is created (RequestLogger 
 line 250). However when a user logs out the SessionData is destroyed, but the 
 page still has to detach and thus creates a new SessionData entity. 
 When we lookup the live sessions  and peak sessions from RequestLogger, 
 the two numbers are (nearly) always the same. Which is wrong when all users 
 have logged out or closed their browser (no difference there).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-3009) support X-Forwarded-Proto header in SwitchProtocolRequestTarget

[
https://issues.apache.org/jira/browse/WICKET-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903902#action_12903902
]

Peter Ertl commented on WICKET-3009:

you might want to vote for

https://issues.apache.org/jira/browse/WICKET-3015

support X-Forwarded-Proto header in SwitchProtocolRequestTarget
---

Key: WICKET-3009
URL: https://issues.apache.org/jira/browse/WICKET-3009
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.4.10
Reporter: Daniel Peters
Priority: Minor
Attachments: SwitchProtocolRequestTarget.java.patch

If you use the @RequireHttps annotation and HttpsRequestCycleProcessor, the
currently used protocol is determined by looking at
HttpServletRequest.getScheme().
But when your (clustered) wicket-application is behind a frontend
load-balancer that does all the SSL for you, this isn't enough.
In my case the load-balancer (Apache httpd with mod_proxy) does the external
http/https and ALLWAYS talks to the cluster-nodes with http. With the current
wicket-code this leads to an endless redirect-loop.
A common practice seems to be to send a request-header that says how the page
has been originally requested.
The header-name X-Forwarded-Proto is quite popular (do a google search), so
I chose that one... It should contain one of the values http or https.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-3015) add (even more) support for front-end proxies (schema, client ip, ...)


[ 
https://issues.apache.org/jira/browse/WICKET-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903903#action_12903903
 ] 

Peter Ertl commented on WICKET-3015:


this could also solve https://issues.apache.org/jira/browse/WICKET-3009

 add (even more) support for front-end proxies (schema, client ip, ...)
 --

 Key: WICKET-3015
 URL: https://issues.apache.org/jira/browse/WICKET-3015
 Project: Wicket
  Issue Type: Wish
  Components: wicket
Reporter: Peter Ertl

 Would be nice to have something like this
   http://code.google.com/p/xebia-france/wiki/XForwardedFilter
 in core. People's life would be a lot easier and it's really quite easy to 
 add (actually just parsing a few headers and wrapping the original request)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (WICKET-2948) Clash between AutoComplete request and Form submit request