Thanks Eelco,
https://issues.apache.org/jira/browse/WICKET-994
Have you had a chance to reproduce it? We tested with a few browsers but all
in the same server env, although hard to see what difference that would
make.
Eelco Hillenius wrote:
On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote:
Hi, I'm unable to reproduce this with latest trunk. I believe this has
been already fixed by delaying the actual form serialization until the
previous request finishes. Can you please test this with latest trunk?
Unfurtunately, there are no current snapshots available so you'd have
to build it
Btw., did you clean browser cache after updating wicket? There's
chance that you have old javascript code still in browser cache.
Also part of the fix is in wicket-ajax.js, line 950:
submitForm: function(form, submitButton) {
var body = function() {
var s =
Doh. Owe you a pint. My build from trunk didn't work because I had wrong
version of logger... So I was running older code that was hanging about.
Can't break it now :)
Many thanks. If you are in London lots of nice warm English beer waiting for
you!
--
View this message in context:
So you tried it with latest trunk and it still doesn't work for you? I
used FF2/IE7 on Vista.
-Matej
On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote:
Still doesn't work for me. Can you give me a pointer to which change should
fix things?
What browser/OS did you use? Did you let the form get
Matej,
Sorry for the delay. If you unzip the attached file into the root of src dir
and point web.xml at TestWicketApplication it should work with 1.3-beta3. We
have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the
button and hold down return.
Please let me know if this is
On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote:
Matej,
Sorry for the delay. If you unzip the attached file into the root of src dir
and point web.xml at TestWicketApplication it should work with 1.3-beta3. We
have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the
button
Bit more information is that the bean property that is causing the problem is
being set to null by my html form via a wicket ajax update...
Could it be that although wicket is doing everything correctly the DOM in
(firefox 2) has not settled after the elmt.innerHTML= ... from the
previous ajax
but you get null pointers in the serverside. So what should that have to do
with busy parsing on the client side
That second submit is being done again (with the OLD dom) and that maybe
doesn't map correctly any more?
The problem is that the ajax request and waiting for the response and
updating
But shouldn't that be a validation error?
-Matej
On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote:
I'm getting null pointers on the server side because the form _values_ seem
not do have been set by the client yet so in the http request
someParameter= which would otherwise not be the case.
While the repaint is somewhat asynchronous, this shouldn't affect the
actual form serialization. Can you provide a quickstart that can be
used to reproduce this problem?
-Matej
On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote:
I'm using 1.3-beta3
I think as far as the wicket js is concerned it
I'm getting null pointers on the server side because the form _values_ seem
not do have been set by the client yet so in the http request
someParameter= which would otherwise not be the case.
Doesn't seem like something I want to handle on the server... If somebody is
hacking, has broken
So is the form sent using wicket JS from the DOM?
Anyway, I'm afraid I need to get the OK from my project manager before
spending more time on this :( Sucks that he is happy for you to work for
free on our problem but that I'm not even allowed to help you in this effort
:(
Thanks for your time
show us the full stack trace
-igor
On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote:
Which bit of code does the blocking on the server? I'm getting what looks
very much like a threading issue. I've looked at all the methods below and
can't see any obvious sync code... I'm using 1.3-beta3
Which bit of code does the blocking on the server? I'm getting what looks
very much like a threading issue. I've looked at all the methods below and
can't see any obvious sync code... I'm using 1.3-beta3
at
That is pretty much it. Except that:
Caused by: java.lang.NullPointerException
at
com.namechangedtoprotectguilty.search.Criterion.getHelper(Criterion.java:200)
at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
at
the nullpointer comes from outside of wicket (criterion class) but you
say if you click quickly you only get it? all pages are blocked by a
barrier that is build around the pagemap. its in Session.get page
method. only 1 request can pass that at the same time.
but what is
suddenly null that you
Must be me then. I'll try and pin it down more. Hmmm.
Johan Compagner wrote:
the nullpointer comes from outside of wicket (criterion class) but you
say if you click quickly you only get it? all pages are blocked by a
barrier that is build around the pagemap. its in Session.get page
Can you be more specific? What kind of concurrency issues?
-Matej
On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote:
oops, I posted on old forum...
http://www.nabble.com/threading-question-tf841003.html
[all request serialised on Session object]
Is this true even for Ajax requests? Is whole
I must be slowing down or Sun is speeding up. Huge amounts of stuff in 1.5
that I've not played with. From 1.1 to 1.2 it didn't seem that much to keep
up with!?
Not sure we have really slow tasks (like classic booking ticket) but we are
using Alfresco for some calls and that can be slow...
On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote:
Create a thread from within a servlet container...? Tut tut ;)
Yeah, not the most elegant way since they are not monitored by the
container, but it sure does get the work done. And we have really nice
users that would never try to flood our server.
Create a thread from within a servlet container...? Tut tut ;)
I don't think we have any messaging or timing framework at the mo so may
come to that.
Martijn Dashorst wrote:
On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote:
OK. Should give me fewer nightmares even if it doesn't explain
In our application, for long running ajax request we block the screen, so the
user is unable to click somewhere else.
Alex.
Sam Hough wrote:
OK. Should give me fewer nightmares even if it doesn't explain current
problem.
Many thanks. It is probably just my dodgy code.
What pattern do
OK. Should give me fewer nightmares even if it doesn't explain current
problem.
Many thanks. It is probably just my dodgy code.
What pattern do you use for long running Ajax requests?
Matej Knopp-2 wrote:
There is no way that ajax requests can be processed without blocking.
a) ajax
There is no way that ajax requests can be processed without blocking.
a) ajax requests are ordered on client into queues
b) requests are blocked on target page (not session) on server side
-Matej
On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote:
A bit of the application lets you add items to a
On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote:
OK. Should give me fewer nightmares even if it doesn't explain current
problem.
Many thanks. It is probably just my dodgy code.
What pattern do you use for long running Ajax requests?
Create a worker thread in the background. If it really lasts
26 matches
Mail list logo
