[jira] Commented: (WICKET-852) Request Cycle TimeOut

2007-08-23 Thread Peter Ertl (JIRA) 

[ 
https://issues.apache.org/jira/browse/WICKET-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522116
 ] 

Peter Ertl commented on WICKET-852:
---

Does it happen immediately or after some time (like 120 seconds or so)? I could 
imagine that the web server interrupts the waiting request thread after the 
webserver's timeout is reached...

 Request Cycle TimeOut
 -

 Key: WICKET-852
 URL: https://issues.apache.org/jira/browse/WICKET-852
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.2.6
 Environment: Application server: jetty
 OS: Kubuntu
Reporter: Yoshizaki Gustavo

 In the init() method of the application (entends webApplication) I set:
 getRequestCycleSettings().setTimeout(Duration.ONE_HOUR );
 But always get the following error:
 09:00:05,290 ERROR [RequestCycle] java.lang.InterruptedException
 wicket.WicketRuntimeException: java.lang.InterruptedException
 at wicket.Session.getPage(Session.java:431)
 This is an error thrown in Session.class:
 try
 {
   pageMapsUsedInRequest.wait(timeout.getMilliseconds());
 }
 catch (InterruptedException ex)
 {
   throw new WicketRuntimeException(ex);
 }

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

[jira] Commented: (WICKET-702) MockWebApplication doesn't redirect properly to mounted pages under RestartResponseAtInterceptPageException

2007-08-23 Thread Maurice Marrink (JIRA) 

[ 
https://issues.apache.org/jira/browse/WICKET-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522117
 ] 

Maurice Marrink commented on WICKET-702:


As submitted to the user list the current resolution breaks the behavior of 
continueToOriginalDestination  when not using mounted urls. Uncomment the code 
in org.apache.wicket.markup.html.form.login.InterceptTest to see it fail.

 MockWebApplication doesn't redirect  properly to mounted pages under 
 RestartResponseAtInterceptPageException
 

 Key: WICKET-702
 URL: https://issues.apache.org/jira/browse/WICKET-702
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta1
Reporter: Mark Sandori
Assignee: Jean-Baptiste Quenot
 Fix For: 1.3.0-beta4

 Attachments: 20070703-WICKET-702.txt, LoginPage.html, LoginPage.java, 
 ProtectedPage.html, ProtectedPage.java, RestartWithMountedPageTest.java


 The MockWebApplication doesn't decode the redirect request properly when 
 redirecting to a mounted page due to a 
 RestartResponseAtInterceptPageException.
 This is the test:
   @Test
 public void testPageRender()
 {
 WicketTest tester = new WicketTester(new MyApplication());
 //must be logged in to get to the Profile page
 tester.startPage(Profile.class);
 //should redirect to the Login page
 tester.assertRenderedPage(Login.class);
 }
 The application mounts pages via:
 mount(/main, PackageName.forPackage(Profile.class.getPackage()));
 Running the test results in this exception:
 org.apache.wicket.WicketRuntimeException: Already redirecting to 
 'main/Login'. Cannot redirect more than once
   at 
 org.apache.wicket.protocol.http.BufferedWebResponse.redirect(BufferedWebResponse.java:100)
   at 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:219)
   at 
 org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103)
   at 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:981)
   at org.apache.wicket.RequestCycle.step(RequestCycle.java:1048)
   at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1127)
   at org.apache.wicket.RequestCycle.request(RequestCycle.java:489)
   at 
 org.apache.wicket.protocol.http.MockWebApplication.postProcessRequestCycle(MockWebApplication.java:426)
   at 
 org.apache.wicket.protocol.http.MockWebApplication.processRequestCycle(MockWebApplication.java:372)
   at 
 org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:237)
 What is happening is that the redirect URL main/Login is not getting 
 resolved to a bookmarkable page and the RequestParameters is therefore not 
 setup correctly. Then in WebRequestCycleProcessor.resolve(final RequestCycle 
 requestCycle, final RequestParameters requestParameters) the 
 bookmarkablePageClass of the requestParameters is null and the method 
 resolves to the Home page instead of the page that is intended to redirect 
 to. This causes an attempt to redirect again thereby causing the exception.
 If the mount() is removed then the unit test passes.

-- 
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-702) MockWebApplication doesn't redirect properly to mounted pages under RestartResponseAtInterceptPageException

