date:20120221

[jira] [Commented] (WICKET-4371) Timer problems with Internet Explorer

2012-02-21 Thread Ari Suutari (Commented) (JIRA)

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

Ari Suutari commented on WICKET-4371:
-

I think there is a slight misunderstanding here. The issue is not caused by
browser requests coming to server in different order than sent by browser.
However, with pending javascript timer there are two different problem
scenarios:

1) User clicks link, request goes to server, it is processed by wicket
application and redirect response is sent back. After that javascript timer
fires. I think that the proposed patch handles this case very well.

2) User clicks link, request goes to server for processing. But before the
response is received by browser end the javascript timer fires a request to
server. This seems to confuse wicket application on server side, because it
might have completed redirect processing already. This results in some kind of
mismatch between application states in browser and server, the server thinks
that user wanted to go back to first page (because the timer request came from
that) but browser sits happily on new page. To handle this on browser side
ajax/javascript stuff it would be necessary to block timer
requests totally if there is some other ajax call in progress.

These problems occur more easily if network link is a little bit slow. That is
the reason for Mikko trying to demonstrate to problem for adding
delay into application code. Otherwise it would be difficult to hit correct
timeframe with clicking (in real application it might take tens of clicks to
hit the problem).

Regards,

Ari S.

Timer problems with Internet Explorer
-

Key: WICKET-4371
URL: https://issues.apache.org/jira/browse/WICKET-4371
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.19, 1.5.3, 1.5.4
Environment: Jetty/Apache Tomcat Internet Explorer
Reporter: Mikko Pukki
Assignee: Igor Vaynberg
Attachments: TimerProblem.zip, TimerProblem_take2.zip,
WICKET-4371.patch, wicket-4371-with_firefox.har

Hi,
We are encountering problems on all pages that have timers for
updating/polling new data.
It seems that if new page is rendering, timer's request can mess things up.
Problem can be
reproduced with Wicket 1.5.3 and 1.5.4
An example situation:
1) Page (id1) has a timer and user presses link (Request1) that forwards to a
new Page (future id2).
2) Request is being processed at server and page with id2 is rendered
3) While still in render phase timer makes new request to a server
Timer's request is handled even if there is a new rendered page. Timer's
request is now last request
handled and page that contained timer is last page stored at PageTable. This
causes weird problems with
our applications.
I'm wondering that why any request that is meant for previous versions of
pages are processed?
In quickstart rendering is slowed down with Thread.sleep, but network
latencies can and will create similar problems.
In the quickstart there is PageB -link. Pressing that invokes this behavior
There is also custom store in quickstart that provider simple debug logging.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (WICKET-4423) Modal Window dragging failes with iframe

2012-02-21 Thread Sven Meier (Created) (JIRA)

Modal Window dragging failes with iframe


 Key: WICKET-4423
 URL: https://issues.apache.org/jira/browse/WICKET-4423
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 6.0.0
Reporter: Sven Meier
Assignee: Sven Meier


Forwarding of mouse event from nested iframes seems to have stopped working. 
(see javascript Wicket.Iframe)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (WICKET-4418) Combine all JavaScript evaluations in one evaluate element for better performance at the client side

2012-02-21 Thread Martin Grigorov (Commented) (JIRA)


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

Martin Grigorov commented on WICKET-4418:
-

Here is a benchmark showing that Firefox is actually slower with combined eval, 
IE is the same, all other are faster with one eval.

http://jsperf.com/one-function-vs-several

 Combine all JavaScript evaluations in one evaluate element for better 
 performance at the client side
 --

 Key: WICKET-4418
 URL: https://issues.apache.org/jira/browse/WICKET-4418
 Project: Wicket
  Issue Type: Sub-task
  Components: wicket
Affects Versions: 6.0.0
Reporter: Martin Grigorov
Assignee: Martin Grigorov
 Fix For: 6.0.0


 Ajax response may contain several evaluate (and priority-evaluate) 
 elements which are eval-ed one by one when ajax-response is processed. This 
 can be improved by combining the bodies (the JS code) of all evaluates in 
 one bigger evaluate.
 See http://markmail.org/thread/qdgn4qvqp4kzuptb for the discussion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (WICKET-4424) getComponentFromLastRenderedPage appends componentInPage id when it shouldn't

2012-02-21 Thread Johannes Odland (Created) (JIRA)

getComponentFromLastRenderedPage appends componentInPage id when it shouldn't
-

 Key: WICKET-4424
 URL: https://issues.apache.org/jira/browse/WICKET-4424
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.4
Reporter: Johannes Odland
Priority: Minor



When using WicketTester#startComponentInPage with a component class, wicket 
will instantiate the component and give it an id.

As an example, a starting a panel with a link inside will generate these page 
relative paths:

testObject
testObject:link


This id is automatically generated by wicket and not known to the developer, 
wich makes it impossible for the developer to reference components by path, as 
the first segment of the path is unknown. 
To remedy this, wicket appends the id of the component to the path given by the 
developer in getComponentFromLastRenderedPage().

If the developer calls clickLink(link), getComponentFromLastRenderedPage will 
append the generated id and form the path testObject:link

This is OK as long as the developer explicitly gives the path, omitting the id 
of the component.

But, when retrieving the path from the components themselves this creates a 
problem. 
Say a developer is iterating through all links in the page and clicking them:

Link link = getLink();
wicketTester.clickLink(link.getPageRelativePath());

ClickLink is then called with the path testObject:link, and 
getComponentFromLastRenderedPage will append the generated id forming the path 
testObject:testObject:link wich clearly fails.



This is illustrated by a simple testcase:

@Test
public void clickShouldWork() {
  WicketTester tester = new WicketTester();
  tester.startComponentInPage(TestLink.class); 
  Link link = (Link) tester.getLastRenderedPage().get(0);
  String path = link.getPageRelativePath();
  wicketTester.clickLink(path);
}

public static class TestLink extends Link {
  public TestLink(String id) { super(id);}
  public void onClick() {}
}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: WICKET-4418 Combine all JavaScript evaluations in one evaluate element for better performance at the client side

2012-02-21 Thread mgrigorov

Updated Branches:
  refs/heads/master 3d2dfa75d - 36c90fa61


WICKET-4418 Combine all JavaScript evaluations in one evaluate element for 
better performance at the client side

Pass all scripts to XmlAjaxResponse so that it can decide how to render them - 
one by one or all in one evaluate.


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/36c90fa6
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/36c90fa6
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/36c90fa6

Branch: refs/heads/master
Commit: 36c90fa61dae547835a8205fba0dd5e1579c49dc
Parents: 3d2dfa7
Author: Martin Tzvetanov Grigorov mgrigo...@apache.org
Authored: Tue Feb 21 11:42:28 2012 +0100
Committer: Martin Tzvetanov Grigorov mgrigo...@apache.org
Committed: Tue Feb 21 11:42:28 2012 +0100

--
 .../apache/wicket/ajax/AbstractAjaxResponse.java   |   29 ---
 .../org/apache/wicket/ajax/AjaxRequestHandler.java |   11 ++
 .../org/apache/wicket/ajax/XmlAjaxResponse.java|   19 --
 3 files changed, 27 insertions(+), 32 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/36c90fa6/wicket-core/src/main/java/org/apache/wicket/ajax/AbstractAjaxResponse.java
