Then you dont throw the right thing, you should set a page as the
response opage thats in a different pagemap
On 9/8/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> 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]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
