Thanks for all the ideas and interest - I still haven't solved it.

It did seem to work for a while but then as I changed a configuration to
prove what was broken - I haven't been able to get it working again.

I'm thinking it is some sort of caching issue - but I can't find any
settings, tomcat is running as root so it shouldn't be any permission issues
......

I need to move on with the project so I am probably just going to get a new
virtual server built. I want to keep the old around because it is bugging
the heck out of me :)

On Tue, Jun 8, 2010 at 6:58 AM, nino martinez wael <
nino.martinez.w...@gmail.com> wrote:

> did you solve this yet?
>
> 2010/6/7 Bryan Montgomery <mo...@english.net>:
> > 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
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to