2007-08-23 Thread Maurice Marrink (JIRA) 

[ 
https://issues.apache.org/jira/browse/WICKET-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522117
 ] 

mrmean edited comment on WICKET-702 at 8/23/07 5:09 AM:
-

As submitted to the user list the current solution breaks the behavior of 
continueToOriginalDestination  when not using mounted urls. Uncomment the code 
in org.apache.wicket.markup.html.form.login.InterceptTest to see it fail.

  was (Author: mrmean):
As submitted to the user list the current resolution breaks the behavior of 
continueToOriginalDestination  when not using mounted urls. Uncomment the code 
in org.apache.wicket.markup.html.form.login.InterceptTest to see it fail.
  
 MockWebApplication doesn't redirect  properly to mounted pages under 
 RestartResponseAtInterceptPageException
 

 Key: WICKET-702
 URL: https://issues.apache.org/jira/browse/WICKET-702
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta1
Reporter: Mark Sandori
Assignee: Jean-Baptiste Quenot
 Fix For: 1.3.0-beta4

 Attachments: 20070703-WICKET-702.txt, LoginPage.html, LoginPage.java, 
 ProtectedPage.html, ProtectedPage.java, RestartWithMountedPageTest.java


 The MockWebApplication doesn't decode the redirect request properly when 
 redirecting to a mounted page due to a 
 RestartResponseAtInterceptPageException.
 This is the test:
   @Test
 public void testPageRender()
 {
 WicketTest tester = new WicketTester(new MyApplication());
 //must be logged in to get to the Profile page
 tester.startPage(Profile.class);
 //should redirect to the Login page
 tester.assertRenderedPage(Login.class);
 }
 The application mounts pages via:
 mount(/main, PackageName.forPackage(Profile.class.getPackage()));
 Running the test results in this exception:
 org.apache.wicket.WicketRuntimeException: Already redirecting to 
 'main/Login'. Cannot redirect more than once
   at 
 org.apache.wicket.protocol.http.BufferedWebResponse.redirect(BufferedWebResponse.java:100)
   at 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:219)
   at 
 org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103)
   at 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:981)
   at org.apache.wicket.RequestCycle.step(RequestCycle.java:1048)
   at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1127)
   at org.apache.wicket.RequestCycle.request(RequestCycle.java:489)
   at 
 org.apache.wicket.protocol.http.MockWebApplication.postProcessRequestCycle(MockWebApplication.java:426)
   at 
 org.apache.wicket.protocol.http.MockWebApplication.processRequestCycle(MockWebApplication.java:372)
   at 
 org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:237)
 What is happening is that the redirect URL main/Login is not getting 
 resolved to a bookmarkable page and the RequestParameters is therefore not 
 setup correctly. Then in WebRequestCycleProcessor.resolve(final RequestCycle 
 requestCycle, final RequestParameters requestParameters) the 
 bookmarkablePageClass of the requestParameters is null and the method 
 resolves to the Home page instead of the page that is intended to redirect 
 to. This causes an attempt to redirect again thereby causing the exception.
 If the mount() is removed then the unit test passes.

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

svn commit: r568960 - in /wicket/trunk/jdk-1.4/wicket/src: main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java test/java/org/apache/wicket/markup/html/form/login/InterceptTest.java

2007-08-23 Thread jbq 
Author: jbq
Date: Thu Aug 23 05:48:54 2007
New Revision: 568960

URL: http://svn.apache.org/viewvc?rev=568960view=rev
Log:
WICKET-702 MockWebApplication doesn't redirect properly to mounted pages under 
RestartResponseAtInterceptPageException

Remove occurences of .. from the path

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java

wicket/trunk/jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/form/login/InterceptTest.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java?rev=568960r1=568959r2=568960view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java
 Thu Aug 23 05:48:54 2007
@@ -1293,7 +1293,17 @@
 
// We need to absolutize the redirect URL as we are not as 
smart as a web-browser (WICKET-702)
url = getContextPath() + getServletPath() + / + redirect;
-   log.debug(Redirecting to  + url);
+
+   try
+   {
+   // Remove occurences of .. from the path
+   url = new File(url).getCanonicalPath();
+   }
+   catch (IOException e)
+   {
+   throw new RuntimeException(e);
+   }
+   log.info(Redirecting to  + url);
}
 
