Hi Johan,
as I mentioned earlier, I realise that long operations shouldn't be done in
the request thread. But there are some cases where it's hard to guarantee
that operations can't take long, and I want to make sure we cope well with
exceptional cases too.
I didn't fully understand your last reply, but I tried checking the page map
name in the constructor of a page and throwing an exception when it's not
set. But then I just got an infinite redirect loop.
Jan
2008/9/6 Johan Compagner <[EMAIL PROTECTED]>
> You have to redirect onces.
> Just throw a resartresponseexception in the constructor and let a new
> page be created. It are all landing pages anyway so thats
> bookmarkable.
>
> But to make this thread even simpeler. Just dont have long running
> stuff in the request thread
>
> On 9/5/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> > Hi Johan,
> >
> > I've seen the code in WebPage.onNewBrowserWindow(). The thing I'm having
> a
> > problem figuring out is where to hook in this code. I can't see that I
> can
> > do this in the constructor of a page as you suggest. In the constructor
> the
> > page hasn't been fully constructed yet so I can't see that I could clone
> the
> > page and redirect to it in the way that onNewBrowserWindow does. I've
> also
> > had a look in wicket.Session to see if there's a place that I can hook in
> > this extra check but I can't see how. Partly because all the relevant
> > methods are final so can't be overridden...
> >
> > I tried to patch our version of Wicket to get a workaround for this. I
> > added the following to Session.newPageMap(String name):
> >
> > public final IPageMap newPageMap(String name)
> > {
> > if (name == PageMap.DEFAULT_NAME) {
> > name = createAutoPageMapName();
> > log.debug("Allocated new page map name: " + name);
> > }
> > <...the rest as before...>
> > }
> >
> > This seems to solve the problem, but I don't know if this as other side
> > effects. If this is basically a sensible fix, would it be reasonable to
> add
> > a hook for doing this in a cleaner way, e.g. adding a call in
> newPageMap()
> > to a new method "getPageMapName(name)", that in the default
> implementation
> > just returns the argument, but could be overridden to do the above?
> >
> > Regards,
> > Jan
> >
> >
> > 2008/9/1 Johan Compagner <[EMAIL PROTECTED]>
> >
> >> First try to look at the newbrowser window check that we have in
> webpage.
> >> Dont know if you can all do those things (clone the page and set
> >> another pagemap)
> >>
> >> What you could do is int the page const check pagemap, if default then
> >> create the same page as you are on but then with a different pagemap
> >> and throw a restartresponse exception.
> >>
> >> Johan
> >>
> >> On 9/1/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> >> > Johan,
> >> >
> >> > I've had a look at doing the workaround you suggest, but I don't know
> >> > Wicket's internals enough to fully understand where to plug it in. In
> >> the
> >> > constructor of a page, I can check the page map name, but how would I
> do
> >> the
> >> > redirect here? Conversely, I can override onBeginRequest() in the
> >> request
> >> > cycle, but in this case, how would I check the page map name and
> access
> >> > other page details in order to redirect to the same page? Sorry if
> I'm
> >> > being dim here, but some more details would be greatly appreciated.
> >> >
> >> > And yes, pages shouldn't take a long time to load, it's just that in
> >> > some
> >> > applications it's hard to guarantee that it will never happen, and
> we'd
> >> like
> >> > to handle all cases to make our application as robust as possible.
> >> >
> >> > Regards,
> >> > Jan
> >> >
> >> >
> >> > 2008/8/29 Johan Compagner <[EMAIL PROTECTED]>
> >> >
> >> >> Yes your observation is exactly what i described.
> >> >>
> >> >> What you can do is for example check in the constructor (with pagemap
> >> >> param) or in onbegin request (before render) of a page, if the
> pagemap
> >> >> is the default, if it is create the same page with a new pagemap and
> >> >> redicect to that one.
> >> >>
> >> >> Whay you want is that the default pagemap is never used, by defaul
> all
> >> >> pages are going into that
> >> >>
> >> >> But you should check if you really want long running processes like
> >> that!
> >> >>
> >> >> Jihan
> >> >>
> >> >> On 8/29/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> >> >> > Thanks for your answers, Matej and Johan.
> >> >> >
> >> >> > Matej: we are running with multi-window support on, and store
> >> per-window
> >> >> > related navigation in the session keyed on page map name. This
> works
> >> >> fine
> >> >> > most of the time.
> >> >> >
> >> >> > Johan: I've been stepping through the Wicket code and studying the
> >> docs
> >> >> to
> >> >> > understand how it deals with new windows, and I think I'm starting
> to
> >> >> > understand what's happening, and your comments about default page
> >> maps.
> >> >> >
> >> >> > Basically what seems to be the case is that the inital window in a
> >> >> session
> >> >> > never receives its own page map name, it stays on the default one.
> >> This
> >> >> > means that this initial window is indistinguishable from a brand
> new
> >> >> window
> >> >> > that hasn't yet had a page map name allocated and been redirected
> to
> >> >> > a
> >> >> page
> >> >> > with this set. I've done some tests which seem to confirm this
> >> >> hypothesis:
> >> >> >
> >> >> > - I open an initial browser window on my application (window 1)
> >> >> > - I open a second window in the same session (window 2)
> >> >> >
> >> >> > If a start a long-running operation in window 1, any new windows
> >> created
> >> >> > will lock until window 1's operation has been completed.
> >> >> > However, if I start the long-running operation in window 2, I can
> >> >> > open
> >> >> new
> >> >> > windows to my heart's content and they will not block.
> >> >> >
> >> >> > Does that make sense, is this an accurate description of the
> problem?
> >> >> >
> >> >> > It seems odd that the initial window is never allocated a page map
> >> name,
> >> >> > which leads to this assymtry between windows. Is this something
> that
> >> >> > can
> >> >> be
> >> >> > fixed? Or even better, can I do something my side in order to
> force
> >> any
> >> >> > window/page map opened against a session to have a unique name
> >> >> > allocated?
> >> >> >
> >> >> > Regards,
> >> >> > Jan
> >> >> >
> >> >> >
> >> >> > 2008/8/29 Johan Compagner <[EMAIL PROTECTED]>
> >> >> >
> >> >> >> And even with that check it will not work.
> >> >> >> If you open a new tab then the first page wicket will render when
> >> >> >> you
> >> >> >> type in an url will be the defaul pagemap. Only on the first page
> >> >> >> rendered we know that we have to redirect. So that first page will
> >> >> >> be
> >> >> >> blocked. The only thing that could maybe help is never use the
> >> >> >> defaul
> >> >> >> pagemap. So always use from the first page on a differnt one. And
> if
> >> >> >> you then see that a defaul pagemap request is done in your page,
> >> >> >> create a new pagemap and redirect again.
> >> >> >>
> >> >> >> On 8/29/08, Matej Knopp <[EMAIL PROTECTED]> wrote:
> >> >> >> > Only if multi window support is on (which is off by default with
> >> >> >> > secondlevelcachesessionstore). The multiwindow support is more
> or
> >> >> >> > less
> >> >> >> > a hack, because HTTP doesn't really provide any means to detect
> >> >> >> > browser windows/tabs.
> >> >> >> >
> >> >> >> > -Matej
> >> >> >> >
> >> >> >> > On Fri, Aug 29, 2008 at 2:28 AM, Jan Stette <
> [EMAIL PROTECTED]>
> >> >> >> wrote:
> >> >> >> >> I agree, that's a better long-term fix. Even so, isn't it
> wrong
> >> >> >> >> that
> >> >> >> the
> >> >> >> >> request from a new window is locked waiting on the other
> window's
> >> >> page
> >> >> >> map
> >> >> >> >> -
> >> >> >> >> I would have thought the new window should have ended up with
> its
> >> >> >> >> own
> >> >> >> page
> >> >> >> >> map?
> >> >> >> >>
> >> >> >> >> Regards,
> >> >> >> >> Jan
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> 2008/8/29 Matej Knopp <[EMAIL PROTECTED]>
> >> >> >> >>
> >> >> >> >>> Hi,
> >> >> >> >>>
> >> >> >> >>> the long running process should be executed in separate
> thread.
> >> You
> >> >> >> >>> can make wicket periodically poll for result (via ajax). It is
> >> >> >> >>> generally not a good idea to run action that potentially can
> >> >> >> >>> take
> >> >> long
> >> >> >> >>> time to complete from a request thread.
> >> >> >> >>>
> >> >> >> >>> -Matej
> >> >> >> >>>
> >> >> >> >>> On Thu, Aug 28, 2008 at 8:42 PM, Jan Stette <
> >> [EMAIL PROTECTED]>
> >> >> >> wrote:
> >> >> >> >>> > I'm having a problem with the following scenario:
> >> >> >> >>> >
> >> >> >> >>> > 1. A user logs into our Wicket application and starts using
> >> it.
> >> >> >> >>> > 2. The user clicks on a link which kicks off a potentially
> >> >> >> >>> > long-running
> >> >> >> >>> > operation.
> >> >> >> >>> > 3. While getting bored with waiting for this to complete,
> the
> >> >> user
> >> >> >> >>> copies
> >> >> >> >>> > the URL from her browser into another tab or window.
> >> >> >> >>> >
> >> >> >> >>> > Unfortunately, at this stage, the second window is locked
> and
> >> >> times
> >> >> >> out
> >> >> >> >>> with
> >> >> >> >>> > a message "pagemap is still locked after one minute".
> >> >> >> >>> > Should this work? Stepping through the second request in
> the
> >> >> >> debugger,
> >> >> >> >>> it
> >> >> >> >>> > appears that it this request has a page map name = null, as
> >> >> >> >>> > has
> >> >> the
> >> >> >> >>> previous
> >> >> >> >>> > request ( in the long running thread). So they seem to pick
> >> >> >> >>> > up
> >> >> the
> >> >> >> >>> > same
> >> >> >> >>> > page map. Presumably this is wrong; multiple windows should
> >> each
> >> >> >> have
> >> >> >> >>> their
> >> >> >> >>> > unique page map? Or does the magic that detects new windows
> >> >> >> >>> > hence
> >> >> >> new
> >> >> >> >>> page
> >> >> >> >>> > maps to be created break down in cases like this?
> >> >> >> >>> >
> >> >> >> >>> > Regards,
> >> >> >> >>> > Jan
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>>
> >> >> ---------------------------------------------------------------------
> >> >> >> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> >> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
