Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Beans disappearing from request.

 
Jon Senior
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Edited to make the code more readable. Sorry.

I have a problem with Struts, which is almost certainly due to a misunderstanding of struts-config.xml. The situation is as follows.

I have a Forward to a page which presents a list of reports. Choosing one of these reports forwards to a form containing the parameters for the report. Submitting the report forwards to a third page which should display the generated report. "Should", because it's failing with a Cannot find bean xxx in any scope error.

The relevant parts of struts-config.xml (dgemapReportForm is defined earlier as is a ViewReports Global Foward):

The relevant parts of ViewReportAction:

The revelant bit of reportParams.jsp:

And of reportResults.jsp

As this code stands, the com.dgemap.test bean is not found (nor were the other ones before I commented them out!).

Note that the attributes are set correctly in the relevant parts of ViewReportAction.java and that this works fine for the reportParams page. It's when forwarding to reportResults that it "loses" them. I have debug statements in the log that demonstrates that the attributes are set correctly,so the problem lies within the Struts framework, but I don't see what I've done wrong. The configuration in struts-config.xml was copied from a working part of the web app (albeit a part which works a little differently) and then modified to suit this situation. I guess I might be able to simply put all of this into session scope , but I'd really rather not. It shouldn't need to be.

Thanks in advance for any help offered.

Jon
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please use code tags; I can't really read any of that.
 
Jon Senior
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:Please use code tags; I can't really read any of that.


Done. Sorry about that.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So you're saying that in reportResults.jsp there's no bean named "com.dgemap.reportResults"?
 
Jon Senior
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:So you're saying that in reportResults.jsp there's no bean named "com.dgemap.reportResults"?


Yep (Nor is there "com.dgemap.test"). As you can see, in the java snippet for reportResults(...) there's a series of calls to request.setAttribute which should setup the various beans for the jsp file. The same code is used in reportParams(...) and they appear in the corresponding jsp. None of the beans that I set up are making it to the jsp which suggests that I've got something wrong with the struts-config.xml. The reportResults(...) function contains code to dump the full list of attributes to standard out and all of the beans (attributes) that I add appear in the catalina.out logfile, but none of them are accessible from the jsp.

Is there a method within jsp to get a list of all the visible beans? Some collection that could be iterated over in a scriptlet? I strongly suspect that I'm getting something wrong in the forwarding, but I fail to see what it is (and I find the documentation for struts-config.xml to be a little sparse!).

Jon
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is the result of report.report(conn) something that can be iterated over?

HttpServletRequest has methods for getting its attributes; see the JavaDocs.
 
Jon Senior
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:Is the result of report.report(conn) something that can be iterated over?


Yes. It's a Vector<ReportResult>. But the issue is taht it's not just that bean. It's all of them. com.dgemap.test is a String which should be usable with <bean:write /> and com.dgemap.report is a ReportInterface object from which I should be able to pull the name (Using the same code as in reportParams.jsp).

David Newton wrote:HttpServletRequest has methods for getting its attributes; see the JavaDocs.


I used that to pull the attributes out in the Java code and dump them to the log, they're definitely there. They seem to vanish somewhere between the return mapping.findForward(...) and the jsp page.

The only other thing that I can think of is that it's in some way related to the fact that this is a Portlet, but I'm using the Struts-Portlet bridge and the rest of the (fairly large) webapp is working fine. This is what makes me think that it's my configuration that's gone awry.

Jon
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh; I don't know anything about portlets, but I know enough to know it makes a difference when accessing session/request/etc.

If you're saying the first method (reportParams(...)) works and the second one doesn't then I'd first check for other, portlet-related configuration regarding the action in question.
 
Jon Senior
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:Oh; I don't know anything about portlets, but I know enough to know it makes a difference when accessing session/request/etc.

If you're saying the first method (reportParams(...)) works and the second one doesn't then I'd first check for other, portlet-related configuration regarding the action in question.


I searched high and low and failed to find anything of use, so I eventually just popped the neccessary beans into session scope with request.getSession().setAttribute(String, Object). It's not elegant but it works, which is the main thing. Thanks for your help. It does appear to be related to the way that the Struts-Portlets bridge operates, although I'm still not entirely clear why this particular arrangement broke it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic