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