Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!

2010-06-16 Thread Bryan Montgomery
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!!!

2010-06-08 Thread nino martinez wael
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!!!

2010-06-08 Thread Bryan Montgomery
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!!!

2010-06-07 Thread Bryan Montgomery
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!!!

2010-06-07 Thread Edward Zarecor
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!!!

2010-06-07 Thread fastone

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



Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!

2010-06-04 Thread Bryan Montgomery
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


Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!

2010-06-04 Thread James Carman
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!!!

2010-06-04 Thread Bryan Montgomery
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!!!

2010-06-04 Thread gnul

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

2010-06-04 Thread Bryan Montgomery
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!!!

2010-06-04 Thread Scott Swank
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!!!

2010-06-04 Thread Igor Vaynberg
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