So it seems that Tomcat is unable to set a cookie to store the session id
for the problematic domain as it will append it to the URL when all else
fails -- you may also be able to configure this as the default behavior.

Look at the differences between the hostname configurations comparing a
working server and a non-working server.

Ed.


On Mon, Jun 7, 2010 at 11:22 AM, Bryan Montgomery <mo...@english.net> wrote:

> 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