/**

Modified: 
wicket/trunk/jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/form/login/InterceptTest.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/form/login/InterceptTest.java?rev=568960r1=568959r2=568960view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/form/login/InterceptTest.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/form/login/InterceptTest.java
 Thu Aug 23 05:48:54 2007
@@ -88,16 +88,14 @@
admin);
application.processRequestCycle();
 
-   // FIXME continueToInterceptPage seems to return the same call, 
causing it to
-   // login twice as a result the lastrendered page is null
-   /*assertEquals(application.getApplication().getHomePage(), 
application.getLastRenderedPage()
+   assertEquals(application.getApplication().getHomePage(), 
application.getLastRenderedPage()
.getClass());
 
application.setupRequestAndResponse();
application.getServletRequest().setRequestToComponent(
application.getLastRenderedPage().get(link));
application.processRequestCycle();
-   assertEquals(PageA.class, 
application.getLastRenderedPage().getClass());*/
+   assertEquals(PageA.class, 
application.getLastRenderedPage().getClass());
}
 
/**
@@ -117,16 +115,15 @@
WebRequestCycle requestCycle = application.createRequestCycle();

assertTrue(((MockLoginPage)application.getLastRenderedPage()).login(admin));
application.processRequestCycle(requestCycle);
-   // FIXME continueToInterceptPage seems to return the same call, 
causing it to
-   // login twice as a result the lastrendered page is null
-   /*assertEquals(application.getApplication().getHomePage(), 
application.getLastRenderedPage()
+
+   assertEquals(application.getApplication().getHomePage(), 
application.getLastRenderedPage()
.getClass());
 
application.setupRequestAndResponse();
application.getServletRequest().setRequestToComponent(
application.getLastRenderedPage().get(link));
application.processRequestCycle();
-   assertEquals(PageA.class, 
application.getLastRenderedPage().getClass());*/
+   assertEquals(PageA.class, 
application.getLastRenderedPage().getClass());
}
 
