Hmm.. yeah.. that even seems like it could not be fool proof. I.E. Wicket checks that components are serializable not Externalizable.
I'm curious if anybody that is running wicket in a cluster has experienced this, or how you deal with deploying changes to the signature of a component. D/ On Mar 7, 2010, at 2:42 PM, James Carman wrote: > You can implement Externalizable and manage it all yourself. > > On Sun, Mar 7, 2010 at 3:39 PM, Douglas Ferguson > <[email protected]> wrote: >> How do you prevent developers from renaming fields on components. >> That seems really dangerous. >> >> i.e. what seems like a simple refactor to correct a spelling mistake could >> result in sessions not being deserialized. >> >> D/ >> >> On Mar 6, 2010, at 11:10 AM, Igor Vaynberg wrote: >> >>> not with java serialization afaik >>> >>> -igor >>> >>> On Sat, Mar 6, 2010 at 6:52 AM, Douglas Ferguson >>> <[email protected]> wrote: >>>> I can't deal with removing fields or changing method >>>> signatures/implementations? >>>> >>>> D/ >>>> >>>> On Mar 6, 2010, at 12:58 AM, Igor Vaynberg wrote: >>>> >>>>> as long as all you do is add fields you are ok... >>>>> >>>>> -igor >>>>> >>>>> On Fri, Mar 5, 2010 at 8:16 PM, Douglas Ferguson >>>>> <[email protected]> wrote: >>>>>> So as long as the serial I'd is the same the classlader won't care the >>>>>> fields don't match? >>>>>> >>>>>> Douglas Ferguson >>>>>> 512-293-7279 >>>>>> Sent from my iPhone >>>>>> >>>>>> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> in the wicket code we override serial ids to 1, you should do the same >>>>>>> in your code. >>>>>>> >>>>>>> -igor >>>>>>> >>>>>>> On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson >>>>>>> <[email protected]> wrote: >>>>>>>> I'm considering a 0 downtime deployment but am concerned with the >>>>>>>> amount of state in the wicket session. >>>>>>>> >>>>>>>> This is the scenario that concerns me. >>>>>>>> >>>>>>>> 1) There are 2 tomcats running >>>>>>>> 2) A change is made to a serializable object and the serial version >>>>>>>> id is updated >>>>>>>> 3) 1 tomcat instance is taken down for updating >>>>>>>> 4) tomcat instance comes back up with new object and now tries to >>>>>>>> update state from other tomcat and the wicket session has a >>>>>>>> reference to the old version of the serializable. >>>>>>>> >>>>>>>> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote: >>>>>>>> >>>>>>>>> yes >>>>>>>>> >>>>>>>>> -igor >>>>>>>>> >>>>>>>>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> Has anybody had success with wicket using tomcat's session >>>>>>>>>> replication? >>>>>>>>>> >>>>>>>>>> D/ >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> 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] >> >> > > --------------------------------------------------------------------- > 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]