--
diff --git 
a/wicket-core/src/main/java/org/apache/wicket/ajax/AbstractAjaxResponse.java 
b/wicket-core/src/main/java/org/apache/wicket/ajax/AbstractAjaxResponse.java
index 4f89b15..8cab7e1 100644
--- a/wicket-core/src/main/java/org/apache/wicket/ajax/AbstractAjaxResponse.java
+++ b/wicket-core/src/main/java/org/apache/wicket/ajax/AbstractAjaxResponse.java
@@ -16,6 +16,7 @@
  */
 package org.apache.wicket.ajax;
 
+import java.util.ArrayList;
 import java.util.Collection;
 import java.util.Collections;
 import java.util.Iterator;
@@ -146,28 +147,14 @@ abstract class AbstractAjaxResponse
 
// queue up prepend javascripts. unlike other steps these are 
executed out of order so that
// components can contribute them from inside their 
onbeforerender methods.
-   IteratorCharSequence it = prependJavaScripts.iterator();
-   while (it.hasNext())
-   {
-   CharSequence js = it.next();
-   writePriorityEvaluation(response, js);
-   }
+   writePriorityEvaluations(response, prependJavaScripts);
 
// execute the dom ready javascripts as first javascripts
// after component replacement
-   it = domReadyJavaScripts.iterator();
-   while (it.hasNext())
-   {
-   CharSequence js = it.next();
-   writeNormalEvaluation(response, js);
-   }
-
-   it = appendJavaScripts.iterator();
-   while (it.hasNext())
-   {
-   CharSequence js = it.next();
-   writeNormalEvaluation(response, js);
-   }
+   ListCharSequence evaluationScripts = new 
ArrayListCharSequence();
+   evaluationScripts.addAll(domReadyJavaScripts);
+   evaluationScripts.addAll(appendJavaScripts);
+   writeNormalEvaluations(response, evaluationScripts);
 
writeFooter(response, encoding);
}
@@ -191,7 +178,7 @@ abstract class AbstractAjaxResponse
 * @param js
 *  the JavaScript to evaluate
 */
-   protected abstract void writePriorityEvaluation(Response response, 
CharSequence js);
+   protected abstract void writePriorityEvaluations(Response response, 
CollectionCharSequence js);
 
/**
 *
@@ -200,7 +187,7 @@ abstract class AbstractAjaxResponse
 * @param js
 *  the JavaScript to evaluate
 */
-   protected abstract void writeNormalEvaluation(Response response, 
CharSequence js);
+   protected abstract void writeNormalEvaluations(Response response, 
CollectionCharSequence js);
 
