You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Bryan Montgomery <mo...@english.net> on 2010/06/04 17:57:44 UTC
Frustrating behavior ... same browser, same war, same tomcat version
- different behavior!!!
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'>
<head><link 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>
</head><body topmargin='0'>
<title>Analysis</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:none"><input type="hidden" name="queryForm7_hf_0"
id="queryForm7_hf_0" /></div>
<table>
<tr>
<td>
<span class="label">Circuit</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="label">Segment</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!!!
Posted by Bryan Montgomery <mo...@english.net>.
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.com>wrote:
> 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'>
> >
> >
> > <head><link 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>
> >
> > </head><body topmargin='0'>
> > <title>Analysis</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:none"><input type="hidden" name="queryForm7_hf_0"
> > id="queryForm7_hf_0" /></div>
> >
> > <table>
> > <tr>
> > <td>
> > <span class="label">Circuit</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="label">Segment</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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by James Carman <ja...@carmanconsulting.com>.
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'>
>
>
> <head><link 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>
>
> </head><body topmargin='0'>
> <title>Analysis</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:none"><input type="hidden" name="queryForm7_hf_0"
> id="queryForm7_hf_0" /></div>
>
> <table>
> <tr>
> <td>
> <span class="label">Circuit</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="label">Segment</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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by fastone <au...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by Edward Zarecor <wi...@indeterminate.org>.
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.vaynberg@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 <sc...@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 <nu...@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-unsubscribe@wicket.apache.org
> > >>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>
> > >>>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by Bryan Montgomery <mo...@english.net>.
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.wael@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.vaynberg@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 <sc...@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 <nu...@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-unsubscribe@wicket.apache.org
>> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by Bryan Montgomery <mo...@english.net>.
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.wael@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.vaynberg@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 <sc...@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 <nu...@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-unsubscribe@wicket.apache.org
> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by nino martinez wael <ni...@gmail.com>.
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 <ig...@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 <sc...@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 <nu...@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-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by 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 <ig...@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 <sc...@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 <nu...@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-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <sc...@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 <nu...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by Scott Swank <sc...@gmail.com>.
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 <nu...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by Bryan Montgomery <mo...@english.net>.
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 <nu...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Frustrating behavior ... same browser, same war, same tomcat
version - different behavior!!!
Posted by gnul <nu...@gmail.com>.
>
> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org