Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
I haven't got to the bottom of it exactly, but it's related to our (my) attempt to integrate jcifs and ntml SSO in to the application. It's gone back now to our main software vendor to figure out from here. Bryan. On Tue, Jun 8, 2010 at 8:46 AM, Bryan Montgomery mo...@english.net wrote: 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
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
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.comwrote: 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
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
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
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
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.comwrote: 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
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
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
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
Hi Recently, I have seen a similar issue, on one server apache was forcing compatibility view and on other its not doing that. So some js screwed up. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Frustrating-behavior-same-browser-same-war-same-tomcat-version-different-behavior-tp2243432p2246307.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
Have you tried clearing your cache on your browsers?
On Fri, Jun 4, 2010 at 11:57 AM, Bryan Montgomery mo...@english.net wrote:
Hello,
I've been banging my head against the proverbial brick wall for the last
day. I have a fairly large web application which I've been modifying part
of.
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.
This has been tried on both ie 7 and ie 8 with the same results.
Looking at the html on the browser, it is pretty simple. If I save the file
to the local machine and replace the relative links with absolute links I
can't reproduce the errors - although I do get javascript errors. Comparing
the html between the working server and the problematic server, the only
difference is wicket field references.
Comparing the javascript files and ccs files, they are identical. I'm
guessing it has something to do with the onblur in the html below - but why
would it exhibt a different behavior between the servers? I'm not sure why
we're using ajax there as the page doesn't have any ajax / callback features
to it as far as I know.
Is there some other tomcat setting that could be effecting this? Somewhere
else I should look?
Thanks,
Bryan.
html xmlns='http://www.w3.org/1999/xhtml' lang='en'
headlink rel=stylesheet type=text/css
href=../../../../resources/com.abc.reports.page.MainPage/style/nrgWeb.css
view-source:http://coned-avl:8080/nrg/app/resources/com.samsix.reports.page.MainPage/style/nrgWeb.css
/
link type='image/x-icon' rel='icon'
href='../../../../../favicon_oru.ico
view-source:http://coned-avl:8080/nrg/favicon_oru.ico' /
link type='image/x-icon' rel='shortcut icon'
href='../../../../../favicon_oru.ico
view-source:http://coned-avl:8080/nrg/favicon_oru.ico' /
script type=text/javascript
src=../../../../resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js
view-source:http://coned-avl:8080/nrg/app/resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/script
script type=text/javascript
src=../../../../resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
view-source:http://coned-avl:8080/nrg/app/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js/script
/headbody topmargin='0'
titleAnalysis/title
span class='pageTitle'Single Analysis/span
span
a href=../../../../startup
view-source:http://coned-avl:8080/nrg/app/startup
span
img
src=../../../../resources/org.apache.wicket.Application/back_button
view-source:http://coned-avl:8080/nrg/app/resources/org.apache.wicket.Application/back_button
border=0/
/span
/a
/span
br /
h1 class='reportMenu'Analysis/h1
h1 class='reportDescription'Single pass analysis./h1
span
/span
form id=queryForm7 method=post
action=../../../../?wicket:interface=:7:queryForm::IFormSubmitListener::div
style=display:noneinput type=hidden name=queryForm7_hf_0
id=queryForm7_hf_0 //div
table
tr
td
span class=labelCircuit/span
/td
td
input type=text value= name=circuitField
id=circuitField8 onblur=var
wcall=wicketAjaxPost('../../../../?wicket:interface=:7:queryForm:circuitField::IBehaviorListener:0:4',
wicketSerialize(Wicket.$('circuitField8')),null,null, function()
{return Wicket.$('circuitField8') != null;}.bind(this));/
/td
/tr
tr
td
span class=labelSegment/span
/td
td
input type=text value= name=segmentField
id=segmentField9 onblur=var
wcall=wicketAjaxPost('../../../../?wicket:interface=:7:queryForm:segmentField::IBehaviorListener:0:4',
wicketSerialize(Wicket.$('segmentField9')),null,null, function()
{return Wicket.$('segmentField9') != null;}.bind(this));/
/td
/tr
tr
td /td
td align='right'
input type='submit' name='submit' value='Execute Query' /
/td
/tr
/table
/form
/body
/html
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
Yeah, I thought it might be as simple as that - but unfortunately not.
On Fri, Jun 4, 2010 at 12:29 PM, James Carman ja...@carmanconsulting.comwrote:
Have you tried clearing your cache on your browsers?
On Fri, Jun 4, 2010 at 11:57 AM, Bryan Montgomery mo...@english.net
wrote:
Hello,
I've been banging my head against the proverbial brick wall for the last
day. I have a fairly large web application which I've been modifying part
of.
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.
This has been tried on both ie 7 and ie 8 with the same results.
Looking at the html on the browser, it is pretty simple. If I save the
file
to the local machine and replace the relative links with absolute links I
can't reproduce the errors - although I do get javascript errors.
Comparing
the html between the working server and the problematic server, the only
difference is wicket field references.
Comparing the javascript files and ccs files, they are identical. I'm
guessing it has something to do with the onblur in the html below - but
why
would it exhibt a different behavior between the servers? I'm not sure
why
we're using ajax there as the page doesn't have any ajax / callback
features
to it as far as I know.
Is there some other tomcat setting that could be effecting this?
Somewhere
else I should look?
Thanks,
Bryan.
html xmlns='http://www.w3.org/1999/xhtml' lang='en'
headlink rel=stylesheet type=text/css
href=../../../../resources/com.abc.reports.page.MainPage/style/nrgWeb.css
view-source:
http://coned-avl:8080/nrg/app/resources/com.samsix.reports.page.MainPage/style/nrgWeb.css
/
link type='image/x-icon' rel='icon'
href='../../../../../favicon_oru.ico
view-source:http://coned-avl:8080/nrg/favicon_oru.ico' /
link type='image/x-icon' rel='shortcut icon'
href='../../../../../favicon_oru.ico
view-source:http://coned-avl:8080/nrg/favicon_oru.ico' /
script type=text/javascript
src=../../../../resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js
view-source:
http://coned-avl:8080/nrg/app/resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js
/script
script type=text/javascript
src=../../../../resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
view-source:
http://coned-avl:8080/nrg/app/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
/script
/headbody topmargin='0'
titleAnalysis/title
span class='pageTitle'Single Analysis/span
span
a href=../../../../startup
view-source:http://coned-avl:8080/nrg/app/startup
span
img
src=../../../../resources/org.apache.wicket.Application/back_button
view-source:
http://coned-avl:8080/nrg/app/resources/org.apache.wicket.Application/back_button
border=0/
/span
/a
/span
br /
h1 class='reportMenu'Analysis/h1
h1 class='reportDescription'Single pass analysis./h1
span
/span
form id=queryForm7 method=post
action=../../../../?wicket:interface=:7:queryForm::IFormSubmitListener::div
style=display:noneinput type=hidden name=queryForm7_hf_0
id=queryForm7_hf_0 //div
table
tr
td
span class=labelCircuit/span
/td
td
input type=text value= name=circuitField
id=circuitField8 onblur=var
wcall=wicketAjaxPost('../../../../?wicket:interface=:7:queryForm:circuitField::IBehaviorListener:0:4',
wicketSerialize(Wicket.$('circuitField8')),null,null, function()
{return Wicket.$('circuitField8') != null;}.bind(this));/
/td
/tr
tr
td
span class=labelSegment/span
/td
td
input type=text value= name=segmentField
id=segmentField9 onblur=var
wcall=wicketAjaxPost('../../../../?wicket:interface=:7:queryForm:segmentField::IBehaviorListener:0:4',
wicketSerialize(Wicket.$('segmentField9')),null,null, function()
{return Wicket.$('segmentField9') != null;}.bind(this));/
/td
/tr
tr
td/td
td align='right'
input type='submit' name='submit' value='Execute Query' /
/td
/tr
/table
/form
/body
/html
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
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
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
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
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
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
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
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
