i have no idea. use something like liveheaders to make sure you are
consistently getting the same session id.

there is more info in HttpsRequestCycleProcessor javadoc.

-igor

On Tue, Jun 16, 2009 at 1:27 PM, Martin
Makundi<[email protected]> wrote:
>> this has nothing to do with how many servers you are running
>
> Does it matter that Apache handles the https and proxies it as plain
> http to jetty?
>
> **
> Martin
>
>>
>> -igor
>>
>> On Tue, Jun 16, 2009 at 12:56 PM, Martin
>> Makundi<[email protected]> wrote:
>>>> as far as wicket is concerned it does the best it can. when the
>>>> session is gone we have no state information at all and the only thing
>>>> we can do is display the page expired page. what exactly is
>>>> "unprofessional" about this.
>>>
>>> Well.. this crash :) It is not very 'graceful', maybe better wording
>>> than professionality....
>>>
>>>> btw, is your login page https? this may be caused by the fact that you
>>>> will have two different session ids: one secure and one not secure.
>>>
>>> This is actually true... however I have a single jetty listening to
>>> :8080 so I would presume it sees a single session.
>>>
>>> **
>>> Martin
>>>
>>>> On Tue, Jun 16, 2009 at 12:21 PM, Martin
>>>> Makundi<[email protected]> wrote:
>>>>> I have a feeling this has something to do with the littlebit
>>>>> 'unprofessional' way of wicket's dealing with session expiration on
>>>>> stateful pages. Wicket sort of deals with session expiration like if
>>>>> it was a fatal state.. while it is just daily bloody normal ;)
>>>>> Anyways... I will look into this, it's bugged me for 1 year now and I
>>>>> have managed to override it but not solve it.
>>>>>
>>>>> **
>>>>> Martin
>>>>>
>>>>> 2009/6/16 Igor Vaynberg <[email protected]>:
>>>>>> so the curiosity is why is wicket trying to submit the loginform to
>>>>>> the mainpage? i dont think i have seen anything like this before. if
>>>>>> you can find a way to reproduce it we will be happy to fix it.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Tue, Jun 16, 2009 at 11:54 AM, Martin
>>>>>> Makundi<[email protected]> wrote:
>>>>>>> No. MainPage is the page the user has probably bookmarked or 
>>>>>>> something.. it
>>>>>>> is the page after successful login.
>>>>>>> **
>>>>>>> Martin
>>>>>>>
>>>>>>> 2009/6/16 Igor Vaynberg <[email protected]>
>>>>>>>
>>>>>>>> is your LoginPage the com.domain.view.application.MainPage ?
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Tue, Jun 16, 2009 at 9:54 AM, Martin
>>>>>>>> Makundi<[email protected]> wrote:
>>>>>>>> > I am not actually sure how to repeat this bug, this is what I see on
>>>>>>>> > the production log.
>>>>>>>> >
>>>>>>>> > **
>>>>>>>> > Martin
>>>>>>>> >
>>>>>>>> > 2009/6/16 Igor Vaynberg <[email protected]>:
>>>>>>>> >> IFormSubmitListener? so this happens when you submit the login page?
>>>>>>>> >>
>>>>>>>> >> -igor
>>>>>>>> >>
>>>>>>>> >> On Tue, Jun 16, 2009 at 9:30 AM, Martin
>>>>>>>> >> Makundi<[email protected]> wrote:
>>>>>>>> >>>> IIRC, for this purpose I had written a separate expired page but 
>>>>>>>> >>>> I had
>>>>>>>> >>>> thrown a new restartresponseexception(LoginPage.class) which was
>>>>>>>> working
>>>>>>>> >>>> fine with wicket 1.3.4.
>>>>>>>> >>>
>>>>>>>> >>> So is there a bug with the pageparameters for a stateful page? They
>>>>>>>> >>> should be thrown away when pageExpired occurs (this happens
>>>>>>>> >>> automatically with restartresponseexception?)?
>>>>>>>> >>>
>>>>>>>> >>> Here is some more of the stack:
>>>>>>>> >
>>>>>>>> > ---------------------------------------------------------------------
>>>>>>>> > 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]
>>
>>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to