/**

[CONF] Apache Wicket: Companies that provide services (page edited)

2007-08-23 Thread confluence 










Page Edited :
WICKET :
Companies that provide services



 
Companies that provide services
has been edited by Rida Benjelloun
(Aug 23, 2007).
 

 
 (View changes)
 

Content:
List of companies that provide commercial services for Wicket.


Wicket Support Services


	Wicket Support is a company that provides training, consultations and commercial support for Wicket.
	Jaywayis a premier Java consulting group that via its Malaysian subsidiary provides services for Wicket development, especially running Wicket in OSGi environments.
	Skillsmatteris a leading provider of training, mentoring and project based skills transfer. Amongst other things, they provide Wicket courses.
	Anyware Technologies is a french company  that provides many training courses, including Wicket.
	jWeekend provides weekend, expert training in Java, OO  Wicket, including an "Introduction to Apache Wicket 1.3" course co-developed and co-presented by Al Maw. London  Brighton.
	Doculibre Inc. is a Canadian company that provides Wiket support and development.













Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request

Unsubscribe or edit your notifications preferences

svn commit: r568995 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/res/tree.js

2007-08-23 Thread almaw 
Author: almaw
Date: Thu Aug 23 06:57:26 2007
New Revision: 568995

URL: http://svn.apache.org/viewvc?rev=568995view=rev
Log:
WICKET-872 - Typo in org.apache.wicket.markup.html.tree.res.tree.js causes AJAX 
tree node addition failures

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/res/tree.js

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/res/tree.js
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/res/tree.js?rev=568995r1=568994r2=568995view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/res/tree.js
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/res/tree.js
 Thu Aug 23 06:57:26 2007
@@ -46,7 +46,7 @@
 
 Wicket.Tree.createElement = function(elementId, afterId) {
var existing = Wicket.$(elementId);
-   if (typeof(existing) != undefined  exiting != null) {
+   if (typeof(existing) != undefined  existing != null) {
Wicket.Tree.askForReload();
}

[jira] Resolved: (WICKET-872) Typo in org.apache.wicket.markup.html.tree.res.tree.js causes AJAX tree node addition failures

2007-08-23 Thread Alastair Maw (JIRA) 

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

Alastair Maw resolved WICKET-872.
-

   Resolution: Fixed
Fix Version/s: 1.3.0-beta4
 Assignee: Alastair Maw

Good spot. Applied to trunk. Thanks.

 Typo in org.apache.wicket.markup.html.tree.res.tree.js causes AJAX tree node 
 addition failures
 --

 Key: WICKET-872
 URL: https://issues.apache.org/jira/browse/WICKET-872
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta1, 1.3.0-beta2
 Environment: wicket 1.3.0-beta1 and 2
Reporter: Barrett Snyder
Assignee: Alastair Maw
 Fix For: 1.3.0-beta4


 There is a typo in the tree javascript which can sometimes cause node 
 addition failures. Here is the patch:
 Index: tree.js
 ===
 --- tree.js   (revision 568693)
 +++ tree.js   (working copy)
 @@ -46,7 +46,7 @@
  
  Wicket.Tree.createElement = function(elementId, afterId) {
   var existing = Wicket.$(elementId);
 - if (typeof(existing) != undefined  exiting != null) {
 + if (typeof(existing) != undefined  existing != null) {
   Wicket.Tree.askForReload();
   }

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

[jira] Resolved: (WICKET-873) Constructor of Component not DRY?

2007-08-23 Thread Alastair Maw (JIRA) 

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

Alastair Maw resolved WICKET-873.
-

Resolution: Invalid

Please don't ask questions like this in the bug tracker. Post to the mailing 
list instead.

 Constructor of Component not DRY?
 -

 Key: WICKET-873
 URL: https://issues.apache.org/jira/browse/WICKET-873
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Reporter: Martin Funk

 Probably I'm missing something, but what's the reason for the two 
 constructors of org/apache/wicket/Component.java
 not to follow the DRY principle.
 In my schoolbook driven aproach I'd do constructor chaining like this:
 Index: jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
 ===
 --- jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java   
 (Revision 568743)
 +++ jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java   
 (Arbeitskopie)
 @@ -724,15 +724,7 @@
  */
 public Component(final String id)
 {
 -   setId(id);
 -   getApplication().notifyComponentInstantiationListeners(this);
 -
 -   final IDebugSettings debugSettings = 
 Application.get().getDebugSettings();
 -   if 
 (debugSettings.isLinePreciseReportingOnNewComponentEnabled())
 -   {
 -   setMetaData(CONSTRUCTED_AT_KEY, 
 Strings.toString(this, new MarkupException(
 -   constructed)));
 -   }
 +   this(id, null);
 }
  
 /**

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

svn commit: r569002 - in /wicket/trunk/jdk-1.4/wicket/src: main/java/org/apache/wicket/protocol/http/ test/java/ test/java/org/apache/wicket/protocol/http/

2007-08-23 Thread jbq 
Author: jbq
Date: Thu Aug 23 07:10:34 2007
New Revision: 569002

URL: http://svn.apache.org/viewvc?rev=569002view=rev
Log:
WICKET-702 MockWebApplication doesn't redirect properly to mounted pages under 
RestartResponseAtInterceptPageException

Use a cross-platform way to remove .. in the path

Added:

wicket/trunk/jdk-1.4/wicket/src/test/java/org/apache/wicket/protocol/http/RequestUtilsTest.java
   (with props)
Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/RequestUtils.java
wicket/trunk/jdk-1.4/wicket/src/test/java/log4j.properties

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java?rev=569002r1=569001r2=569002view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockHttpServletRequest.java
 Thu Aug 23 07:10:34 2007
@@ -23,7 +23,6 @@
 import java.io.FileInputStream;
 import java.io.IOException;
 import java.io.OutputStream;
-import java.io.StringWriter;
 import java.io.UnsupportedEncodingException;
 import java.net.URLEncoder;
 import java.security.Principal;
@@ -1294,18 +1293,11 @@
// We need to absolutize the redirect URL as we are not as 
smart as a web-browser (WICKET-702)
url = getContextPath() + getServletPath() + / + redirect;
 
-   try
-   {
-   // Remove occurences of .. from the path
-   url = new File(url).getCanonicalPath();
-   }
-   catch (IOException e)
-   {
-   throw new RuntimeException(e);
-   }
+   // Remove occurences of .. from the path
+   url = RequestUtils.removeDoubleDots(url);
log.info(Redirecting to  + url);
}
-
+   
/**
 * Helper method to create some default headers for the request
 */

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/RequestUtils.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/RequestUtils.java?rev=569002r1=569001r2=569002view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/RequestUtils.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/RequestUtils.java
 Thu Aug 23 07:10:34 2007
