BTW Andrzej, in case you start thinking that Craig's design model, as he
describes it below, is odd, or different, and thus to be avoided, I would
encourage you to adopt it. I generally do the same things, although with
the 0.91 spec given I'm using WebSphere, and the approach is sound.
Good luck,
Dan
--
Daniel Kirkdorffer
NACN IS: 425-580-6225
Sr. Consultant, Syllogistics LLC
Email: [EMAIL PROTECTED]
Web: http://www.syllogistics.com/
> ----------
> From: Craig McClanahan[SMTP:[EMAIL PROTECTED]]
> Reply To: Craig McClanahan
> Sent: Tuesday, October 12, 1999 4:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Servlet/JSP Architecture
>
> Andrzej Kobus wrote:
>
> >
> >
> > I just started to work on a web based application. I think, I would
> > like to see it done this way. A client requests a URL.
> >
> > 1) The web server directs the URL request to a servlet.
> > 2) The servlet checks for the client's privileges
> > 3) The servlet creates beans or gets their references from the cache
> > and invokes a JSP passing the beans.
> > The goal is to have MVC type application.
> >
>
> Good design choice :-), although others will have different opinions.
>
> >
> > I have a few questions about the technology required to implement this
> > solution. I should probably add that this is going to be my first
> > internet application.
> >
> > To all of you I thank you in advance for any suggestions or code
> > samples.
> >
> > The questions are:
> >
> > 1) How do you create a global list of references (cache for beans).
> > The list has to be visible to all sessions. Scope etc.
> >
>
> The simplest way to make things available to everything in your
> application is to store it as an attribute in the servlet context. In a
> servlet, you might do something like this:
>
> MyObject mo = new MyObject(...);
> getServletContext().setAttribute("mo", mo);
>
> and a different servlet could retrieve it like this:
>
> MyObject mo =
> (MyObject) getServletContext().getAttribute("mo");
>
> or a JSP page could reference it like this:
>
> <jsp:useBean id="mo" scope="application"
> type="MyObject" />
>
> Note that the session attributes are not *directly* visible to beans
> themselves -- you'll need to pass the shared object as a parameter to
> some method in the bean to accomplish that.
>
> >
> > 2) How do you decide when to remove an object from cache if you don't
> > know for how long a user will be looking at a given page.
> >
>
> Ay, that's always the rub, isn't it? The answer is pretty application
> specific, and depends on the tradeoffs between how many users are
> looking at the same cached object, and how long it would take to
> rematerialize it if a subsequent request asks for it.
>
> In the simple case where a cached object is unique to a particular user,
> you're probably better off just storing it in the user's session. Such
> objects are visible both in servlets (session.getValue()) and JSP pages
> (<jsp:useBean> with scope="session"), and they go away automatically
> when the session times out or you invalidate it. Doing this is
> essentially using the servlet container's collection of active sessions
> as your cache.
>
> >
> > 3) How do you call a JSP from a controlling servlet and pass the
> > required bean references.
>
> First, you store the bean references in the appropriate scope. The
> example above showed how to store a bean with application scope -- for
> session scope it would look like this:
>
> MyObject mo = new MyObject(...);
> HttpSession session = request.getSession();
> session.putValue("mo", mo);
>
> and for request scope (in other words, you only need it for long enough
> to finish this request -- it does not need to be cached):
>
> MyObject mo = new MyObject(...);
> request.setAttribute("mo", mo);
>
> Second, once all your beans are stashed, you use a request dispatcher to
> forward control to the appropriate page:
>
> RequestDispatcher rd =
> getServletContext().getRequestDispatcher("/display.jsp");
> rd.forward(request, response);
> return;
>
> Note that in this scenario, it is the JSP page that creates the actual
> response, not your servlet. Therefore, you should not call
> response.getWriter() or response.getOutputStream() prior to doing this.
>
> >
> > 3) How do you force people to log to your application.
> >
>
> The technique that I have been using is to always use sessions, and
> detect a new session by the absence of a particular login bean in the
> session that is put there only by a successful login.
>
> To avoid problems of people bookmarking the middle of my application,
> each JSP page starts with something like this:
>
> <% if (session.getValue("loginBean") == null) { %>
> <jsp:forward page="/login.jsp" />
> <% } %>
>
> to forward to my username/password form. In the servlet that receives
> the username and password, I store an object under key "loginBean" in
> the user's session. This object goes away when the user logs out
> (because I call session.invalidate()) or when the session times out (at
> which time the server calls session.invalidate() for me).
>
> >
> > Do you guys know of some code samples that will make this architecture
> > easier to implement?
> >
>
> There is some basic code in the JSP Tutorial that is available at the
> JavaSoft web site, but it doesn't focus on this design model so it
> probably won't do you a lot of good.
>
>
> >
> > Andrzej Kobus
> >
>
> Craig McClanahan
>
> ==========================================================================
> =
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
