In the JSP, I added a <s:property value="request"/> line to see what bean it was finding by the name and it accurately printed out the bean which I was expecting it to be finding by the name. To be safe, I did go ahead and renamed the bean to something a bit more descriptive (ie: calibrationRequest) and retested by pushing the new bean name on the stack and it still behaved the same way; no output.
I did go through and double check the base action of the particular executing action and nothing stood out around "request" and the fact the page was printing out the name of the bean correctly in the JSP supported my theory that it wasn't reading or pulling anything from any parent class objects that it shouldn't have been doing either; thus the name change would have also stopped that as well or any conflicts with "request" in OGNL. FWIW, I am using 2.1.8.1 which is the same version as what is on the servers. The only things that had changed is the introduction of Spring Security 3.1 to the framework and Spring's upgrade from 3.0.2 to 3.0.5; however I had not experienced any issues with the s:push tag on other pages; just this particular one :-/. Well anyhow, false alarm. After a bit more careful digging; I found that a tag in the s:include page being included right after the s:push statement was the culprit to the problem and was throwing the entire page's rendering off. For whatever reason, the tag was not recording the error in any log or dumping the error to the page. I just happened to comment out the code in the included page which lead me to realize it was something with the "include" page and not the push tag itself ... Thanks for the help tho Dave. Chris > -----Original Message----- > From: Dave Newton [mailto:davelnew...@gmail.com] > Sent: Friday, April 15, 2011 9:15 AM > To: Struts Users Mailing List > Cc: CRANFORD, CHRIS > Subject: Re: s:push problem > > (I'm always nervous when business logic names something the same as > something servlet-ish.) > > My first assumption would be that the pushed object is masking > underlying properties. Don't know why it would start now--did you > check the changelog for the release you're currently using? > > Don't know what version(s) you're comparing, don't know what's being > pushed, don't know what the expected vs. actual behavior is, so can't > help beyond that. > > Dave > > On Fri, Apr 15, 2011 at 10:09 AM, CRANFORD, CHRIS > <chris.cranf...@setech.com> wrote: > > I am noticing a strange behavior on my development machine where a > POJO > > when pushed onto the top of the stack using s:push is causing tags > such > > as s:include not to work. In the action being executed, there is a > > property in the action called request which represents a POJO of type > > CalibrationRequest. The action has a method called getRequest() > which > > returns this value. If I remove the s:push and use request.property > in > > the JSP; the data is rendered fine. I don't see any errors in the > logs > > either as to why I am encountering this problem. > > > > Ironically though, the last build on my non-development server is > > working as intended and I recall this functionality worked as > intended > > on my laptop when I last used it. Can anyone offer any reason for > why > > this could be an issue now or what I should look at to try and > diagnose > > the issue? > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > For additional commands, e-mail: user-h...@struts.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