@@ -18,7 +18,11 @@
 
 import java.io.UnsupportedEncodingException;
 import java.net.URLDecoder;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
 
+import org.apache.wicket.util.string.Strings;
 import org.apache.wicket.util.value.ValueMap;
 
 /**
@@ -59,6 +63,36 @@
// Should never happen
}
}
+   }
+
+   /**
+* Remove occurences of .. from the path
+* @param path
+* @return
+*/
+   static String removeDoubleDots(String path)
+   {
+   String[] components = path.split(/);
+   List newcomponents = new ArrayList(Arrays.asList(components));
+
+   for (int i=0; icomponents.length; i++)
+   {
+   if (icomponents.length-1)
+   {
+   // Verify for a .. component at next iteration
+   if (components[i].length()  0  
components[i+1].equals(..))
+   {
+   newcomponents.remove(i);
+   newcomponents.remove(i);
+   // Skip the .. component
+   i++;
+   }
+   }
+   }
+   String newpath = Strings.join(/, 
(String[])newcomponents.toArray(new String[0]));
+   if (path.endsWith(/))
+   return newpath + /;
+   return newpath;
}
 
/**

Modified: wicket/trunk/jdk-1.4/wicket/src/test/java/log4j.properties
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/test/java/log4j.properties?rev=569002r1=569001r2=569002view=diff
==
--- wicket/trunk/jdk-1.4/wicket/src/test/java/log4j.properties (original)
+++ wicket/trunk/jdk-1.4/wicket/src/test/java/log4j.properties

[jira] Created: (WICKET-877) stateless page + form + bookmark = trouble

2007-08-23 Thread Peter Ertl (JIRA) 
stateless page + form + bookmark = trouble
--

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


I have a stateless login page for the application (using 
HybridUrlCodingStrategy):

   url_1 = http://localhost/login

When I press the login button of the username + password form the form data 
will be sent using HTTP POST:

  url_2 = 
http://localhost/login/wicket:interface/%3A0%3AnavigationContrib%3Aform%3A%3AIFormSubmitListener%3A%3A/

Unfortunately, if somebody bookmarks url_2 (which is stupid as we java dudes 
all know, but it _will_ happen because average users don't know better) the 
form submit listener will be invoked using HTTP GET and having no form 
parameters. *imho* bookmarks should be possible in a professional application 
at all time.

This, of course, will result in an ugly error message and unexpected 
application behavior and empty form fields and stuff. That's *btw* why I 
declare this request a bug and not a feature / enhancement.

I think it would be cool to have Form#onInvalidSubmit() to handle this kind of 
stuff (it won't happen on stateful pages with redirect after post enabled). So, 
for example, the application could just reload to the login page.

detection is easy... here my suggestion:

--
class org.apache.wicket.markup.html.form.Form:

public final void onFormSubmitted()  // line 746
{
final String method = ((WebRequest) 
getRequest()).getHttpServletRequest().getMethod();

if (method.equalsIgnoreCase(this.getMethod()) == false)
  this.onInvalidSubmit();

// ...
}

// override (optional)
protected onInvalidSubmit() {}

--

in my case I would just do this:

@Override
protected onInvalidSubmit()
{
  this.setRedirect(true);
  throw new RestartResponseException(getPage().getClass());
}

This would probably be a good default behavior for StatelessForm

I consider this change useful enough to be part of wicket core.

What you guys think?

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

[jira] Commented: (WICKET-847) setResponsePage redirects to wrong url

2007-08-23 Thread Andrew Klochkov (JIRA) 

[ 
https://issues.apache.org/jira/browse/WICKET-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522187
 ] 

Andrew Klochkov commented on WICKET-847:


The evil code is in the WebRequestCodingStrategy class:

// We need to special-case links to the home page if 
we're at the
// same level.
if (result.length() == 0)
{
result = ./;
}

A workaround is to override newWebResponse in Application subclass to prevent 
such redirects

pre
protected WebResponse newWebResponse(HttpServletResponse 
servletResponse)
{
return new BufferedWebResponse(servletResponse) {

public CharSequence encodeURL(CharSequence url)
{
return ./.equals(url) ?  : 
super.encodeURL(url);
}

};
}
/pre

 setResponsePage redirects to wrong url
 --

 Key: WICKET-847
 URL: https://issues.apache.org/jira/browse/WICKET-847
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta2
Reporter: Andrew Klochkov
Assignee: Alastair Maw
 Fix For: 1.3.0-rc1

 Attachments: wicket-quickstart.tar.gz


 When I do setResponsePage(MyHomePage.class) IE tries to show me 
 my.site.com/./ url and gets 404 response. 
 Firefox just shows my.site.com without any troubles. I'm using wicket 
 1.3-beta2 and WicketFilter mapped to /*. 
 It's being reproduced under tomcat only, jetty works fine. My tomcat version 
 is 5.5.17. 
 Quickstart project which reproduces the bug is attached.

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

svn commit: r569071 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/behavior/AbstractBehavior.java

2007-08-23 Thread ivaynberg 
Author: ivaynberg
Date: Thu Aug 23 09:55:28 2007
New Revision: 569071

URL: http://svn.apache.org/viewvc?rev=569071view=rev
Log:
better isenabled() for behavior

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/behavior/AbstractBehavior.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/behavior/AbstractBehavior.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/behavior/AbstractBehavior.java?rev=569071r1=569070r2=569071view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/behavior/AbstractBehavior.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/behavior/AbstractBehavior.java
 Thu Aug 23 09:55:28 2007
@@ -154,7 +154,7 @@
 */
