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
