hmm
getSessionSettings().setPageMapEvictionStrategy(new
IPageMapEvictionStrategy() {
public void evict(IPageMap pageMap) {
syncrhonized (Session.get()) {pageMap.clear();}
}
}
-igor
On 1/30/07, dukejansen <[EMAIL PROTECTED]> wrote:
I have tried the suggestion, and am still having trouble.
I have tried the suggestion, and am still having trouble.
In my base page component, I have the following code at the end of the
constructor:
setVersioned(false);
In addition, I have the following code in my extension of
WebApplication.init:
getSessionSettings().setMaxPageMaps(
yes thats already fixed for a few days now!
whiner!
johan
On 1/24/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
ajax requests shouldnt create versions anyways! did you fix that in 2.0yet?
-igor
On 1/24/07, Johan Compagner < [EMAIL PROTECTED]> wrote:
> Ahh so you are using pages with state.
Did not know about that functionality. Sounds perfect. Then for pages which
must always have bookmarkable URL, we can always extend a base class that
sets itself to unversioned, and for other non-bookmarkable pages we can
still rely on the standard behavior with back button support.
Thanks!
-Jas
ajax requests shouldnt create versions anyways! did you fix that in 2.0 yet?
-igor
On 1/24/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
Ahh so you are using pages with state. (you use ajax)
You just don't want to version them? Because for navigation you only use
bookmarkable pages
Just hav
Ahh so you are using pages with state. (you use ajax)
You just don't want to version them? Because for navigation you only use
bookmarkable pages
Just have one base page that does serVersioned(false)
then all your pages are unversioned.
johan
On 1/24/07, dukejansen <[EMAIL PROTECTED]> wrote:
Sorry, guess I misunderstood. Still trying to wrap my head around these
concepts.
We have an app that is all bookmarkable pages so far, but we may encounter
cases without them further down the road.
But even for our bookmarkable pages, they may have lots of activity on them
which is ajax actions
But i was talking about the settings maxpageversions.
thats not the same thing as how many there can be in the pagemap
That depends on the page map that is used (in 1.3 or 2.0)
AccessStackPageMap uses by default 5 because that is EvictionStrategy:
private IPageMapEvictionStrategy pageMapEvicti
I think the current method name makes sense, but what is unclear is whether
the CURRENT page is taking up one of the positions. I would think setting
the max to 1 would ensure that the pagemap contains the current page and no
others. If in fact the current page doesn't need room in the page map, t
The application I'm building must always have bookmarkable URLs which contain
all page parameters needed to reconstruct the page.
Achieved this currently by letting all page events update state/model, then
redirect to a new URL based on that state, so that the URL includes the new
state. But this
set the max to 0 then the change list of the version manager will really not
contain anything
this is the test: (after the new one is added to the list)
// If stack is overfull, remove oldest entry
if (getVersions() > maxVersions)
{
expireOldestVersion();
}
you do realize that by doing this you are completely killing the back button
support in your app
-igor
On 1/23/07, dukejansen <[EMAIL PROTECTED]> wrote:
Eelco Hillenius wrote:
>
> Well, every user (session) will use memory, correct. But only to a
> certain limit. Wicket 1.2 holds a coup
> How can I instruct Wicket not to maintain the multiple versions of a given
> page within the session? I've tried the following but when I dump the
> session contents I still see multiple page versions:
>
> getSessionSettings().setMaxPageMaps(1);
> getPageSettings().setMaxPageVersions(1);
>
> Am I
Eelco Hillenius wrote:
>
> Well, every user (session) will use memory, correct. But only to a
> certain limit. Wicket 1.2 holds a couple of page/ versions in a
> session, and Wicket 2.0 by default only holds the current one. So the
> creation of a fresh instance (e.g. a bookmarkable page) will r
Hi TH,
This has been discussed to death. Not only here in the Wicket
mailinglist, but on many other places as well.
The short answer is:
Yes, you get more GC and
no, you don't care if you have a sufficiently modern JVM and enough RAM
in your machine
Regards,
Erik.
TH Lim schreef:
> As w
Read this on the benefits of recent garbage collection strategies.
http://www-128.ibm.com/developerworks/library/j-jtp01274.html
Martijn
On 12/4/06, TH Lim <[EMAIL PROTECTED]> wrote:
>
> As we creating new instantes of WebPage, Form and other web widgets for every
> request received for differen
As we creating new instantes of WebPage, Form and other web widgets for every
request received for different pages, it will cause more garbages created.
Will this going to be affect the server performance?
I'm new to Wicket and probably this has been discussed before. I will be
grateful if someon
-
> > Von: wicket-user@lists.sourceforge.net
> <mailto:wicket-user@lists.sourceforge.net>
> > Gesendet: 03.11.06 16:30:22
> > An: wicket-user@lists.sourceforge.net
> <mailto:wicket-user@lists.sourceforge.net>
> > Betreff: Re: [Wicket-user] S
mailto:wicket-user@lists.sourceforge.net>
> > Gesendet: 03.11.06 16:30:22
> > An: wicket-user@lists.sourceforge.net
> <mailto:wicket-user@lists.sourceforge.net>
> > Betreff: Re: [Wicket-user] Strategy to avoid new instances of
> pages and panels
>
>
subclass: DefaultRequestTargetResolverStrategy
and then the method resolveBookmarkablePage(final RequestCycle requestCycle,
final RequestParameters requestParameters)
then create a new:
public CompoundRequestCycleProcessor(IRequestCodingStrategy
requestCodingStrategy,
IRequestTargetRes
Hi Johan,
I am having problems with new instances caused by bookmarkable pages.
I was unable to find how to provide my own implementation of
IRequestTargetResolverStrategy. Probably I must override a method somewhere,
but I was unable to find it.
How do I provide my implementation to IRequestTa
On 11/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Martijn,
>
> isn`t this a problem of the framework itself? When I have page
> constcted from serveral subcomponents then my JVM will run
> out of memory after some user.
Well, every user (session) will use memory, correct. But only to a
ce
> -Ursprüngliche Nachricht-
> Von: wicket-user@lists.sourceforge.net
> Gesendet: 03.11.06 17:03:46
> An: wicket-user@lists.sourceforge.net
> Betreff: Re: [Wicket-user] Strategy to avoid new instances of pages and panels
with that new in new user request you don't mean
t;> > -----Ursprüngliche Nachricht->> > Von: wicket-user@lists.sourceforge.net
> > Gesendet: 03.11.06 16:30:22> > An: wicket-user@lists.sourceforge.net>> > Betreff: Re: [Wicket-user] Strategy to avoid new instances of pages and panels
>> what do you mean w
Perfect,
this is what I need.
Thanks,
Maciej
> -Ursprüngliche Nachricht-
> Von: wicket-user@lists.sourceforge.net
> Gesendet: 03.11.06 16:55:14
> An: wicket-user@lists.sourceforge.net
> Betreff: Re: [Wicket-user] Strategy to avoid new instances of pages and p
new user request a minute.
> -Ursprüngliche Nachricht-
> Von: wicket-user@lists.sourceforge.net
> Gesendet: 03.11.06 16:48:51
> An: wicket-user@lists.sourceforge.net
> Betreff: Re: [Wicket-user] Strategy to avoid new instances of pages and panels
as martijn said. I am no
e pagea new instance. Is there a way to avoid this?Maciej> -Ursprüngliche Nachricht-> Von:
wicket-user@lists.sourceforge.net> Gesendet: 03.11.06 16:30:22> An: wicket-user@lists.sourceforge.net> Betreff: Re: [Wicket-user] Strategy to avoid new instances of pages and panels
wha
; An:
wicket-user@lists.sourceforge.net> Betreff: Re: [Wicket-user] Strategy to avoid new instances of pages and panels> Object pooling is considered baaaddd form with Wicket and Java in general.>
> A page is constructed in the context of a user session and as such> should not be shared
as martijn said. I am not talking about pooling pages over sessionsThat is a nogo in wicket. No i was talking about a single session reusing pages.So if you create a link that goes back to page X then hold that page there.
pooling pages over sessions can't be done. Maybe for completely static pages
ff: Re: [Wicket-user] Strategy to avoid new instances of pages and panels
what do you mean with reloads the page?
>
> A normal refresh (if url is wicket:interface=xxx) then a page is not
> recreated.
> Or do you mean bookmarkable urls?
>
> Other links like pageLinks or your own li
t; Von: wicket-user@lists.sourceforge.net
> Gesendet: 03.11.06 16:38:11
> An: wicket-user@lists.sourceforge.net
> Betreff: Re: [Wicket-user] Strategy to avoid new instances of pages and panels
> Object pooling is considered baaaddd form with Wicket and Java in general.
>
> A pa
able pages? How are those pages given back to the
> pool for reuse?
>
> Thank you very much,
>
> Maciej
>
> > -Ursprüngliche Nachricht-
> > Von: wicket-user@lists.sourceforge.net
> > Gesendet: 03.11.06 16:30:22
> > An: wicket-user@lists.sourceforge.ne
h,
Maciej
> -Ursprüngliche Nachricht-
> Von: wicket-user@lists.sourceforge.net
> Gesendet: 03.11.06 16:30:22
> An: wicket-user@lists.sourceforge.net
> Betreff: Re: [Wicket-user] Strategy to avoid new instances of pages and panels
what do you mean with reloads the page?
>
> A normal refr
what do you mean with reloads the page?A normal refresh (if url is wicket:interface=xxx) then a page is not recreated.Or do you mean bookmarkable urls?Other links like pageLinks or your own links you can do what ever you want with pooling pages.
johanOn 11/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
ion storage
to be re-used.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 1:31 AM
To: wicket-user@lists.sourceforge.net
Subject: [Wicket-user] Strategy to avoid new instances of pages and
panels
Hi all!
Hi all!
I am looking for a pattern, strategy or code example how to avoid creation of
new page Instances when a user reloads a page. Can someone give my a hint how
to achieve following behaviour:
- "static" pages which have only a single instance during whole application
lifecycle ?
- some kin
36 matches
Mail list logo