RE: Servlet regains control after execution of .Forward()
Title: Servlet regains control after execution of .Forward()
Just
put a return after the call to forward.
The
forward call is not magical. It's just a method call and when the method
completes, the thread continues to System.out.println("BUGGER ME! I
AM HERE AFTER ALL"); The only thing the spec calls for is that the
response be committed and closed by the container before the forward method
returns. The only way (from an interface perspective) to skip that last
System.out call without is to throw an exception in the forward call that's
declared in the throws clause of the service method. The container could
then interpret interpret the is exception as the result of a successful forward
and basically ignore it but the spec does not call for this and to my knowledge,
no server that I does this... they'd have to use the IOException or
ServletException in an unorthodox way to accomplish this... In any case,
just put a return after the forward.
The
following is an excerpt from Servlet2_2-spec.pdf
8.4 Forward
The forward method of the RequestDispatcher interface
may only be called by the calling
servlet if no output has been committed to the client. If output exists in
the response buffer that has
not been committed, it must be reset (clearing the buffer) before the target
servlets service
method is called. If the response has been committed, an IllegalStateException must be
thrown.
The path elements of the request object exposed to the target servlet must
reflect the path used to
obtain the RequestDispatcher. The only exception to this is if the
RequestDispatcher
was obtained via the getNamedDispatcher
method. In this case, the path
elements of the
request object reflect those of the original request.
Before the forward method of the RequestDispatcher interface
returns, the response must
be committed and closed by the servlet container. -Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Grant
DoranSent: Thursday, November 09, 2000 6:52 PMTo:
Orion-InterestSubject: Servlet regains control after execution of
.Forward()
Hi,
(Orion 1.3.8, Windows NT 4, JDK1.3) This should not be possible, but it is happening. After executing the
forward() method, control IS returning to the forwarding servlet. I have
checked the archives and found that this has been an issue in previous
versions of orion.
Here is the offending fragment: --- if (condition XXX) { request.getSession().setAttribute("username",username);
request.getSession().setAttribute("password",password); System.out.println("[GATEWAYSERVLET]User has now logged in and
is being redirected to reception");
request.getSession().setAttribute("LoginFailure","false");
getServletContext().getRequestDispatcher("/index.jsp").forward(request,
response); } else
{
System.out.println("[GATEWAYSERVLET]Authentication failure. Username:[" +
username + "] Password:[" + password + "]");
request.getSession().setAttribute("LoginFailure","true");
getServletContext().getRequestDispatcher("/login.jsp").forward(request,
response); } System.out.println("BUGGER ME! I AM HERE AFTER ALL");
Here is the output
[GATEWAYSERVLET]User has now logged in and is being
redirected to reception [INDEX.JSP]Session is
established. UserId = gdoran. Printing frames with menus etc. BUGGER ME! I AM HERE AFTER ALL
How can this be? Execution of the servlet(thread) is supposed
to cease immediately and control handed to the target.
Am I missing something?
While I'm at it, does anyone know where I can obtain a good
pattern example of JSP/Servlet based authentication, with a login page for any
unauthenticated requests. I am pushing all requests through a single
controller servlet and checking their session object for the required
attributes, but I seem to be having problems with retrieving the session.
Sometimes the attributes are there, sometimes they aren't.
Any guidance would be greatly appreciated.
Grant Doran Principle Architect
iLaunch inc. (02)
89257055 [EMAIL PROTECTED]
RE: 1.2.9 bug: InputStream from request throwing an exception
Sorry, I didn't see the Bugzilla link on the web site. I knew there was a better place for this but I couldn't find it. I see it now. The InputStream is to spec just as Magnus has said. The funny thing is that my code actually works in Tomcat and some other servers. I suppose I'll report the bug to the jakarta project. Thanks for the added info in the message of the exception. That should help other poor souls in identifying the problem.
1.2.9 bug: InputStream from request throwing an exception
Orion 1.2.9
Windows 2000
J2SE 1.3.0
Bug: Underlying InputStream from request.getInputStream() throws an
exception when the input stream should return more than 2048 bytes.
Example: The following error occurs when running the JSP and servlet below.
The underlying input stream seems to throw and exception during in.read(...)
when trying to upload a file that's greater than 2048 (actually when the
file + the extra multi encoding > 2048). I've tried this on Tomcat 3.2b
and it works fine. I've used similar code on older servers (not orion) and
didn't have this problem. I'm writing this to the users group as well in
case others are having problems with this. If you work with file uploading
through forms, this will certainly hamper your progress.
500 Internal Server Error
java.lang.IndexOutOfBoundsException
at com.evermind.server.http.ep.read(JAX)
at InputStreamBug.doPost(InputStreamBug.java:21)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at com.evermind.server.http.du.rr(JAX)
at com.evermind.server.http.du.forward(JAX)
at com.evermind.server.http.d5.rx(JAX)
at com.evermind.server.http.d5.rw(JAX)
at com.evermind.util.f.run(JAX)
InputStreamBug.jsp
<%@page contentType="text/html"%>
InputStreamBug
InputStreamBug.java---
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;
public class InputStreamBug extends HttpServlet {
/**
* Reads the input stream and outputs the results to the output stream.
*/
public void doPost(HttpServletRequest request, HttpServletResponse
response)
throws IOException{
response.setContentType("text/html");
InputStream in = request.getInputStream();
OutputStream out = response.getOutputStream();
int contentLength = request.getContentLength();
byte[] bytes = new byte[contentLength];
int actualRead = 0;
int bytesRead = 0;
while (bytesRead < contentLength) {
actualRead = in.read(bytes, bytesRead, contentLength);
bytesRead += actualRead;
}
out.write(bytes);
}
}
RE: ServletSession's and Servlet Reloading
Title: RE: ServletSession's and Servlet Reloading Also, I want to emphasize that the solution mentioned is not desirable. Maintaining session information even after reloads promotes rapid development. It allows one to build up a session and then work on a single servlet, compiling again and again, without rebuilding the session or using a 'shortcut' servlet to build the session after every reload. Several weeks ago, someone on this list raised the same issue and they resorted to using their own session implementation. I think this is largely unecessary since the Serlvet Container is capable of dealing with this using the standard spec. In any case, how do others deal with this situation? I have been rebuilding the session using a separate servlet after each recompile of the servlet being tested. It's tedious and prone to human error and often makes me wish that I had purchased VAJ and Websphere as twisted as that may sound. [Scott Lawrence] -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hani SuleimanSent: Tuesday, August 08, 2000 10:03 AMTo: Orion-InterestSubject: RE: ServletSession's and Servlet Reloading This behaviour actually makes a lot of sense when you consider how classloaders work in java. It is impossible to throw away any given class, in order to do ANY reloading of anything at all, you need to throw away the classloader, and make a new one and load classes through it. Now, another factor to throw into the mix is that in order for two classes to be equal, they must have the same class, AND be loaded through the same classloader. Hence, when you've reloaded classes, all classes in your session are now invalid. There is no way around this, I'm afraid! The solution is to ensure that things are initialised properly in your servlet startup code. Eg, where you first create the session, make sure you invalidate the existing one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott Lawrence Sent: Monday, August 07, 2000 11:12 PM To: Orion-Interest Subject: ServletSession's and Servlet Reloading Orion 1.1.37 (as well as all other versions as far as I remember) lose the Servlet Session whenever a servlet is reloaded. Why is this? Is this an issue with how classloaders are used? This makes working with complex sessions very difficult to test and debug since each time I recompile a servlet, I'll lose the session when that servlet is reloaded. Other servers do not destroy the session (Websphere for instance) when reloading servlets. Have I missed something or is there a setting that prevents this from happening?
RE: ServletSession's and Servlet Reloading
Title: RE: ServletSession's and Servlet Reloading Actually, it is possible. Session's are not lost in Websphere when you recompile any of the classes... servlet or otherwise. I'm not reloading the session, just a single servlet (which of course can access the session). No, something else is going on here. Either classloaders aren't arranged properly in a chain or the reload process is mistakenly causing all sessions to be invalidated. [Scott Lawrence] -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hani SuleimanSent: Tuesday, August 08, 2000 10:03 AMTo: Orion-InterestSubject: RE: ServletSession's and Servlet Reloading This behaviour actually makes a lot of sense when you consider how classloaders work in java. It is impossible to throw away any given class, in order to do ANY reloading of anything at all, you need to throw away the classloader, and make a new one and load classes through it. Now, another factor to throw into the mix is that in order for two classes to be equal, they must have the same class, AND be loaded through the same classloader. Hence, when you've reloaded classes, all classes in your session are now invalid. There is no way around this, I'm afraid! The solution is to ensure that things are initialised properly in your servlet startup code. Eg, where you first create the session, make sure you invalidate the existing one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott Lawrence Sent: Monday, August 07, 2000 11:12 PM To: Orion-Interest Subject: ServletSession's and Servlet Reloading Orion 1.1.37 (as well as all other versions as far as I remember) lose the Servlet Session whenever a servlet is reloaded. Why is this? Is this an issue with how classloaders are used? This makes working with complex sessions very difficult to test and debug since each time I recompile a servlet, I'll lose the session when that servlet is reloaded. Other servers do not destroy the session (Websphere for instance) when reloading servlets. Have I missed something or is there a setting that prevents this from happening?
RE: ServletSession's and Servlet Reloading
I do have development=true but that's only so that orion generates the
source for the jsps as far as I know.
I ran a few tests to see what was happening and I got mixed results. The
most disturbing was the code below. It simply keeps track of an attribute
in the session and how many times it exists vs. doesn't exist in the
session. I sat with Netscape reloading the url for the servlet over and
over and occassionally, every 19th request would fail to use the same
session and a new one would be created.
Also, I played around with HttpSessionBindingListener and simply kept track
of when an object was removed from a session to verify that the
session-timeout setting in my web.xml was working properly. Well, sometimes
I would get 2 events instead of one when the object was removed from the
session. It's as if the objects in the session that implemented
HttpSessionBinding Listener would be registered twice after the bind
occurred. I couldn't nail down the exact scenario in which two
HttpSessionBindingEvents occurred on unbind.
I wish a document existed that explained how sessions and reloading is
taking place. Without this sort of explanation, I'm finding that I have to
do a lot of trial and error for developing. I'm spending way too much time
on the app server vs. my code... well less than if I were using Weblogic or
other app server since orion starts so quickly ;-)... but still, it's making
debugging next to impossible. I hope that sessions can be made accessible
through the parent classloader of the servlet classloader so that the
session is not lost from reload to reload. Alas, all indications are that
this is not the case...
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.IOException;
import java.io.PrintWriter;
public class Test extends HttpServlet {
static int notExistsCounter = 0;
static int existsCounter= 0;
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
HttpSession session = req.getSession(true);
Object attribute = session.getAttribute("attribute");
PrintWriter out = res.getWriter();
if (attribute == null) {
notExistsCounter++;
out.println("attribute did not exist in session");
out.println("binding attribute to session...");
session.setAttribute("attribute", "this is a test");
out.println("bound attribute to session");
} else {
existsCounter++;
out.println("attribute exists in session");
out.println("attribute: " + attribute);
}
out.println("exists count:" + existsCounter);
out.println("doesn't exist count: " + notExistsCounter);
}
}
ServletSession's and Servlet Reloading
Orion 1.1.37 (as well as all other versions as far as I remember) lose the Servlet Session whenever a servlet is reloaded. Why is this? Is this an issue with how classloaders are used? This makes working with complex sessions very difficult to test and debug since each time I recompile a servlet, I'll lose the session when that servlet is reloaded. Other servers do not destroy the session (Websphere for instance) when reloading servlets. Have I missed something or is there a setting that prevents this from happening?
Re: Clustering
I asked this once before but here it goes again: > I know that there is a cluster id setting in server.xml but how do we > actually use clustering? Also, what is Orion's definition of clustering > in terms of JSP's and Servlets? I know that EJB clustering isn't > available yet (in the FAQ).
Clustering
I know that there is a cluster id setting in server.xml but how do we actually use clustering? Also, what is Orion's definition of clustering in terms of JSP's and Servlets? I know that EJB clustering isn't available yet (in the FAQ).
0.9.1 Compiled JSP... where is it?
I have set development="true" in global-web-application.xml I can't find the location of compiled jsps. Anyone?
user-web-apps... do they work?
Does this work in the Web-Site XML file (see the excerpt from the docs below)? I tried it but I couldn't get a simple index file to load using http://ip:port/~user/ or http://ip:port/~user/index.html. I put the web-app xml file for the user in the user's home directory. Is that where it's supposed to go? On a related note, i'm confused by the relationship between the 'global' site and additional sites. Orion has the ability to run two sites on separate ports under one jvm? What happens if they are set to the same port? Who's html directory or servlet directory is used (assuming they have the same virtual paths)? I'm impressed by the features of Orionserver and the fact that 2 people have coded it but without the documentation, I can't really get it working properly. When enabled user dirs/apps will be supported. Each user has his own private web-application (and connected web-application.xml file). The user apps are reached at /~username/ from the server root. max-inactivity-time - Optional attribute specifying number of minutes of inactivity before a loaded user-web-app can be shut down, if not specified no shutdown will occur. path - A path, including a wildcard to specify the local directory of each user application. The default UNIX mask for instance would be "/home/*". The * is replaced with the username when searching for the apps.