/**
 * Processes components added to the target. This involves attaching 
components, rendering

http://git-wip-us.apache.org/repos/asf/wicket/blob/36c90fa6/wicket-core/src/main/java/org/apache/wicket/ajax/AjaxRequestHandler.java
--
diff --git 
a/wicket-core/src/main/java/org/apache/wicket/ajax/AjaxRequestHandler.java 
b/wicket-core/src/main/java/org/apache/wicket/ajax/AjaxRequestHandler.java
index 7a349ad..b9dffa9 100644
--- a/wicket-core/src/main/java/org/apache/wicket/ajax/AjaxRequestHandler.java
+++ b/wicket-core/src/main/java/org/apache/wicket/ajax/AjaxRequestHandler.java
@@ -48,8 +48,6 @@ import org.apache.wicket.util.string.AppendingStringBuffer;
 import

[jira] [Resolved] (WICKET-4418) Combine all JavaScript evaluations in one evaluate element for better performance at the client side

2012-02-21 Thread Martin Grigorov (Resolved) (JIRA)


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

Martin Grigorov resolved WICKET-4418.
-

   Resolution: Won't Fix
Fix Version/s: (was: 6.0.0)

We wont do this suggestion because it is slower for Firefox and doesn't give 
much for the other browsers (except WebKit based ones).

I changed the API of org.apache.wicket.ajax.AbstractAjaxResponse so that it is 
possible to add such optimizations later.

 Combine all JavaScript evaluations in one evaluate element for better 
 performance at the client side
 --

 Key: WICKET-4418
 URL: https://issues.apache.org/jira/browse/WICKET-4418
 Project: Wicket
  Issue Type: Sub-task
  Components: wicket
Affects Versions: 6.0.0
Reporter: Martin Grigorov
Assignee: Martin Grigorov

 Ajax response may contain several evaluate (and priority-evaluate) 
 elements which are eval-ed one by one when ajax-response is processed. This 
 can be improved by combining the bodies (the JS code) of all evaluates in 
 one bigger evaluate.
 See http://markmail.org/thread/qdgn4qvqp4kzuptb for the discussion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (WICKET-4418) Combine all JavaScript evaluations in one evaluate element for better performance at the client side

2012-02-21 Thread Martin Grigorov (Commented) (JIRA)


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

Martin Grigorov commented on WICKET-4418:
-

Actually it is not even possible to execute something like: eval(function() { 
console.log(1); }();)
It seems it is not possible to run anonymous function in an eval.

 Combine all JavaScript evaluations in one evaluate element for better 
 performance at the client side
 --

 Key: WICKET-4418
 URL: https://issues.apache.org/jira/browse/WICKET-4418
 Project: Wicket
  Issue Type: Sub-task
  Components: wicket
Affects Versions: 6.0.0
Reporter: Martin Grigorov
Assignee: Martin Grigorov

 Ajax response may contain several evaluate (and priority-evaluate) 
 elements which are eval-ed one by one when ajax-response is processed. This 
 can be improved by combining the bodies (the JS code) of all evaluates in 
 one bigger evaluate.
 See http://markmail.org/thread/qdgn4qvqp4kzuptb for the discussion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (WICKET-4418) Combine all JavaScript evaluations in one evaluate element for better performance at the client side

2012-02-21 Thread Christoph Leiter (Commented) (JIRA)


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

Christoph Leiter commented on WICKET-4418:
--

Use eval((function() { console.log(1); })(););

 Combine all JavaScript evaluations in one evaluate element for better 
 performance at the client side
 --

 Key: WICKET-4418
 URL: https://issues.apache.org/jira/browse/WICKET-4418
 Project: Wicket
  Issue Type: Sub-task
  Components: wicket
Affects Versions: 6.0.0
Reporter: Martin Grigorov
Assignee: Martin Grigorov

 Ajax response may contain several evaluate (and priority-evaluate) 
 elements which are eval-ed one by one when ajax-response is processed. This 
 can be improved by combining the bodies (the JS code) of all evaluates in 
 one bigger evaluate.
 See http://markmail.org/thread/qdgn4qvqp4kzuptb for the discussion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: WICKET-4422 Minimize Wicket's Ajax JavaScript files at build time

2012-02-21 Thread mgrigorov

Updated Branches:
  refs/heads/master 36c90fa61 - 99eec004e


WICKET-4422 Minimize Wicket's Ajax JavaScript files at build time

Use Yahoo compressor to minimize our .js and .css resources


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/99eec004
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/99eec004
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/99eec004

Branch: refs/heads/master
Commit: 99eec004ea31b4830ff03de54addffb4355800c1
Parents: 36c90fa
Author: Martin Tzvetanov Grigorov mgrigo...@apache.org
Authored: Tue Feb 21 13:50:32 2012 +0100
Committer: Martin Tzvetanov Grigorov mgrigo...@apache.org
Committed: Tue Feb 21 13:50:32 2012 +0100

--
 pom.xml|   23 +--
 wicket-core/pom.xml|   11 ++-
 .../markup/html/form/AbstractCheckSelector.java|3 +-
 .../wicket/markup/html/form/CheckBoxSelector.java  |3 +-
 .../markup/html/form/CheckGroupSelector.java   |3 +-
 .../html/form/CheckboxMultipleChoiceSelector.java  |3 +-
 .../html/form/upload/MultiFileUploadField.java |3 +-
 wicket-extensions/pom.xml  |8 +
 .../autocomplete/AbstractAutoCompleteBehavior.java |4 +-
 .../DefaultCssAutoCompleteTextField.java   |6 ++--
 .../markup/html/form/upload/UploadProgressBar.java |9 +++--
 .../ajax/markup/html/modal/ModalWindow.java|8 ++--
 .../markup/html/form/palette/Palette.java  |   10 +++---
 .../html/repeater/tree/theme/HumanTheme.java   |4 +-
 .../html/repeater/tree/theme/WindowsTheme.java |4 +-
 .../extensions/markup/html/tree/AbstractTree.java  |4 +-
 .../extensions/markup/html/tree/BaseTree.java  |4 +-
 .../markup/html/tree/DefaultAbstractTree.java  |3 +-
 .../markup/html/tree/table/TreeTable.java  |4 +-
 .../wicket/extensions/rating/RatingPanel.java  |5 ++-
 .../apache/wicket/extensions/wizard/Wizard.java|   10 +++---
 21 files changed, 87 insertions(+), 45 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/99eec004/pom.xml
--
diff --git a/pom.xml b/pom.xml
index af1c8dc..2f3fb84 100644
--- a/pom.xml
+++ b/pom.xml
@@ -7,7 +7,7 @@
(the License); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at
 
-http://www.apache.org/licenses/LICENSE-2.0
+   http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
@@ -114,7 +114,7 @@
plugin

groupIdorg.apache.maven.plugins/groupId

artifactIdmaven-surefire-plugin/artifactId
-   inheritedtrue/inherited
+   inheritedtrue/inherited
configuration

excludedGroupsorg.apache.wicket.util.SlowTests/excludedGroups
/configuration
@@ -127,7 +127,7 @@
plugin

groupIdorg.apache.maven.plugins/groupId

artifactIdmaven-javadoc-plugin/artifactId
-   inheritedtrue/inherited
+   inheritedtrue/inherited
configuration
skiptrue/skip
/configuration
@@ -758,6 +758,23 @@

artifactIdmaven-archetype-plugin/artifactId
version2.0/version
/plugin
+   plugin
+   groupIdnet.alchim31.maven/groupId
+   
artifactIdyuicompressor-maven-plugin/artifactId
+   version1.3.0/version
+   configuration
+   statisticstrue/statistics
+   jswarnfalse/jswarn
+   suffix.min/suffix
+   /configuration
+   executions
+

[jira] [Resolved] (WICKET-4422) Minimize Wicket's Ajax JavaScript files at build time

2012-02-21 Thread Martin Grigorov (Resolved) (JIRA)


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

Martin Grigorov resolved WICKET-4422.
-

Resolution: Fixed
  Assignee: Martin Grigorov

All JS and CSS resources in -core and -extensions now are compressed with Yahoo 
compressor at build time.

 Minimize Wicket's Ajax JavaScript files at build time
 -

 Key: WICKET-4422
 URL: https://issues.apache.org/jira/browse/WICKET-4422
 Project: Wicket
  Issue Type: Sub-task
  Components: wicket
Affects Versions: 6.0.0
Reporter: Martin Grigorov
Assignee: Martin Grigorov
 Fix For: 6.0.0


 wicket-ajax-jquery.js, wicket-event-jquery.js, ... are loaded with 
 MinifiedAwareJavaScriptResourceReference but they don't have .min.js version 
 and these leads to warning messages in production mode.
 We can use Maven plugin with Yahoo compressor, Google Closure compiler or 
 another to do that at build time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

buildbot failure in ASF Buildbot on wicket-master

2012-02-21 Thread buildbot

The Buildbot has detected a new failure on builder wicket-master while building 
wicket.
Full details are available at:
 http://ci.apache.org/builders/wicket-master/builds/196

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: hemera_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch master] 99eec004ea31b4830ff03de54addffb4355800c1
Blamelist: Martin Tzvetanov Grigorov mgrigo...@apache.org

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

git commit: WICKET-4422 Minimize Wicket's Ajax JavaScript files at build time

2012-02-21 Thread mgrigorov

Updated Branches:
  refs/heads/master 99eec004e - 59da20da4


WICKET-4422 Minimize Wicket's Ajax JavaScript files at build time

Revert the indents in the pom.xml files changed by my editor


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/59da20da
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/59da20da
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/59da20da

Branch: refs/heads/master
Commit: 59da20da4adb47c575860588c007d87f3a30b4a4
Parents: 99eec00
Author: Martin Tzvetanov Grigorov mgrigo...@apache.org
Authored: Tue Feb 21 13:58:29 2012 +0100
Committer: Martin Tzvetanov Grigorov mgrigo...@apache.org
Committed: Tue Feb 21 13:58:29 2012 +0100

--
 pom.xml |2 +-
 wicket-core/pom.xml |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/59da20da/pom.xml
--
diff --git a/pom.xml b/pom.xml
index 2f3fb84..9409ad0 100644
--- a/pom.xml
+++ b/pom.xml
@@ -7,7 +7,7 @@
(the License); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at
 
-   http://www.apache.org/licenses/LICENSE-2.0
+http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,

http://git-wip-us.apache.org/repos/asf/wicket/blob/59da20da/wicket-core/pom.xml
--
diff --git a/wicket-core/pom.xml b/wicket-core/pom.xml
index 96feeb2..c007e17 100644
--- a/wicket-core/pom.xml
+++ b/wicket-core/pom.xml
@@ -7,7 +7,7 @@
(the License); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at
 
-   http://www.apache.org/licenses/LICENSE-2.0
+http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,

buildbot success in ASF Buildbot on wicket-master

2012-02-21 Thread buildbot

The Buildbot has detected a restored build on builder wicket-master while 
building wicket.
Full details are available at:
 http://ci.apache.org/builders/wicket-master/builds/197

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: hemera_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch master] 59da20da4adb47c575860588c007d87f3a30b4a4
Blamelist: Martin Tzvetanov Grigorov mgrigo...@apache.org

Build succeeded!

sincerely,
 -The Buildbot

[CONF] Apache Wicket Migration to Wicket 6.0

2012-02-21 Thread confluence








Migration to Wicket 6.0
Page edited by Martin Grigorov


Comment:
Add an entry about minified aware resource references


 Changes (1)
 




...
 All IInitializer classes configured in wicket.properties are initialized *before* the call to Application#init(). This way the application has the control to re-configure something that comes from external library. [WICKET-4088|https://issues.apache.org/jira/browse/WICKET-4088] 
 h3. PackageResourceReference that can load a compressed version of a package resource  org.apache.wicket.resource.MinifiedAwareCssResourceReference and org.apache.wicket.resource.MinifiedAwareJavaScriptResourceReference are introduced. Their usage is the same as _javascript_ResourceReference. The difference is that in development mode they will load _resource.ext_ using the provided name while in production mode they will try to load _resource_*.min*_.ext_ by automatically inserting +.min+ right before the extension. If there is no such resource with that name then it will log a warning and fall back to the non-compressed version. 


Full Content

Migrating to Wicket 6.0



Environment
Repeaters
Form Processing

Validation
Feedback Storage Refactoring

Ajax

Use JQuery as a backing library for Wicket Ajax functionality
AjaxRequestTarget is an interface

IHeaderResponse, including decorators and filters
Order of Header contributions and wicket:head
package.properties renamed to wicket-package.properties
List of renamed classes and methods
Refactorings
o.a.w.IComponentSource and o.a.w.ComponentSourceEntry are removed
o.a.w.Component#onMarkupAttached() has been dropped in favour of o.a.w.Component#onInitialize().
IInitializers are initialized before Application#init()
PackageResourceReference that can load a compressed version of a package resource


Environment


	Wicket 6.0 requires at least Java 6




Repeaters

	`IDataProvider` was converted to using `long` instead of `int` to better line up with JPA and other persistence frameworks. This has caused a rather large cascade of `int` to `long` changes all over the repeater packages (WICKET-1175).



Form Processing

Validation


	`StringValidator` will add the `maxlength` attribute if added to a component attached to an input tag
	`AbstractValidator` has been removed
	`ValidationError` now makes creating standard error keys (classname and classname.subtype) easier. Before one had to do: new ValidationError().addMessageKey(validator.getClass().getSimpleName()) to construct the default key, now you can simply say new ValidationError(validator) and it will do the above for you. Also, for more specific keys one had to do new ValidationError().addMessageKey(validator.getClass().getSimpleName()+".variant"), now you can do new ValidationError(validator, "variant").
	Most validators provide a `decorate(ValidationError, Validatable)` method for overriding how they report errors. For example, to add an extra resource key for the error message to StringValidator one can do 


class MyStringValidator extends StringValidator {
ValidationError decoreate(ValidationError error, IValidatable validatable) {
   error.addKey("mystringerror");
   return error;
}
}





Feedback Storage Refactoring


	Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705.
	Previously the cleanup of messages was controlled by RequestCycle#cleanupFeedbackMessages(), now it is controlled by an IFeedbackMessageFilter set via IApplicationSettings#setFeedbackMessageCleanupFilter(). When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed. The default filter will accept any rendered message, so by default feedback messages are removed once rendered.
	Form components will clear any stored messages when validate() is called. This will remove any unredered, but now stale, messages.
	Since messages are now stored in session and in component tree retrieving them is not as simple as Session.getFeedbackMessages(). To assist with this common usecase please see FeedbackCollector.
	In test land cleanup of feedback messages was controlled by RequestCycle#set/isCleanupFeedbackMessagesOnDetach(), but this method is now deprecated. Instead, in testland you can now call WicketTester#cleanupFeedbackMessages() to clean up message just like it would be done at the end of a request. Alternatively, WicketTester#clearFeedbackMessages() can be used to clear all feedback messages. By default WicketTester will not clean any feedback messages.



Ajax

Use JQuery as a

git commit: WICKET-4424 getComponentFromLastRenderedPage appends componentInPage id when it shouldn't

2012-02-21 Thread mgrigorov

Updated Branches:
  refs/heads/master 59da20da4 - 47d4674b5


WICKET-4424 getComponentFromLastRenderedPage appends componentInPage id when it 
shouldn't


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/47d4674b
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/47d4674b
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/47d4674b

Branch: refs/heads/master
Commit: 47d4674b5d7ba1badcb488cb4ef2c3bbcf9bc0fe
Parents: 59da20d
Author: Martin Tzvetanov Grigorov mgrigo...@apache.org
Authored: Tue Feb 21 14:36:45 2012 +0100
Committer: Martin Tzvetanov Grigorov mgrigo...@apache.org
Committed: Tue Feb 21 14:36:45 2012 +0100

--
 .../wicket/util/tester/BaseWicketTester.java   |   35 +-
 1 files changed, 32 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/47d4674b/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
--
diff --git 
a/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java 
b/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
index f6e771a..e400de3 100644
--- 
a/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
+++ 
b/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
@@ -42,7 +42,6 @@ import javax.servlet.http.Cookie;
 import javax.servlet.http.HttpSession;
 
 import junit.framework.AssertionFailedError;
-
 import org.apache.wicket.Application;
 import org.apache.wicket.Component;
 import org.apache.wicket.IPageManagerProvider;
@@ -64,8 +63,8 @@ import org.apache.wicket.ajax.markup.html.AjaxLink;
 import org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink;
 import org.apache.wicket.behavior.AbstractAjaxBehavior;
 import org.apache.wicket.behavior.Behavior;
-import org.apache.wicket.feedback.FeedbackMessage;
 import org.apache.wicket.feedback.FeedbackCollector;
+import org.apache.wicket.feedback.FeedbackMessage;
 import org.apache.wicket.feedback.IFeedbackMessageFilter;
 import org.apache.wicket.markup.ContainerInfo;
 import org.apache.wicket.markup.IMarkupFragment;
@@ -1184,12 +1183,19 @@ public class BaseWicketTester
/**
 * Process a component. A web page will be automatically created with 
the markup created in
 * {@link #createPageMarkup(String)}.
+* p
+* strongNote/strong: the instantiated component will have an 
auto-generated id. To
+* reach any of its children use their relative path to the 
component itself. For example
+* if the started component has a child a Link component with id 
link then after starting
+* the component you can click it with: 
codetester.clickLink(link)/code
+* /p
 * 
 * @param C
 *the type of the component
 * @param componentClass
 *the class of the component to be tested
 * @return The component processed
+* @see #startComponentInPage(org.apache.wicket.Component)
 */
