is that your are showing dialogs and other stuff
without
using pagemaps correctly. So the page is expired because wicket thinks
that
it can clean it up.
johan
On 2/16/07, beboris [EMAIL PROTECTED] wrote:
We have a central WebPage, which is not supposed to be versioned.
So, we call
) it was
decided that the file path should include /pictureBank ???
Can it be something simple that we can do to cure this kind of issues?
beboris wrote:
Just an FYI for those who want to know what the problem was about or
solution for it is. We did mount the page, and it didn't help. So, we
created
/
/a
span class=text_style
wicket:message key=searchOptions/
/span
/div
beboris wrote:
So, here is an update.
It DID fix the problem for the home page.
Still, we have a bunch of relative path resources on other pages, which
We are using version 1.2.4
Johan Compagner wrote:
what wicket version are you exactly using?
On 2/17/07, beboris [EMAIL PROTECTED] wrote:
So, here is an update.
It DID fix the problem for the home page.
Still, we have a bunch of relative path resources on other pages, which
whether it fixed the problem for us...
igor.vaynberg wrote:
mount the page using querystringcodingstrategy that way the link will be
/index.html?wicket:pagemap...
-igor
On 2/15/07, beboris [EMAIL PROTECTED] wrote:
Nothing happens. We stay on the same HomePage and display an error
After 2 months of working with Wicket we almost felt like profies but now
that we have to [loosely] integrate some pieces written by others we've got
into one of those Wicket gotchas again...
So, there is a simple home page with a simple javascript created by others,
which we host inside our
We have a central WebPage, which is not supposed to be versioned.
So, we call setVersioned(false) in all constructors for that WebPage, and
Wicket, indeed, has only one version for that page, version number 1.
However, it looks like somehow there is a logic inside the framework, which
is not
?
-igor
On 2/15/07, beboris [EMAIL PROTECTED] wrote:
After 2 months of working with Wicket we almost felt like profies but
now
that we have to [loosely] integrate some pieces written by others we've
got
into one of those Wicket gotchas again...
So, there is a simple home page
.
-igor
On 2/1/07, beboris [EMAIL PROTECTED] wrote:
It's hard for me to say, what the right way to fix this situation is.
The
number of open files (that look to the OS as wicket .jar files) will go
up
significantly and then go down (down - probably due to the garbage
collection
beboris wrote:
We have the following code that attempts to create a modal window of
certain
size and make it non-resizable:
public class MyModalPage extends WebPage {
public MyModalPage( final WebPage parentPage, ModalWindow modalWindow) {
modalWindow.setVersioned(false
instead of development mode?
then that shouldn't happen.
I can see if we can backport it.
johan
On 2/1/07, beboris [EMAIL PROTECTED] wrote:
We have found a pretty weird situation with too many open files error
on
our alpha-testing site. Further analysis showed that on each page refresh
normal files are involved?
Eelco
On 2/1/07, Johan Compagner [EMAIL PROTECTED] wrote:
one per resource will i think not really change.
johan
On 2/1/07, beboris [EMAIL PROTECTED] wrote:
We will, when we
We have the following code that attempts to create a modal window of certain
size and make it non-resizable:
public class MyModalPage extends WebPage {
public MyModalPage( final WebPage parentPage, ModalWindow modalWindow) {
modalWindow.setVersioned(false);
Is it possible that your session expired comes from the second host because
it knows nothing about your session on the first host? If that's the case
you'd need to use some distributed session mechanism. Just a guess...
Carfield Yim-2 wrote:
By the way, I just deploy the application of
We have done some performance testing between JSF, JSP, Wicket and Stripes
when choosing a framework to develop Ajax-enabled WebUI.
You may find it interesting to know that our results showed JSF is at least
3-4 times slower than JSP on simple pages (exactly as described at
We have found a pretty weird situation with too many open files error on
our alpha-testing site. Further analysis showed that on each page refresh
the following resources get repeatedly obtained from the wicket's .jar and
add to the number of open files:
'wicket/ajax/wicket-ajax.js'
we should make handlemultipart protected with a javadoc
warning
that overrides may break fileuploadfields
-igor
On 1/17/07, beboris [EMAIL PROTECTED] wrote:
So, I guess you suggest we do it on the application level by overriding
newWebRequest() method inside the whole WebApplication
Done (issue ID=12360795)
Eelco Hillenius wrote:
If you could open up a feature request for that Boris, we can put it
in the next version.
Eelco
Also, please let me know what your plans for making method
protected are (starting with which version)...
?
The issue id doesn't seem to fit the profile.
For the core projects (found at the download site at
http://sf.net/projects/wicket) we exclusively use JIRA at apache.
Martijn
On 1/18/07, beboris [EMAIL PROTECTED] wrote:
Done (issue ID=12360795)
Eelco Hillenius wrote:
If you could
I am glad you are open to making the handleMultiPart() method protected.
While we understand your concern about existing contracts, the dangers of
giving user ability to override and control multi-part stream handling may well
be exaggerated - especially considering getRequest/setRequest
So, I guess you suggest we do it on the application level by overriding
newWebRequest() method inside the whole WebApplication, so it returns our
custom WebRequest subclass globally, as follows:
protected WebRequest newWebRequest(HttpServletRequest servletRequest) {
return new
21 matches
Mail list logo
