Thanks - this is still puzzling me. This is a virtual machine. I did just try the war on another virtual machine and it worked as expected. I think I'm about to rebuild the server.
I don't have any clustering, and not using apache, just hitting tomcat directly. One thing I noticed from the profiling on IE8 is that on the servers that worked normally, the postbacks had the jsessionid appended to the url. The non-working server is missing that so I'm doing a little bit of digging to see if I can find a reason why that may be happening. Cheers - Bryan. On Fri, Jun 4, 2010 at 7:33 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > right, sounds like the session is being lost and the page is being > rerendered fresh. > > -igor > > On Fri, Jun 4, 2010 at 1:46 PM, Scott Swank <scott.sw...@gmail.com> wrote: > > Do you have apache or a load balancer or anything else in the network? > > Is there maybe a simple difference in your httpd.conf pertaining to > > sessions? > > > > On Fri, Jun 4, 2010 at 1:32 PM, Bryan Montgomery <mo...@english.net> > wrote: > >> Thanks for the ideas. Still no joy. > >> > >> The behavior is consistent between three different clients, all running > >> different versions of IE (6,7 and 8). > >> I was able to use the debugging feature built in to IE 8 to see that the > >> wicket ajax javascript was gettting called. At some point in that > process it > >> lost the value of the field and it got set to an empty field. > >> > >> I have the feeling that there is something different with the > environment on > >> this particular server - but I have no idea what at this point. > >> > >> On Fri, Jun 4, 2010 at 1:32 PM, gnul <nullc...@gmail.com> wrote: > >> > >>> > > >>> > Essentially, part of the process generates dynamic web forms based on > xml > >>> > configuration files. We noticed that on one of our servers when we > >>> deployed > >>> > the war file that the fields would not hold their values, and as soon > as > >>> you > >>> > tabbed out, the entry would disappear. Taking the same war file and > >>> > deploying it to another server the form acts as expected. > >>> > > >>> > >>> If it works on one server, but not the other, and they are configured > >>> the same (meaning same appserver/tomcat version, same jvm, same > >>> user/group/perms, etc.), the first thing I do is "clean" the appserver > >>> and do a fresh deploy. > >>> > >>> For example, say you are deploying to /var/lib/tomcat/webapps/, I > >>> would shutdown both tomcats, remove the exploded directories (e.g. > >>> myapp.war => myapp/ ) and re-deploy the war files to each server. I > >>> would also clean out tomcat's temp directory (e.g. > >>> /var/cache/tomcat5/temp), then restart them both. > >>> > >>> -gnul > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >>> For additional commands, e-mail: users-h...@wicket.apache.org > >>> > >>> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >