Revert your wicket-spring and wicket-spring-annot (if you use that) to 1.2.4
Martijn
On 4/2/07, sraj <[EMAIL PROTECTED]> wrote:
>
> Hello!
>
> I changed the Wicket version to 1.2.5. We are using tomcat. And now we are
> getting the following error on server startup on some mcahines -
>
> Can you
Hello!
I changed the Wicket version to 1.2.5. We are using tomcat. And now we are
getting the following error on server startup on some mcahines -
Can you please let me know, if you know anything about this issue?
-
Thank you! I will do that. Also, I changed my mode in web.xml to DEPLOYMENT.
-Shyla
Eelco Hillenius wrote:
>
> Yeah, please upgrade to a new version. You can download them here:
> http://sourceforge.net/project/showfiles.php?group_id=119783&package_id=130482
> or you can get the latest snaps
Yeah, please upgrade to a new version. You can download them here:
http://sourceforge.net/project/showfiles.php?group_id=119783&package_id=130482
or you can get the latest snapshot from here:
http://wicketstuff.org/maven/repository/wicket/wicket/1.2-SNAPSHOT/
We want to do a 1.2.6 release soon if
1.2.3.
Thanks,
Shyla
Eelco Hillenius wrote:
>
> What version of Wicket are you using? And if it is not the latest
> 1.2.x or 1.3, please upgrade.
>
> Eelco
>
>
>> Hello,
>>
>> I am getting 'Stack Overflow' error from the browser while selecting
>> Date
>> from Date picker UI. Please help
What version of Wicket are you using? And if it is not the latest
1.2.x or 1.3, please upgrade.
Eelco
> Hello,
>
> I am getting 'Stack Overflow' error from the browser while selecting Date
> from Date picker UI. Please help.
>
> Thanks,
> sraj
--
Hello,
I am getting 'Stack Overflow' error from the browser while selecting Date
from Date picker UI. Please help.
Thanks,
sraj
samyem wrote:
>
> So far so good. It got rid of the issues with stack overflow and the other
> previous issues has not surfaced.
>
> Thanks,
> Samyem
>
>
> Mate
and to add to the confusion, 1.x will first become 1.2.3 as soon as we
fix those damn bugs. 1.3 (or 1.2.4) will follow quickly.
Martijn
On 10/17/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Yeah, sorry, I meant 1.x.
>
> -Matej
>
> Pierre-Yves Saumont wrote:
> > Hi Matej,
> >
> > I suppose 1.3 is
Yeah, sorry, I meant 1.x.
-Matej
Pierre-Yves Saumont wrote:
> Hi Matej,
>
> I suppose 1.3 is current branch 1.x ? I checked out this, and it works.
> It still don't work with 1.2.2, but never mind. I hope it will continue
> working as I add functionnalities to the application ;-)
>
> Thanks,
Hi Matej,
I suppose 1.3 is current branch 1.x ? I checked out this, and it works.
It still don't work with 1.2.2, but never mind. I hope it will continue
working as I add functionnalities to the application ;-)
Thanks,
Pierre-Yves
Matej Knopp a écrit :
> Hi Pierre-Yvers,
>
> I've tested your
Hi Pierre-Yvers,
I've tested your example with IE, FF and Opera, in all browsers it
worked well. I've tested it wicket current svn (branch 1.3). So if there
really is a bug, I still can't reproduce it :(
However, there is one bug your example helped me to find, and that is
AjaxTabbedPanel being
Well, the modification basically restored the behavior from before the
speed optimization was done. It shouldn't really change anything,
definitely not cause null instead of AjaxRequest (which probably means
that you're using fallback links and for some reason they are not fired
using Ajax).
A
Hi Matej,
With this modification, some Ajax link are seeing there onClick methods
called with a null target.
In the page I load, there is a top menu bar that loaded "Ajax pages". In
this "pages" there is genrally a ajax tabbed panel. The inner ajax
links are working and the datepicker also w
This is very unfortunate. I'm not able to reproduce the stack overflow
problem even with huge ajax responses.
Can you plese replace the processNext method with this:
processNext: function() {
if (this.current < this.functions.length) {
var f = this
I changed the value to 10. It does not change anything. I don't know if
it can be usefull, but I added the line:
alert(this.depth);
before line 120. When loading the Ajax response that contains the
datepicker, this alert is displayed 10 times with values 0 to 9.
Pierre-Yves
Matej Knopp a écri
That's not really the problem. The javascript _is_ included only once.
Problem is the performance improvement I did, calling the run method
from call stack instead of scheduling it on window.setTimeout(). The
latter is very slow, because it redraws browser window.
Anyway, it should no longer ca
is it possible to change calendar.js and include an include_only_once logic?
-Igor
Pierre-Yves Saumont wrote:
>
> Hello Matej,
>
> I eventually found the updated file. (I was looking for the calendar.js
> file, and not for wicket-ajax.js). It doesn't change anything. I still
> have a "too m
Hello Matej,
I eventually found the updated file. (I was looking for the calendar.js
file, and not for wicket-ajax.js). It doesn't change anything. I still
have a "too much recursion" error at line 1796 of calendar.js
Pierre-Yves
Matej Knopp a écrit :
> I assume there's something wrong with yo
I assume there's something wrong with your svn setup. The revision of
wicket-ajax.js in svn is 7534, it's 3 days old
http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534
Maybe it would help to do a clean checkout of enti
Hi Matej,
I can't find anything newer than revision 7520 (udpate of the french
files) in branche 1.x and revision 7519 in trunk.
Where did you put the updated files?
Thanks,
Pierre-Yves
Matej Knopp a écrit :
> Hi,
>
> it should be fixed in SVN, but I can't really test it. I've simulated
>
So far so good. It got rid of the issues with stack overflow and the other
previous issues has not surfaced.
Thanks,
Samyem
Matej Knopp wrote:
>
> Hi,
>
> it should be fixed in SVN, but I can't really test it. I've simulated
> updating of many elements so that I could reproduce the stack ov
I can't find it yet in SVN. Only the french files are new.
Pierre-Yves
Matej Knopp a écrit :
> Hi,
>
> it should be fixed in SVN, but I can't really test it. I've simulated
> updating of many elements so that I could reproduce the stack overflow,
> but I don't know if that is your case.
>
> p
Hi,
it should be fixed in SVN, but I can't really test it. I've simulated
updating of many elements so that I could reproduce the stack overflow,
but I don't know if that is your case.
please try the current version and let me know.
-Matej
Matej Knopp wrote:
> Sorry for this, I've underestima
Sorry for this, I've underestimated the stack size of browsers. Expect
it to be fixed withing couple of hours.
-Matej
Pierre-Yves Saumont wrote:
> Hi Samyem,
>
> Could you send me your script, so that I can see if it solves the
> problem for me?
>
> Thanks,
>
> Pierre-Yves
>
> samyem a écri
Hi Samyem,
Could you send me your script, so that I can see if it solves the
problem for me?
Thanks,
Pierre-Yves
samyem a écrit :
> I could trace my problem to a recent change in wicket-ajax.js. In the
> defination of processNext, it used to be that the run was called on a
> timeout like windo
I could trace my problem to a recent change in wicket-ajax.js. In the
defination of processNext, it used to be that the run was called on a
timeout like window.setTimeout(run, 1);. Now this is only called for
isKHTML, and there is a direct call to run() otherwise. This for some reason
gave the rec
Same here. I am getting too much recursion in places I didn't have problem
earlier as well. Looking at the generated source, it is clear that the java
script gets included more than once, not just once in the header.
- Samyem
Pierre-Yves Saumont wrote:
>
> I am afraid there is still a problem.
I am afraid there is still a problem. I tested the fix in the quickstart
I had made and it worked fine. However, in my application, selecting a
date in the datepicker cause a Javascript error. FF reports this error as:
Erreur : too much recursion
Fichier source :
http://localhost:8080/ceagrap/a
Thanks for fixed files, I've already commited those.
-Matej
Pierre-Yves Saumont wrote:
> Now it seems to work fine provided the locale switching is made through
> reloading the page and not through Ajax. (I enclosed the modified french
> scripts, in utf8 and iso.)
>
> If switching is made thro
Now it seems to work fine provided the locale switching is made through
reloading the page and not through Ajax. (I enclosed the modified french
scripts, in utf8 and iso.)
If switching is made through Ajax, it works much better than it did
before. If the datepicker is visible when switching, s
You won't find it there. It's wicket-1.x (and trunk).
1.2.2 is release. Current branch for 1.2 is under 1.x
-Matej
Pierre-Yves Saumont wrote:
> I can't find it in releases/wicket-1.2.2, only in trunk, but my app does
> not work with 2.0 :-(
>
> Pierre-Yves
>
> Matej Knopp a écrit :
>> Sorry f
I can't find it in releases/wicket-1.2.2, only in trunk, but my app does
not work with 2.0 :-(
Pierre-Yves
Matej Knopp a écrit :
> Sorry for ambiguity. The fix should be already in.
>
> -Matej
>
> Pierre-Yves Saumont wrote:
>> What should already be in? Is it your fix? Or are you talking about
Sorry for ambiguity. The fix should be already in.
-Matej
Pierre-Yves Saumont wrote:
> What should already be in? Is it your fix? Or are you talking about the
> edited file I sent to the list few days ago? This is no complete since
> at that time I had not noticed the tuesday error!
>
> Pierre
What should already be in? Is it your fix? Or are you talking about the
edited file I sent to the list few days ago? This is no complete since
at that time I had not noticed the tuesday error!
Pierre-Yves
Matej Knopp a écrit :
> btw. it should be already in.
>
> Pierre-Yves Saumont wrote:
>> H
btw. it should be already in.
Pierre-Yves Saumont wrote:
> Hi Matej,
>
> Of course I will test it as soon as you commit it. BTW, there are plenty
> of typos and spelling mistakes in the french script, and even an error
> in the abreviated day names (it says monday, tuesday, tuesday, thursday
>
Sure, why not? I had the same problem with Slovak locale. Just send me
the corrected (utf-8 encoded) file and I'll commit it.
-Matej
Pierre-Yves Saumont wrote:
> Hi Matej,
>
> Of course I will test it as soon as you commit it. BTW, there are plenty
> of typos and spelling mistakes in the frenc
I remember the first days of Java: UNICODE (UTF16) was the ultimate
encoding scheme that would definitely solve the problem for all
languages on earth. There was plenty of unused room for future use. The
Java designers even create a special type (char) for this. They would
have been much better
Hi Matej,
Of course I will test it as soon as you commit it. BTW, there are plenty
of typos and spelling mistakes in the french script, and even an error
in the abreviated day names (it says monday, tuesday, tuesday, thursday
and there is no wednesday!). Do you want me to send you an edited fil
Hi,
I'm working on the date picker encoding problem. What I'll probably do
is to convert all non-unicode (latin1, ...) date picker locale strings
to utf-8 and add charset="utf-8" to the
Next UNICODE encoding will be 32 bits, which will be enoughfor all characters of all languages in the galaxy.
thats what they said about ipv4 :)-Igor
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net'
Hi Eelco,
I did not feel irritated by your answers and I apologize for having let
you think I was. I understand perfectly your position and I acknowledge
the immense amount of work there is behind Wicket and I want to thank
every one working on it for making such a smart framework available.
I
The reason why locale switching using ajax link on datepicker is, that
ajax header contribution is for performance reasons done only once per
component instance (until the entire page is refreshed).
The reason is reduce amount of data sent to browser on every ajax call.
The Unicode problem also
> It is the same kind of problem we have with character encoding. Every
> time someone has a problem with encoding, the answer can be "use XXX
> encoding for all and there will be no problem". This is false AND
> irrelevant.
Well, I guess we hoped that UTF-8 would just work for everyone. It's
cert
Well, I believe a functionnality should work whatever teh reason you
have to use it. I agree it make sense to refresh the whole page... if it
is what you want. If it is not what you need, it makes very little
sense. Of course, it it does not work, I will not use it. No choice. But
I think it wo
> I finally decided to apply the solution proposed by Eelco (only change
> locale through a normal link so that the whole page is reloaded)
> although I feel it is like closing our eyes and pretended the problem is
> solved.
I don't agree with that. Changing the locale potentially has effect on
th
It works now much better, but still not correctly. Changing the locale
when the datepicker is not displayed, and then loading the datepicker
through Ajax dont work. The datepicker does not use the new locale.
I finally decided to apply the solution proposed by Eelco (only change
locale through
It also is fixed in wicket-1.x
-Matej
Pierre-Yves Saumont wrote:
> Is it fixed only in trunk or also in releases ?
>
> Pierre-Yves
>
> Matej Knopp a écrit :
>> The problem was that AjaxRequestTarget called component.renderHead(),
>> without calling rendered() on component behaviors after that
So far so good. Now if only the z-index issue can be cleanly fixed. I still
have other issues that I'll post in other threads.
- Samyem
Matej Knopp wrote:
>
> The problem was that AjaxRequestTarget called component.renderHead(),
> without calling rendered() on component behaviors after that (
Is it fixed only in trunk or also in releases ?
Pierre-Yves
Matej Knopp a écrit :
> The problem was that AjaxRequestTarget called component.renderHead(),
> without calling rendered() on component behaviors after that (co the
> thread local has not been cleaned).
>
> The fix is in SVN. Can you
The problem was that AjaxRequestTarget called component.renderHead(),
without calling rendered() on component behaviors after that (co the
thread local has not been cleaned).
The fix is in SVN. Can you please test if it works for you? It works
with the quick start you've provided, so I'd say it
Great! I can reproduce the problem now. Will look at it today. Thanks!
-Matej
samyem wrote:
> Okay I have got something that'll make you happy: wicket quickstart! Pick it
> up at http://www.yomari.net/~samyem/problem-wicket-quickstart.zip
>
> It has two pages. The first page is okay. Click on t
Okay I have got something that'll make you happy: wicket quickstart! Pick it
up at http://www.yomari.net/~samyem/problem-wicket-quickstart.zip
It has two pages. The first page is okay. Click on the link to go to the
second one. And click on the "Click here to add one" link. Nothing will
happen.
I am using 1.2.2 from trunk. I compiled the sources skipping the tests.
It still doesn't work in IE6. The only difference is that when I reload
the page to have the whole page load normally (not through Ajax), it now
throw an exception (with version 1.2.1, it worked). The exception is:
Root cau
This problem is a bit difficult to reproduce. Anyway, I am trying to isolate
this into a quick start. So far, this is what I observed:
AbstractAjaxBehavior has a ThreadLocal variable called headContribHolder. It
is set to null by a call to cleanup() method, which is ment to be called
from Abstrac
http://www.wicket-wiki.org.uk/wiki/index.php/Wicketfromsource
On 9/25/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> No Idea. Which version are you using?
> Anyway, there is a maven parameter that allows you to build a release
> without running unit test (look at older posts, it's certainly mentione
No Idea. Which version are you using?
Anyway, there is a maven parameter that allows you to build a release
without running unit test (look at older posts, it's certainly mentioned
somewhere).
-Matej
Pierre-Yves Saumont wrote:
> Yes. I have even deleted everything and checked out a new complete
No matter what I do I just can't reproduce this. Can you please double
check that you're using branch wicket-1.x or trunk, and a clean build?
If the problem persists, can you please either check if it happens with
wicket-examples too or try to isolate the problem and provide a
quickstart exampl
Upon further investigations, what is clear is that when the page first loads,
it loads up all the java scripts in the header. When I do a page refresh by
pressing F5, the ensuing page does not render the javascript references at
all. Looks like there is some logic which prevents javascripts from
r
I am also getting this new error after the update:
Error: wicketAjaxGet is not defined
Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
Line: 1
samyem wrote:
>
> I updated wicket and wicket-extension and now my modal window is not even
> showing and the date picker does not s
Just to add emphasis, here the problem is that wicket made a request for the
resource at /mm/calendar.js, which is not a valid path. It should have been
/mm/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
- Samyem
samyem wrote:
>
> I updated wicket and wicket-exte
I updated wicket and wicket-extension and now my modal window is not even
showing and the date picker does not show up in non modal window pages as
well. I can only see the error through the ajax debugger as:
...
NFO: Response parsed. Now invoking steps...
INFO:
INFO: Initiating Ajax GET request
Yes. I have even deleted everything and checked out a new complete fresh
version, tried mvn clean, deleted manually the target and tried again !!
I have no problem with wicket-extensions.
Pierre-Yves
Matej Knopp a écrit :
> This is strange. I've tested both current 1.x and 2.0
>
> in 1.x all t
This is strange. I've tested both current 1.x and 2.0
in 1.x all tests completed with no problem for me,
in 2.0 there are 4 errors and 1 failure.
I don't know where the problem can be. Have you tried clean build?
-Matej
Pierre-Yves Saumont wrote:
> I tried to build the last version from trunk,
I tried to build the last version from trunk, but it fails the tests (32
failures) most failures report inversion of two html attributes, for
exemple:
=== wicket.markup.MarkupInheritanceExtension_11 ===
3c3
<
---
>
Checkout reported version # 7486.
Pierre-Yves
Matej Knopp a écrit :
Problem is the z-index of the datepicker div. The div is shown only when
you click on the calendar icon. At that time there is no way for us to
set the z-index of the datepicker. When showing modal dialog the
datepicker div is probably not even in the DOM tree.
-Matej
Martijn Dashorst wrote:
>
ah... so a solution would be to have the datepicker insert its panel
inside the containing div, and adjust its z-index accordingly. Not
sure if that is simple or not though.
Martijn
On 9/25/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Problem is the z-index of the datepicker div. The div is shown
Just thinking out loud:
the modal window knows its z-index. can't we put an extra div (or
span) inside that elevates all components inside to have
newModalWindow.z-index + 1?
As the modal window is displayed we use javascript. It wouldn't be
hard I suspect to change the z-index of the inner span?
Thanks. I've fixed the z-index problem in my app by manually resetting the
z-index in my HTML, thus overriding the default values set by the
components. So hopefully now everything will run smoothly.
Thanks for the fix again,
Samyem
Matej Knopp wrote:
>
> The fix is in svn. (both 1.x and 2.0)
I've tested your quick start example with current svn and I worked as it
should. Tested with FF1.5, IE6 and opera 9.
Can you please test your project with current svn, if the problem persists?
-Matej
Pierre-Yves Saumont wrote:
> And in some conditions (see my other post with a quickstart examp
The fix is in svn. (both 1.x and 2.0)
DatePicker in modal window panel now works, although the issue with
z-index still remains. As a side effect this also fixes the component
use check for components that render into head, so calling
getDebugSettings().setComponentUseCheck(false) in application
Hi,
It indeed is problem with modal window. Or, better said, with
AjaxRequestTarget. I've tried to put date picker to modal window, and it
didn't work. The reason is that component is not attached when rendering
it's header contribution from AjaxRequestTarget. I've tried to refactor
AjaxReques
And in some conditions (see my other post with a quickstart example),
the setup script is not even executed !!
Pierre-Yves
samyem a écrit :
> The header contribution logic seems to be still flawed. The javascript
> references were not added to the HTML's HEAD at all when the component is
> added
Well it might actually be just a problem with this component. In my case, all
I have is a date picker in a modal window which is shown as a result of
clicking on a link. This produced the shown error and the modal window fail
to display. I am sure you can replicate this condition with the current
I don'y really understand why. I was able to reproduce the problem with
the files attached to bug report. And after I fixed the debug console,
the problems were no longer there (though there was other problem -
component not rendered except - for which it is necessary to disable
component rende
Dynamic addition of javascript and css through header contributions
does work for most cases. I'm using it on a daily basis, and never
have problems with it. I'm afraid we ran into a corner case here.
Eelco
On 9/23/06, samyem <[EMAIL PROTECTED]> wrote:
>
> The header contribution logic seems to
The header contribution logic seems to be still flawed. The javascript
references were not added to the HTML's HEAD at all when the component is
added by ajax. I guess this is a larger problem than the date picker. The
same problem would occur everytime the javascript/stylesheet are added
dynamica
Well, I was working on it. But only to the degree that I disabled the
disabling of check during ajax request, because it was no longer necessary.
Unfortunately head contribution is something else, I'm not sure how to
do it the best way, again, it's not my domain. I think that I've posted
mail a
i thought you _were_ working on the component use check and ajax target stuff?-IgorOn 9/22/06, Matej Knopp <
[EMAIL PROTECTED]> wrote:I don't think so. I was working on header contribution and problem with
debug console calling document.write() (thus removing all head elementsfrom DOM).This is some
I don't think so. I was working on header contribution and problem with
debug console calling document.write() (thus removing all head elements
from DOM).
This is something completely different, it's related to the component
rendered check. That's not my domain. I believe the problem are
compo
matej was working to fix this, i thought he did matej?-IgorOn 9/21/06, samyem <[EMAIL PROTECTED]
> wrote:I took the latest SVN code today and suddenly, I am getting the following
error everytime there is an ajax refresh on panels with date pickers:2006-09-21 14:16:07,728 ERROR wicket.ajax.AjaxR
I took the latest SVN code today and suddenly, I am getting the following
error everytime there is an ajax refresh on panels with date pickers:
2006-09-21 14:16:07,728 ERROR wicket.ajax.AjaxRequestTarget - Error while
responding to an AJAX request: [EMAIL PROTECTED]
markupIdToComponent [{pageBody
81 matches
Mail list logo
