Hi Daniel, good idea, we can add some log messages exposing the page map
creation and how close it is from its max limit. I think your new problem of
have multiple page maps without user click on the popup link is related to
WICKET-3109 <https://issues.apache.org/jira/browse/WICKET-3109>
<https://issues.apache.org/jira/browse/WICKET-3109>Anyway, you can simple
increase your max page map number by
calling ISessionSettings#setMaxPageMaps.

On Tue, Feb 8, 2011 at 10:11 AM, Daniel Soneira
<[email protected]>wrote:

> Is it maybe possible to give the developer / user some clues (better /
> different error message) in such a situation?
> I'm trying to understand how there can be > 5 pageMaps if the application
> just started and only 1 page is displayed (no other action taken at that
> point in time).
> Can someone explain that to me? I thought pageMaps are only created when a
> new window (e.g. popup) is shown to the user.
>
> That's how I've used to think of it:
>    User clicks link with popup settings => create new page map.
>    User opens new tab => create new page map.
>
> I was already aware of the fact that 1.5 does not deal with page maps
> anymore, that's why I tried (by pure desperation at that point) to migrate
> the whole application to 1.5 RC1 but that just lead to other problems (topic
> of another mailing list entry I'll post soon when I get around to reproduce
> in a QuickStart).
>
>
> On 07.02.2011 14:58, Pedro Santos wrote:
>
>> I'm afraid that the opposite statement is the right one :)
>> The version 1.4.12 wasn't respecting the max page map, than your app was
>> relying on the fact that it could always get page versions from it's page
>> map. Since this bug get resolved, you need to pay close attention to how
>> page map is getting managed if you want to keep using the max page map
>> property.
>> As a side note, Wicket 1.5 don't have page maps any more, page still get
>> incremented versions, but not in an specific page map.
>>
>> On Mon, Feb 7, 2011 at 8:53 AM, Daniel Soneira<[email protected]
>> >wrote:
>>
>>  Hi Pedro,
>>>
>>> I've increased the max page map setting from 5 to 10 and the exception
>>> went
>>> away.
>>> Thanks for the suggestion - for a quick fix that is good enough for now
>>> :)
>>> Still it seems like a bug.
>>> Can I help with some specific logs to determine the source of the
>>> problem?
>>>
>>> Regards,
>>> Daniel
>>>
>>>
>>> On 04.02.2011 18:15, Pedro Santos wrote:
>>>
>>>  Hi Daniel, try to increase the application max page map number, if the
>>>> problem remains we can eliminate the WICKET-3108 as the source.
>>>>
>>>> On Fri, Feb 4, 2011 at 2:46 PM, Daniel Soneira<
>>>> [email protected]
>>>>
>>>>> wrote:
>>>>>
>>>>  Hi there,
>>>>
>>>>> I'm experiencing a weird problem that I've tried to solve for 2 days
>>>>> now.
>>>>>
>>>>> After updating Wicket from 1.4.12 to the latest version (1.4.15)
>>>>> because
>>>>> of
>>>>> WICKET-3136 (JVM 1.6 crash) one particular page (bookmarkable) always
>>>>> throws
>>>>> a PageExpiredException on clicking an AjaxSubmitLink. I simply start
>>>>> the
>>>>> application, open the page, click the link =>   BAM, exception!
>>>>>
>>>>> The curious thing about this is that, if I just remove (== not add) one
>>>>> other button (from a group of 3 - all doing nearly the same thing) it
>>>>> works.
>>>>> Those 3 buttons all subclass a nested abstract inner class inside
>>>>> another
>>>>> nested class of the page. Also there are a lot of buttons / menu items
>>>>> on
>>>>> that page.
>>>>> But that one exact button is not causing the problem because I can
>>>>> remove
>>>>> any of those 3 buttons of the group to get it working.
>>>>>    2 of those buttons: GOOD
>>>>>    3 of those buttons: EXCEPTION
>>>>>
>>>>> The problem also vanishes if I remove code from the buttons that
>>>>> reference
>>>>> the page implicitly like the following:
>>>>>
>>>>> == CODE ==
>>>>>
>>>>> public void onConfigure() {
>>>>>    super.onConfigure();
>>>>>    setEnabled(isFormEnabled()&&   isDetailObjectPersistent());
>>>>> }
>>>>>
>>>>> == == == ==
>>>>>
>>>>> Here isFormEnabled and isDetailObjectPersistent are methods of the PAGE
>>>>> not
>>>>> the buttons.
>>>>>
>>>>> Essentially it looks like there is a problem serializing the whole
>>>>> page,
>>>>> which is why the page map is null inside the following code block from
>>>>> WebRequestCycleProcessor.resolve:
>>>>>
>>>>> == CODE ==
>>>>>    if (requestParameters.isOnlyProcessIfPathActive())
>>>>>    {
>>>>>        .....
>>>>>        if (pageMap == null) {
>>>>>            processRequest = 1;
>>>>>        }
>>>>>    ....
>>>>>    }
>>>>>
>>>>> == == == ==
>>>>>
>>>>> I've tested all versions after 1.4.12 and they all show the same
>>>>> behavior
>>>>> while 1.4.12 itself works for this case.
>>>>> I don't think I'm able to reproduce this in a QuickStart without some
>>>>> major
>>>>> effort since there is a deep class hierarchy involved, but I guess this
>>>>> issue has something to do with WICKET-3108 (Problems with page maps
>>>>> stored
>>>>> in session). I've tried to do a QuickStart with a simple test page with
>>>>> nested classes - but that worked (sadly).
>>>>>
>>>>> Also I'm having one @SpringBean inside the page that is used by those
>>>>> buttons which seem to cause trouble.
>>>>> Maybe someone can point me in the right direction?
>>>>>
>>>>> Because of WICKET-3136 staying with 1.4.12 unfortunately is not an
>>>>> option
>>>>> for us.
>>>>> Any help is really appreciated.
>>>>>
>>>>>
>>>>> Kind regards,
>>>>> Daniel
>>>>>
>>>>> PS: I know no one is looking forward to digging into a serialization /
>>>>> page
>>>>> expired problem but maybe someone has mercy and helps me out on this
>>>>> one.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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]
>
>


-- 
Pedro Henrique Oliveira dos Santos

Reply via email to