Forgot to forward to the JSP-INTEREST mailing list. "Craig R. McClanahan" wrote: > Volker Stiehl wrote: > > > Hello Craig, > > I followed your discussion about the application object and especially your > > description about the three cases stated below leads to another question: > > what about objects I've placed in the Servlet Context: are they accessible > > for beans placed in jsp-files? > > Example: a servlet creates a database connection pool and every bean in my > > application should use this connection pool, therefore the servlet has to > > place this "connection pool object" in the Servlet Context. But how can a > > bean access this object? The 0.92 spec says, that a bean can contain a > > processRequest() method, which takes a HttpServletRequest as a parameter, > > so I can access the objects in page scope and session scope with the > > request.getAttribute() and request.getSession() calls respectively, as you > > mentioned below. But what about the application scope? Can you clarify > > this? > > Thank you very much > > Volker Stiehl > > > > That's a pretty interesting question. > > The JSP page can certainly treat the things you store in the servlet context > as a bean (with lifespan=application), but i don't think there are any defined > mechanisms for beans to reference other beans. Thus, you could create a > USEBEAN reference to the connection-holding bean, and access it from within > the JSP page itself (such as in <% %> scriptlets), but not from other beans. > > Personally, I've never felt any need for this, though, because I always use > the "Model 2" application design approach that is described in the JSP 0.92 > specification. In such a case, I would do as you are suggesting, and store a > JDBC connection or connection pool in the servlet context. But, in my > designs, it is always real servlets that use the connection to look up things, > then create "results" beans (normally stored in the request or session, > depending on lifespan requirements), and then forward control to the > appropriate JSP page to display the results. Thus, I never run in to the need > for inter-bean references. (Come to think of it, I have yet to need > processRequest() for anything, either). > > For my designs, I'm not at all interested in mixing program logic in my JSP > page itself, because I believe the resulting mix of display formatting and > logic will be much harder to maintain in the future, versus an environment > where *all* of the logic is implemented in servlets, and *all* of the display > logic is in JSP pages, with beans being the glue that binds everything > together. I've done my share of applications where real servlets generate all > of the HTML (basically, the same mixing problem in reverse), and it is a real > pain to try to enhance things when the logic and the display rules are > intertwined. > > By the way, the current servlet API spec (2.1) is missing an important feature > related to storing things in servlet contexts -- there is no equivalent to the > HttpSessionBindingListener interface for objects being bound or unbound from a > session. If you put a database connection into the servlet context, for > example, there is currently no convenient way to close the connection when the > servlet engine is shutting down -- this would be easy if there was something > like ServletContextBindingListener, so the bean containing your connection > could be told that it was being removed from the servlet context, and it could > close itself down cleanly. This will probably be addressed in a future > version of the servlet API spec. > > Craig McClanahan =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
