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
>
>

Reply via email to