public final C extends Component C startComponentInPage(final 
ClassC componentClass)
{
@@ -1200,6 +1206,12 @@ public class BaseWicketTester
 * Process a component. A web page will be automatically created with 
the {@code pageMarkup}
 * provided. In case pageMarkup is null, the markup will be 
automatically created with
 * {@link #createPageMarkup(String)}.
+* p
+* strongNote/strong: the instantiated component will have an 
auto-generated id. To
+* reach any of its children use their relative path to the 
component itself. For example
+* if the started component has a child a Link component with id 
link then after starting
+* the component you can click it with: 
codetester.clickLink(link)/code
+* /p
 * 
 * @param C
 *the type of the component
@@ -1239,12 +1251,19 @@ public class BaseWicketTester
/**
 * Process a component. A web page will be automatically created with 
markup created by the
 * {@link #createPageMarkup(String)}.
+* p
+* strongNote/strong: the component id is set by the user. To
+* reach any of its children use this id + their relative path to 
the component itself. For example
+* if the started component has id emcompId/em and a Link child 
component component with id link
+* then after starting the component you can click it with: 
codetester.clickLink(compId:link)/code
+* /p
 * 
 * @param C
 *the type of the component
 * @param component
 *the component to be

git commit: WICKET-4424 getComponentFromLastRenderedPage appends componentInPage id when it shouldn't

2012-02-21 Thread mgrigorov

Updated Branches:
  refs/heads/wicket-1.5.x 6ba2d80b9 - 2a4d6c151


WICKET-4424 getComponentFromLastRenderedPage appends componentInPage id when it 
shouldn't


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/2a4d6c15
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/2a4d6c15
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/2a4d6c15

Branch: refs/heads/wicket-1.5.x
Commit: 2a4d6c151792d68b5d73fc1a347e7516187d8078
Parents: 6ba2d80
Author: Martin Tzvetanov Grigorov mgrigo...@apache.org
Authored: Tue Feb 21 14:36:45 2012 +0100
Committer: martin-g mgrigo...@apache.org
Committed: Tue Feb 21 14:42:34 2012 +0100

--
 .../wicket/util/tester/BaseWicketTester.java   |   33 ++-
 1 files changed, 31 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/2a4d6c15/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
--
diff --git 
a/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java 
b/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
index 5cf67ff..252fea4 100644
--- 
a/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
+++ 
b/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
@@ -43,7 +43,6 @@ import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.HttpSession;
 
 import junit.framework.AssertionFailedError;
-
 import org.apache.wicket.Application;
 import org.apache.wicket.Component;
 import org.apache.wicket.IPageManagerProvider;
@@ -1270,12 +1269,19 @@ public class BaseWicketTester
/**
 * Process a component. A web page will be automatically created with 
the markup created in
 * {@link #createPageMarkup(String)}.
+* p
+* strongNote/strong: the instantiated component will have an 
auto-generated id. To
+* reach any of its children use their relative path to the 
component itself. For example
+* if the started component has a child a Link component with id 
link then after starting
+* the component you can click it with: 
codetester.clickLink(link)/code
+* /p
 * 
 * @param C
 *the type of the component
 * @param componentClass
 *the class of the component to be tested
 * @return The component processed
+* @see #startComponentInPage(org.apache.wicket.Component)
 */
public final C extends Component C startComponentInPage(final 
ClassC componentClass)
{
@@ -1286,6 +1292,12 @@ public class BaseWicketTester
 * Process a component. A web page will be automatically created with 
the {@code pageMarkup}
 * provided. In case pageMarkup is null, the markup will be 
automatically created with
 * {@link #createPageMarkup(String)}.
+* p
+* strongNote/strong: the instantiated component will have an 
auto-generated id. To
+* reach any of its children use their relative path to the 
component itself. For example
+* if the started component has a child a Link component with id 
link then after starting
+* the component you can click it with: 
codetester.clickLink(link)/code
+* /p
 * 
 * @param C
 *the type of the component
@@ -1324,12 +1336,19 @@ public class BaseWicketTester
/**
 * Process a component. A web page will be automatically created with 
markup created by the
 * {@link #createPageMarkup(String)}.
+* p
+* strongNote/strong: the component id is set by the user. To
+* reach any of its children use this id + their relative path to 
the component itself. For example
+* if the started component has id emcompId/em and a Link child 
component component with id link
+* then after starting the component you can click it with: 
codetester.clickLink(compId:link)/code
+* /p
 * 
 * @param C
 *the type of the component
 * @param component
 *the component to be tested
 * @return The component processed
+* @see #startComponentInPage(Class)
 */
public final C extends Component C startComponentInPage(final C 
component)
{
@@ -1340,6 +1359,12 @@ public class BaseWicketTester
 * Process a component. A web page will be automatically created with 
the {@code pageMarkup}
 * provided. In case {@code pageMarkup} is null, the markup will be 
automatically created with
 * {@link #createPageMarkup(String)}.
+* p
+*

[jira] [Resolved] (WICKET-4424) getComponentFromLastRenderedPage appends componentInPage id when it shouldn't

2012-02-21 Thread Martin Grigorov (Resolved) (JIRA)


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

Martin Grigorov resolved WICKET-4424.
-

   Resolution: Fixed
Fix Version/s: 6.0.0
   1.5.5
 Assignee: Martin Grigorov

The code now is a bit smarter and checks whether the developer already 
prepended the path with the auto-generated component id and do no prepend it 
automacally anymore.
Additionally I added javadoc explaining how to find a child component inside 
the started component.
Please try latest -SNAPSHOT and give feedback.

 getComponentFromLastRenderedPage appends componentInPage id when it shouldn't
 -

 Key: WICKET-4424
 URL: https://issues.apache.org/jira/browse/WICKET-4424
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.4
Reporter: Johannes Odland
Assignee: Martin Grigorov
Priority: Minor
 Fix For: 1.5.5, 6.0.0


 When using WicketTester#startComponentInPage with a component class, wicket 
 will instantiate the component and give it an id.
 As an example, a starting a panel with a link inside will generate these page 
 relative paths:
 testObject
 testObject:link
 This id is automatically generated by wicket and not known to the developer, 
 wich makes it impossible for the developer to reference components by path, 
 as the first segment of the path is unknown. 
 To remedy this, wicket appends the id of the component to the path given by 
 the developer in getComponentFromLastRenderedPage().
 If the developer calls clickLink(link), getComponentFromLastRenderedPage 
 will append the generated id and form the path testObject:link
 This is OK as long as the developer explicitly gives the path, omitting the 
 id of the component.
 But, when retrieving the path from the components themselves this creates a 
 problem. 
 Say a developer is iterating through all links in the page and clicking them:
 Link link = getLink();
 wicketTester.clickLink(link.getPageRelativePath());
 ClickLink is then called with the path testObject:link, and 
 getComponentFromLastRenderedPage will append the generated id forming the 
 path testObject:testObject:link wich clearly fails.
 This is illustrated by a simple testcase:
 @Test
 public void clickShouldWork() {
   WicketTester tester = new WicketTester();
   tester.startComponentInPage(TestLink.class); 
   Link link = (Link) tester.getLastRenderedPage().get(0);
   String path = link.getPageRelativePath();
   wicketTester.clickLink(path);
 }
 public static class TestLink extends Link {
   public TestLink(String id) { super(id);}
   public void onClick() {}
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (WICKET-4425) Wicket 1.5 rewrites template content where it should not

2012-02-21 Thread Pointbreak (Created) (JIRA)

Wicket 1.5 rewrites template content where it should not


 Key: WICKET-4425
 URL: https://issues.apache.org/jira/browse/WICKET-4425
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.4
Reporter: Pointbreak


I have recently upgraded from Wicket 1.4.14 to 1.5.4. One issue that I
encountered is that script tags in panel templates are rewritten by
Wicket, even when the script tags in question have no wicket handlers
attached to them. I.e. the following panel template (notice that there
are no wicket:id attributes whatsoever):

wicket:panel
script id=template-upload type=text/x-jquery-tmpl
span${name}/span
/script
/wicket:panel

Would render in the panel as:

script id=template-upload type=text/x-jquery-tmpl
/*![CDATA[*/
span${name}/span
/*]]*/
/script

Imho this is unwanted behavior that is a regression from the behavior in
Wicket 1.4.x (or at least 1.4.14). Wicket should not add content to the
body of the script tags (or any other tags in a template, unless their
content is provided programmatically), as it does not have the knowledge
how that affects the functionality of the page. Moreover, the content
that Wicket adds to these script tags is only correct for Javascript
(hence incorrect for the scripts in the example as they are not
javascript). In the above example adding /*, */
will change the functionality of the script tag. If the /*![CDATA[*/
part was necessary in the script tags above, they should be added by the
person that provides the template, not magically added by Wicket.

I have attached a quickstart that demonstrates the issue. The quickstart has a 
script id=script1Some Text/script element in HomePage.html that (by 
javascript) is shown in an alert box. Because of this bug, the alert will now 
start with /*![CDATA[*/, while it should simply show the text. See 
HomePage.html in the provided quickstart.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (WICKET-4425) Wicket 1.5 rewrites template content where it should not

2012-02-21 Thread Pointbreak (Updated) (JIRA)

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

Pointbreak updated WICKET-4425:
---

Attachment: myproject.zip

quickstart that demonstrates the issue

Wicket 1.5 rewrites template content where it should not

Key: WICKET-4425
URL: https://issues.apache.org/jira/browse/WICKET-4425
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5.4
Reporter: Pointbreak
Attachments: myproject.zip

I have recently upgraded from Wicket 1.4.14 to 1.5.4. One issue that I
encountered is that script tags in panel templates are rewritten by
Wicket, even when the script tags in question have no wicket handlers
attached to them. I.e. the following panel template (notice that there
are no wicket:id attributes whatsoever):
wicket:panel
script id=template-upload type=text/x-jquery-tmpl
span${name}/span
/script
/wicket:panel
Would render in the panel as:
script id=template-upload type=text/x-jquery-tmpl
/*![CDATA[*/
span${name}/span
/*]]*/
/script
Imho this is unwanted behavior that is a regression from the behavior in
Wicket 1.4.x (or at least 1.4.14). Wicket should not add content to the
body of the script tags (or any other tags in a template, unless their
content is provided programmatically), as it does not have the knowledge
how that affects the functionality of the page. Moreover, the content
that Wicket adds to these script tags is only correct for Javascript
(hence incorrect for the scripts in the example as they are not
javascript). In the above example adding /*, */
will change the functionality of the script tag. If the /*![CDATA[*/
part was necessary in the script tags above, they should be added by the
person that provides the template, not magically added by Wicket.
I have attached a quickstart that demonstrates the issue. The quickstart has
a script id=script1Some Text/script element in HomePage.html that (by
javascript) is shown in an alert box. Because of this bug, the alert will now
start with /*![CDATA[*/, while it should simply show the text. See
HomePage.html in the provided quickstart.

[jira] [Commented] (WICKET-4404) CryptoMapper is not successfully decoding AbstractDefaultAjaxBehavior.generateCallbackScript request

2012-02-21 Thread Josh Chappelle (Commented) (JIRA)

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

Josh Chappelle commented on WICKET-4404:

Hmm, I'll unzip and see if I can reproduce. I will say that I only tested in
IE9. I'm not sure if that's the browser you were using.

I'll see if I can run it down and repost.

CryptoMapper is not successfully decoding
AbstractDefaultAjaxBehavior.generateCallbackScript request

Key: WICKET-4404
URL: https://issues.apache.org/jira/browse/WICKET-4404
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5.4
Environment: IE9
Reporter: Josh Chappelle
Labels: 1.5, AbstractDefaultAjaxBehavior, cryptomapper,
generateCallbackScript, wicket
Attachments: wicket_cryptomapper_quickstart.zip

I have a yui menu wrapper that I have written that does not work when the
cryptomapper is being used. It works fine otherwise. It basically outputs
javascript in the header and that javascript renders the dom elements. So the
only wicket component is a div that represents the menu. All of the items get
generated by the javascript. One of the attributes on the menu item is a
url attribute. In the url attribute I have javascript: and then the
javascript string that is created via the generateCallbackScript method. The
respond method never gets called if the cryptomapper is enabled.

[jira] [Updated] (WICKET-4425) Wicket 1.5 rewrites template content where it should not

2012-02-21 Thread Martin Grigorov (Updated) (JIRA)

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

Martin Grigorov updated WICKET-4425:

Attachment: WICKET-4425.patch

Here is a patch that wraps the content of script element only if its type is
a plain javascript.

Wicket 1.5 rewrites template content where it should not

Key: WICKET-4425
URL: https://issues.apache.org/jira/browse/WICKET-4425
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5.4
Reporter: Pointbreak
Attachments: WICKET-4425.patch, myproject.zip

[jira] [Assigned] (WICKET-4425) Wicket 1.5 rewrites template content where it should not

2012-02-21 Thread Martin Grigorov (Assigned) (JIRA)

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

Martin Grigorov reassigned WICKET-4425:
---

Assignee: Martin Grigorov

Wicket 1.5 rewrites template content where it should not

[jira] [Commented] (WICKET-2334) DebugBar throws an java.lang.ExceptionInInitializerError when Tomcat is restarted

2012-02-21 Thread Tomek Szpinda (Commented) (JIRA)


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

Tomek Szpinda commented on WICKET-2334:
---

Hi, 
got exactly the same exception, running version 1.5.3 in production with 
configuration set to deployment. Happened after restarting the app with 
jconsole. Any ideas?
Cheers,
Tomek

 DebugBar throws an java.lang.ExceptionInInitializerError when Tomcat is 
 restarted
 -

 Key: WICKET-2334
 URL: https://issues.apache.org/jira/browse/WICKET-2334
 Project: Wicket
  Issue Type: Bug
Affects Versions: 1.4-RC5
Reporter: Zoltan Luspai
Assignee: Igor Vaynberg
 Fix For: 1.4-RC6


 I have just added the DebugBar to our base page, and since then when Tomcat 
 is restarted and session would be reloaded by this it throws this exception:
 1ERROR org.apache.catalina.session.ManagerBase  - Exception loading 
 sessions from persistent storage
 java.lang.ExceptionInInitializerError
   at sun.misc.Unsafe.ensureClassInitialized(Native Method)
   at 
 sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
   at 
 sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
   at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
   at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
   at java.lang.reflect.Field.getLong(Field.java:528)
   at 
 java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
   at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
   at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.io.ObjectStreamClass.init(ObjectStreamClass.java:413)
   at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
   at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
   at 
 java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
   at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
   at 
 java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
   at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
   at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
   at 
 java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:480)
   at org.apache.wicket.Component.readObject(Component.java:4469)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
   at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
   at 
 java.util.concurrent.CopyOnWriteArrayList.readObject(CopyOnWriteArrayList.java:845)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at

[jira] [Commented] (WICKET-4425) Wicket 1.5 rewrites template content where it should not

2012-02-21 Thread Pointbreak (Commented) (JIRA)

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

Pointbreak commented on WICKET-4425:

Martin, although your patch would probably solve my issue in this particular
case, I don't think it is the correct approach. Imho the content of the
script tags in this quickstart should not be altered by wicket in any way,
even when they contain javascript. Wicket should not try to correct what it
deems incorrect html in a template. The programmer that provides the template
is responsible for that. It would be different if the script elements were
attached to a wicket Component (i.e. had a wicket:id) and/or their content was
programmatically added to them. But template code should be rendered as-is
where not attached to wicket Components. That wicket alters content of
html-elements that are not attached to Components a regression from pre 1.5
versions. I don't really understand why wicket would want to do that.

Wicket 1.5 rewrites template content where it should not

[jira] [Commented] (WICKET-4425) Wicket 1.5 rewrites template content where it should not

2012-02-21 Thread Martin Grigorov (Commented) (JIRA)

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

Martin Grigorov commented on WICKET-4425:
-

I guess you didn't notice that I linked this ticket to the one that introduced
this change. Check it and you'll see that we need to help in some cases.

Wicket 1.5 rewrites template content where it should not

[jira] [Commented] (WICKET-2334) DebugBar throws an java.lang.ExceptionInInitializerError when Tomcat is restarted

2012-02-21 Thread Martin Grigorov (Commented) (JIRA)


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

Martin Grigorov commented on WICKET-2334:
-

Can you paste/attach the stacktraces please ?

 DebugBar throws an java.lang.ExceptionInInitializerError when Tomcat is 
 restarted
 -

 Key: WICKET-2334
 URL: https://issues.apache.org/jira/browse/WICKET-2334
 Project: Wicket
  Issue Type: Bug
Affects Versions: 1.4-RC5
Reporter: Zoltan Luspai
Assignee: Igor Vaynberg
 Fix For: 1.4-RC6


 I have just added the DebugBar to our base page, and since then when Tomcat 
 is restarted and session would be reloaded by this it throws this exception:
 1ERROR org.apache.catalina.session.ManagerBase  - Exception loading 
 sessions from persistent storage
 java.lang.ExceptionInInitializerError
   at sun.misc.Unsafe.ensureClassInitialized(Native Method)
   at 
 sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
   at 
 sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
   at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
   at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
   at java.lang.reflect.Field.getLong(Field.java:528)
   at 
 java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
   at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
   at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.io.ObjectStreamClass.init(ObjectStreamClass.java:413)
   at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
   at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
   at 
 java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
   at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
   at 
 java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
   at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
   at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
   at 
 java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:480)
   at org.apache.wicket.Component.readObject(Component.java:4469)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
   at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
   at 
 java.util.concurrent.CopyOnWriteArrayList.readObject(CopyOnWriteArrayList.java:845)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
   at

[jira] [Commented] (WICKET-4425) Wicket 1.5 rewrites template content where it should not

2012-02-21 Thread Pointbreak (Commented) (JIRA)

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

Pointbreak commented on WICKET-4425:

Well actually I did see that, but am still confused. My point is that if there
is a verbatim script tag in the template and its code needs to be wrapped
inside /*![CDATA[*/, this should be done by the programmer that writes the
script tag. NOT as an afterthought by wicket. I don't see why wicket should
help here. (And Wicket did not do that in older versions).

This also applies to the issue you linked. The SCRIPT tag in that issue should
itself contain the wrapping /*![CDATA[*/ ... /*]]*/ stuff. Not providing that
is an error in the template, since the template can't be parsed by an XML/XHTML
parser. Of course Wicket should be smart enough that if such a CDATA wrapper
code is available inside contributions in the wicket:head section that it
doesn't skip that in the context of e.g. ajax requests. But providing that
wrapping code is part of the job of the template writer. I.e. I would argue
that the the following template code is faulty, and to fix that is the
responsibility of the template programmer:

wicket:head
script
if (someVariable 0) {
someVariable = 0;
}
/script
/wicket:head

Wicket 1.5 rewrites template content where it should not

[jira] [Issue Comment Edited] (WICKET-4404) CryptoMapper is not successfully decoding AbstractDefaultAjaxBehavior.generateCallbackScript request

2012-02-21 Thread Josh Chappelle (Issue Comment Edited) (JIRA)

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

Josh Chappelle edited comment on WICKET-4404 at 2/21/12 4:38 PM:
-

I just unzipped the wicket_cryptomapper_quickstart.zip and imported the project
into eclipse. When I pull it up in IE9 it renders the page fine. When I click
the link titled Yui menu link it does nothing. I don't see any javascript
errors either. I have put a debug point in CryptoMapper and I know that
mapRequest() is getting called. In fact, I see that it gets two requests(the
other link does this as well, I assume it is a wicket internal thing and must
be normal). In the mapRequest there is a decryptUrl method that gets called.
Here is the returned value of decryptUrl for each link for each request.

YUI Menu Link Request 1:
?0-1.IBehaviorListener.0-menu

YUI Menu Link Request 2:
?0

Regular Ajax Link Request 1:
?0-3.IBehaviorListener.0-link

Regular Ajax Link Request 2:
wicket/bookmarkable/com.test.wicket.DestinationPage

I hope you can get the quickstart to work for you. I've run down as much of
this thing as I know to do. The only reason I am using the homemade yui menu
instead of the wicketstuff version is that we were hitting some bugs with it
and I couldn't really get any support from the community on it.

Also, this worked in wicket 1.4.x.

Thanks for the help.

Josh

was (Author: jchappelle):
I just unzipped the wicket_cryptomapper_quickstart.zip and imported the
project into eclipse. When I pull it up in IE9 it renders the page fine. When I
click the link titled Yui menu link it does nothing. I have put a debug point
in CryptoMapper and I know that mapRequest() is getting called. In fact, I see
that it gets two requests(the other link does this as well, I assume it is a
wicket internal thing and must be normal). In the mapRequest there is a
decryptUrl method that gets called. Here is the returned value of decryptUrl
for each link for each request.

YUI Menu Link Request 1:
?0-1.IBehaviorListener.0-menu

YUI Menu Link Request 2:
?0

Regular Ajax Link Request 1:
?0-3.IBehaviorListener.0-link

Regular Ajax Link Request 2:
wicket/bookmarkable/com.test.wicket.DestinationPage

Also, this worked in wicket 1.4.x.

Thanks for the help.

Josh

CryptoMapper is not successfully decoding
AbstractDefaultAjaxBehavior.generateCallbackScript request

[jira] [Commented] (WICKET-4404) CryptoMapper is not successfully decoding AbstractDefaultAjaxBehavior.generateCallbackScript request

2012-02-21 Thread Josh Chappelle (Commented) (JIRA)

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

Josh Chappelle commented on WICKET-4404:

I just unzipped the wicket_cryptomapper_quickstart.zip and imported the project
into eclipse. When I pull it up in IE9 it renders the page fine. When I click
the link titled Yui menu link it does nothing. I have put a debug point in
CryptoMapper and I know that mapRequest() is getting called. In fact, I see
that it gets two requests(the other link does this as well, I assume it is a
wicket internal thing and must be normal). In the mapRequest there is a
decryptUrl method that gets called. Here is the returned value of decryptUrl
for each link for each request.

YUI Menu Link Request 1:
?0-1.IBehaviorListener.0-menu

YUI Menu Link Request 2:
?0

Regular Ajax Link Request 1:
?0-3.IBehaviorListener.0-link

Regular Ajax Link Request 2:
wicket/bookmarkable/com.test.wicket.DestinationPage

Also, this worked in wicket 1.4.x.

Thanks for the help.

Josh

CryptoMapper is not successfully decoding
AbstractDefaultAjaxBehavior.generateCallbackScript request

[jira] [Commented] (WICKET-4404) CryptoMapper is not successfully decoding AbstractDefaultAjaxBehavior.generateCallbackScript request

2012-02-21 Thread Martin Grigorov (Commented) (JIRA)

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

Martin Grigorov commented on WICKET-4404:
-

Can you minimize the quickstart even more ? Cut the YUI stuff. Just leave your
ajax behavior + crypto mapper.

CryptoMapper is not successfully decoding
AbstractDefaultAjaxBehavior.generateCallbackScript request

[jira] [Commented] (WICKET-4425) Wicket 1.5 rewrites template content where it should not

2012-02-21 Thread Martin Grigorov (Commented) (JIRA)

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

Martin Grigorov commented on WICKET-4425:
-

The developer should not be aware of the fact that Wicket uses XML to deliver
the HTML response in Ajax response. This CDATA is there exactly for this reason
- to allow DOMParser (JS) to create a proper JS Document no matter what is the
actual content.

Additionally div/ is a valid by HTML specs but some browsers don't behave
well with with. And Wicket tries to help in this situation as well, by
expanding it to div/div.

I'll commit this patch soon if there are no technical problems with it.

Wicket 1.5 rewrites template content where it should not

[jira] [Commented] (WICKET-4371) Timer problems with Internet Explorer

2012-02-21 Thread Igor Vaynberg (Commented) (JIRA)


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

Igor Vaynberg commented on WICKET-4371:
---

what exactly does that last request break?

 Timer problems with Internet Explorer
 -

 Key: WICKET-4371
 URL: https://issues.apache.org/jira/browse/WICKET-4371
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.19, 1.5.3, 1.5.4
 Environment: Jetty/Apache Tomcat  Internet Explorer
Reporter: Mikko Pukki
Assignee: Igor Vaynberg
 Attachments: TimerProblem.zip, TimerProblem_take2.zip, 
 WICKET-4371.patch, wicket-4371-with_firefox.har


 Hi,
 We are encountering problems on all pages that have timers for 
 updating/polling new data.
 It seems that if new page is rendering, timer's request can mess things up. 
 Problem can be
 reproduced with Wicket 1.5.3 and 1.5.4
 An example situation:
 1) Page (id1) has a timer and user presses link (Request1) that forwards to a 
 new Page (future id2).
 2) Request is being processed at server and page with id2 is rendered
 3) While still in render phase timer makes new request to a server
 Timer's request is handled even if there is a new rendered page. Timer's 
 request is now last request
 handled and page that contained timer is last page stored at PageTable. This 
 causes weird problems with
 our applications.
 I'm wondering that why any request that is meant for previous versions of 
 pages are processed?
 In quickstart rendering is slowed down with Thread.sleep, but network 
 latencies can and will create similar problems.
 In the quickstart there is PageB -link. Pressing that invokes this behavior
 There is also custom store in quickstart that provider simple debug logging. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (WICKET-4425) Wicket 1.5 rewrites template content where it should not

2012-02-21 Thread Pointbreak (Commented) (JIRA)

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

Pointbreak commented on WICKET-4425:

You are right in that he/she should not need to be aware of details of how
wicket TRANSPORTS. He/she should be aware how wicket PARSES templates though.
Thus, that and have special meaning in XML/XHTML templates, and will
trigger a parsing error unless used or escaped correctly. Why would the
template parser not simply throw an error on templates that can't be parsed as
valid XML or XHTML? Unbalanced tags in templates also result in parse errors
from wicket (even when they are valid in HTML and accepted by browsers). Your
div/ vs. div/div example has nothing to do with this, as for either
choice the template will be valid/parsable by any XML parser. A script tag that
contains special characters is not. I don't understand why you would want a
parser that accepts and and tries to fix incorrect use of special characters in
scripts tags in template files. Additionally it does a pretty bad job at that.
E.g. try this in a template for an actual error message from the template
parser; just a variation of the same thing though:

script
alert(/script);
/script

But I fail in getting my message across, so eh.. go ahead, I am happy with your
patch either way. Yet convinced that there is a flawed design decision in the
(new) wicket template processing logic, that your patch not fixes but works
around only for this specific case.

Wicket 1.5 rewrites template content where it should not

[jira] [Commented] (WICKET-4387) StringIndexOutOfBoundsException when forwarding requests

2012-02-21 Thread Al Thompson (Commented) (JIRA)


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

Al Thompson commented on WICKET-4387:
-

Slight line numbering fixup:

org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
180c181,185
   url.append(uri.substring(start));
---
   if(start  uri.length()) {
   url.append(uri);
   } else {
   url.append(uri.substring(start));
   }



 StringIndexOutOfBoundsException when forwarding requests
 

 Key: WICKET-4387
 URL: https://issues.apache.org/jira/browse/WICKET-4387
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.4
Reporter: Yossi Shaul
Assignee: Igor Vaynberg
Priority: Critical
 Attachments: wicket.zip


 We're getting StringIndexOutOfBoundsException from wicket when forwarding a 
 request from our servlet filter (using request dispatcher) to wicket.
 The problem occurs whenever the original URI is shorter than the wicket 
 filter mapping.
 I created an example webapp (based on the quickstart) in which a 
 ForwardFilter is mapped to /f/* and it forwards all the requests to /wicket/ 
 (see web.xml snippet below).
 With this webapp a request to http://localhost:8081/wicket/f/; results in 
 the following exception:
 {code}
 ERROR - RequestCycle   - Error during processing error message
 java.lang.StringIndexOutOfBoundsException: String index out of range: -5
 at java.lang.String.substring(String.java:1958)
 at java.lang.String.substring(String.java:1925)
 at 
 org.apache.wicket.protocol.http.servlet.ServletWebRequest.getContextRelativeUrl(ServletWebRequest.java:180)
 at 
 org.apache.wicket.protocol.http.servlet.ServletWebRequest.getClientUrl(ServletWebRequest.java:140)
 at org.apache.wicket.request.UrlRenderer.init(UrlRenderer.java:59)
 at 
 org.apache.wicket.request.cycle.RequestCycle.newUrlRenderer(RequestCycle.java:148)
 at 
 org.apache.wicket.request.cycle.RequestCycle.getUrlRenderer(RequestCycle.java:172)
 at 
 org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:145)
 at 
 org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
 at 
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)
 at 
 org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:304)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
 at 
 org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:227)
 at 
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
 at 
 org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
 at 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at 
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
 at 
 org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
 at 
 org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:402)
 at

[jira] [Commented] (WICKET-4404) CryptoMapper is not successfully decoding AbstractDefaultAjaxBehavior.generateCallbackScript request

2012-02-21 Thread Josh Chappelle (Commented) (JIRA)

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

Josh Chappelle commented on WICKET-4404:

I made a good attempt to but I can't accurately depict the problem without
including the YUI stuff because it creates DOM elements on the fly. I would
probably have to write more javascript than I know how to. I know that would
seem like the problem must lie in the YUI stuff but from what I can tell the
YUI stuff is calling wicket and the cryptomapper is failing to decrypt the
request.

CryptoMapper is not successfully decoding
AbstractDefaultAjaxBehavior.generateCallbackScript request

[jira] [Updated] (WICKET-4404) CryptoMapper is not successfully decoding AbstractDefaultAjaxBehavior.generateCallbackScript request

2012-02-21 Thread Josh Chappelle (Updated) (JIRA)

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

Josh Chappelle updated WICKET-4404:
---

Attachment: HomePageSource.txt

I attached the source of what the rendered HomePage looks like. I don't know if
this will help but I figured I would go ahead and post it.

One thing I have noticed in the javascript that renders using the
generatecallbackscript is that jsessionid is in there and in plain text. Could
that somehow be throwing off the decryption? I noticed the AjaxLink doesn't
render it's callback that way.

CryptoMapper is not successfully decoding
AbstractDefaultAjaxBehavior.generateCallbackScript request

[jira] [Commented] (WICKET-4371) Timer problems with Internet Explorer

2012-02-21 Thread Ari Suutari (Commented) (JIRA)

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

Ari Suutari commented on WICKET-4371:
-

For end-users the problem shows as page which renders odd data. For example,
imagine a three-page application:

page1 has link to page2
page2 has link to page3 and backwards link to page1. page2 also has timer
running.
page3 has backwards link to page2.

These links are in a tree component in real application and the tree is updated
by ajax requests.

Now user clicks link on page1 to navigate to page2. Page2 renders and timer
starts. User clicks link to navigate to page3. Timer backfires and causes
wicket side of application to think that user has gone back to page2. At this
point user doesn't notice anything, but if backward link is clicked
tree state from page1 is rendered to browser.

Maybe we should further develop the quickstart example to reflect the real
application, which has those links in a tree component. This is a little bit
difficult to debug since the problem is related
to timing.

Timer problems with Internet Explorer
-

37 matches

Mail list logo