public boolean isEnabled(Component component)
{
-   return component.isEnabled();
+   return true;
}
 
/**

[jira] Assigned: (WICKET-851) WicketTester unusable after subsequent startPage(Page) call

2007-08-23 Thread Jean-Baptiste Quenot (JIRA) 

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

Jean-Baptiste Quenot reassigned WICKET-851:
---

Assignee: Jean-Baptiste Quenot

 WicketTester unusable after subsequent startPage(Page) call
 ---

 Key: WICKET-851
 URL: https://issues.apache.org/jira/browse/WICKET-851
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta2
Reporter: Roy van Rijn
Assignee: Jean-Baptiste Quenot
Priority: Minor
 Fix For: 1.3.0-beta4

 Attachments: wickettestertestfailure.patch


 When adding two unit-tests to the WicketTesterTest for issue WICKET-848 I ran 
 into the following problem (see patch).

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

[jira] Commented: (WICKET-874) Reloading servlet doing way too much reloading

2007-08-23 Thread Carlos Pita (JIRA) 

[ 
https://issues.apache.org/jira/browse/WICKET-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1259
 ] 

Carlos Pita commented on WICKET-874:


Thanks a bunch JB, now it seems to go with flying colors!



 Reloading servlet doing way too much reloading
 --

 Key: WICKET-874
 URL: https://issues.apache.org/jira/browse/WICKET-874
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta2, 1.3.0-beta3
Reporter: Carlos Pita
Assignee: Jean-Baptiste Quenot
 Fix For: 1.3.0-beta4


 As our project gets bigger in terms of number of classes the reloading 
 servlet is not only becoming slower (it seems as it's reloading a lot of 
 classes after each tiny change) but often incurring into sort of neverending 
 reloading loops. 

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

[jira] Updated: (WICKET-806) add month/year selection

2007-08-23 Thread Eelco Hillenius (JIRA) 

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

Eelco Hillenius updated WICKET-806:
---

Attachment: dump.png

Works fine for all browsers I tested except for Camino. Might be a camino issue 
with buttons though. Maybe using links would fix it.

 add month/year selection
 

 Key: WICKET-806
 URL: https://issues.apache.org/jira/browse/WICKET-806
 Project: Wicket
  Issue Type: New Feature
  Components: wicket-datetime
Affects Versions: 1.3.0-beta2
Reporter: Gerolf Seitz
Assignee: Eelco Hillenius
 Fix For: 1.3.0-beta4

 Attachments: dump.png, dump.png, dump2.png, 
 month_year_selection.patch, month_year_selection.patch, 
 month_year_selection.patch, month_year_selection.patch, 
 screenshot-ff-osx.png, screenshot-ff-winxp.jpg, YearMonthSelection.patch, 
 YearSpinnerMonthSelection.patch


 for faster navigation, direct month and year selection should be provided.
 to avoid parsing (wrong) user input, select boxes should be used.

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

[jira] Updated: (WICKET-879) reduce code in DatePicker.js (because it can be loaded multiple times per page)

2007-08-23 Thread Gerolf Seitz (JIRA) 

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

Gerolf Seitz updated WICKET-879:


Attachment: size_reduction.patch

 reduce code in DatePicker.js (because it can be loaded multiple times per 
 page)
 ---

 Key: WICKET-879
 URL: https://issues.apache.org/jira/browse/WICKET-879
 Project: Wicket
  Issue Type: Improvement
  Components: wicket-datetime
Affects Versions: 1.3.0-beta2
Reporter: Gerolf Seitz
Priority: Trivial
 Fix For: 1.3.0-beta4

 Attachments: size_reduction.patch


 everytime the DatePicker behavior is added to a component, the file 
 DatePicker.js is rendered to the head (with interpolated vars that are 
 specific for each DatePicker instance).
 some of the code (actually only the code in the function 
 init${widgetId}DpJs()) can be moved to wicket-date.js
 the rest of the code is used for the yuiloader and can't be moved to 
 wicket-date.js, since the loader actually loads this file.

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

[jira] Commented: (WICKET-876) Assigning Label to anchor tag in recursive ListView causes exponential performance decay

2007-08-23 Thread Nick Johnson (JIRA) 

[ 
https://issues.apache.org/jira/browse/WICKET-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522294
 ] 

Nick Johnson commented on WICKET-876:
-

As an aside, I was incorrect in identifying the rate of decay as exponential; 
it's actually polynomial, following the formula (n + n^2) / 2.  (O(n^2)) Bad 
enough to be very noticeable, but very easy to correct.

Thanks for the explanation!

 Assigning Label to anchor tag in recursive ListView causes exponential 
 performance decay
 

 Key: WICKET-876
 URL: https://issues.apache.org/jira/browse/WICKET-876
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.2.6
Reporter: Nick Johnson
Assignee: Igor Vaynberg
Priority: Trivial

 This isn't so much a bug as a curiosity, and I'm partially just documenting 
 this in case someone else runs across the same problem later and searches the 
 bug database for clues.  It -would- be interesting to figure out why it 
 happens.  The workaround is trivial.
 If the markup for a recursive list view (like the recursive panel in the 
 examples) contains a named anchor like this:
 a name=x wicket:id=anchor /a
 And the anchor is (inappropriately) associated with a Label like this:
 add(new Label(anchor).add(new SimpleAttributeModifier(name,foo)));
 Then as the levels of recursion deepen, performance during rendering decays 
 exponentially.  During this time, the Java process will also start consuming 
 a tremendous amount of CPU.
 The solution is fairly simple: don't use a Label for situations like this; 
 instead, use a WebMarkupContainer:
 add(new WebMarkupContainer(anchor).add(new 
 SimpleAttributeModifier(name,foo)));
 With the component being WebMarkupContainer, performance does not degrade 
 exponentially.  With Label, it does.  I'm afraid I don't know enough of the 
 internal workings of Wicket to speculate as to why.

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

[jira] Created: (WICKET-882) RefreshingView should call super.onBeforeRender after it refreshed it's items.

2007-08-23 Thread Eelco Hillenius (JIRA) 
RefreshingView should call super.onBeforeRender after it refreshed it's items.
--

 Key: WICKET-882
 URL: https://issues.apache.org/jira/browse/WICKET-882
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta2
Reporter: Eelco Hillenius
 Fix For: 1.3.0-beta3


RefreshingView should call super.onBeforeRender after it refreshed it's items.

Right now, it first visits all it's children, even if those children will be 
removed right after the call, and it misses any children that got added 
directly.

I found out about this because of the recent change where beforeRender calls 
isVisible, and I had a component in a RefreshingView that had an implementation 
of isVisible that depended on it's model value, and another component that 
removes an item in the datamodel that backs the RefreshingView. When an item 
was removed, beforeRender was still executed on the child with the now stale 
reference to the data model, resulting in an exception 

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

[jira] Commented: (WICKET-882) RefreshingView should call super.onBeforeRender after it refreshed it's items.

2007-08-23 Thread Eelco Hillenius (JIRA) 

[ 
https://issues.apache.org/jira/browse/WICKET-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522311
 ] 

Eelco Hillenius commented on WICKET-882:


Same thing goes for SelectOptions, Loop and possibly AjaxEditableLabel and 
ModalWindow. It is probably the safer default anyway.

 RefreshingView should call super.onBeforeRender after it refreshed it's items.
 --

 Key: WICKET-882
 URL: https://issues.apache.org/jira/browse/WICKET-882
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta2
Reporter: Eelco Hillenius
 Fix For: 1.3.0-beta3


 RefreshingView should call super.onBeforeRender after it refreshed it's items.
 Right now, it first visits all it's children, even if those children will be 
 removed right after the call, and it misses any children that got added 
 directly.
 I found out about this because of the recent change where beforeRender calls 
 isVisible, and I had a component in a RefreshingView that had an 
 implementation of isVisible that depended on it's model value, and another 
 component that removes an item in the datamodel that backs the 
 RefreshingView. When an item was removed, beforeRender was still executed on 
 the child with the now stale reference to the data model, resulting in an 
 exception 

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

[jira] Commented: (WICKET-882) RefreshingView should call super.onBeforeRender after it refreshed it's items.

2007-08-23 Thread Igor Vaynberg (JIRA) 

[ 
https://issues.apache.org/jira/browse/WICKET-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522337
 ] 

Igor Vaynberg commented on WICKET-882:
--

ive made the change. matej and i had already tweaked onbeforerender for this 
usecase and fixed it in listview, just forgot to go through the rest of the 
framework.

i am thinking about adding abstract void abstractrepeater.updateitems() and 
onbeforerender() { updateitems(); super.onbeforerender(); } just to make this 
more pragmatic. any objections?

 RefreshingView should call super.onBeforeRender after it refreshed it's items.
 --

 Key: WICKET-882
 URL: https://issues.apache.org/jira/browse/WICKET-882
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta2
Reporter: Eelco Hillenius
Assignee: Igor Vaynberg
 Fix For: 1.3.0-beta3


 RefreshingView should call super.onBeforeRender after it refreshed it's items.
 Right now, it first visits all it's children, even if those children will be 
 removed right after the call, and it misses any children that got added 
 directly.
 I found out about this because of the recent change where beforeRender calls 
 isVisible, and I had a component in a RefreshingView that had an 
 implementation of isVisible that depended on it's model value, and another 
 component that removes an item in the datamodel that backs the 
 RefreshingView. When an item was removed, beforeRender was still executed on 
 the child with the now stale reference to the data model, resulting in an 
 exception 

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

[jira] Commented: (WICKET-882) RefreshingView should call super.onBeforeRender after it refreshed it's items.

2007-08-23 Thread Igor Vaynberg (JIRA) 

[ 
https://issues.apache.org/jira/browse/WICKET-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522354
 ] 

Igor Vaynberg commented on WICKET-882:
--

select options extends repeating view which extends abstractrepeater, so it 
should be good

 RefreshingView should call super.onBeforeRender after it refreshed it's items.
 --

 Key: WICKET-882
 URL: https://issues.apache.org/jira/browse/WICKET-882
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.3.0-beta2
Reporter: Eelco Hillenius
Assignee: Igor Vaynberg
 Fix For: 1.3.0-beta3


 RefreshingView should call super.onBeforeRender after it refreshed it's items.
 Right now, it first visits all it's children, even if those children will be 
 removed right after the call, and it misses any children that got added 
 directly.
 I found out about this because of the recent change where beforeRender calls 
 isVisible, and I had a component in a RefreshingView that had an 
 implementation of isVisible that depended on it's model value, and another 
 component that removes an item in the datamodel that backs the 
 RefreshingView. When an item was removed, beforeRender was still executed on 
 the child with the now stale reference to the data model, resulting in an 
 exception 

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

[CONF] Apache Wicket: Rss Page (page edited)

2007-08-23 Thread confluence 










Page Edited :
WICKET :
Rss Page



 
Rss Page
has been edited by Ryan Sonnek
(Aug 23, 2007).
 

 
 (View changes)
 

Content:


This information is no longer relavent.  The Wicket Stuff project has a complete subproject devoted to creation of RSS/Atom feeds.  see: http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-rome











Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request

Unsubscribe or edit your notifications preferences

[CONF] Apache Wicket: Rss Page (page edited)

2007-08-23 Thread confluence 










Page Edited :
WICKET :
Rss Page



 
Rss Page
has been edited by Ryan Sonnek
(Aug 23, 2007).
 

 
 (View changes)
 

Content:


This information is no longer relavent.  The Wicket Stuff project has a full RSS/Atom component.  See the Wicket Stuff WIKI for more information:
http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket+FeedPage











Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request

Unsubscribe or edit your notifications preferences