You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dave Smith <sa...@home.com> on 2000/10/02 22:49:11 UTC
Re: More Tomcat problems.
More Tomcat problems.Panagiotis,
Are you using a try block around the code to catch SQLExceptions
in your development setup?
This is what is happening: you are throwing an exception without
a handler. The jvm just unwinds to the top and drops you out.
Try using something like this in the JSP:
<%@ page errorPage="error-page.jsp" %>
or else debug the connection code in an IDE first.
Regards,
Dave
----- Original Message -----
From: Panagiotis Konstantinidis
To: tomcat-user@jakarta.apache.org
Sent: Thursday, November 30, 2000 12:45 PM
Subject: More Tomcat problems.
Hello there again, this is the second message I am sending regarding problems with Tomcat. In my previous message Kief answered solved my question correctly, so I would really appreciate if he could answer again this one. It seems that I have exactly the same problem. I am running a JSP file (lets say myFile.jsp) that open a conenction with the database on the server. The code is like the following:
<% .....
String url = <the url string>;
String user = <the user string>;
String password = <the password string>;
Class.forName("org.gjt.mm.mysql.Driver");
Connection con = DriverManager.getConnection(url, user, password);
.....
%>
When the line Connection con = DriverManager.getConnection(url, user, password); is encountered then Tomcat just goes off (and I get the error message from Apache "Internal Server Error....."). Just like that, with no error messages or anything. This is really weird because I have downloaded and installed the latest versions of both Apache (v1.3.14) and Tomcat (v3.2) and I have included the JDBC driver .jar file in my classpath.
I have looked in the "tomcat.log" file and there are no error messages. I have looked in the "error.log" file in the Apache directory and I get the error message (for one more time): [Thu Nov 30 17:47:39 2000] [error] [client 192.168.0.25] Premature end of script headers: c:/work/tomcat/jakarta-tomcat-3.2-b7/webapps/panos/myFile.jsp. I cannot think of anything to do so if somebody knows more about that please help.
Thank you.
Panos
Re: request dispatch woes
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Alan Wright wrote:
> Hi
>
> I have an application working well under Tomcat 3.1 and am trying to get it
> to work under 3.2.
>
> I had a sort of MVC thing going with a main servlet handling all requests
> by handing off to specific controller servlets using
> requestDispatcher.Include(request, response) then returning to the user
> the results of a JSP using requestDispatcher.Forward(request, response).
>
> This approach worked just fine under 3.1 but fails under 3.2.
>
> The the first step is OK but when the application tries to Forward it fails
> with an error "Cannot forward as output stream or writer has already been
> obtained". If I comment out the requestDispatcher.Include statement the
> JSP page returns OK but obvoiusly without any of the required changes to
> the data having taken place.
>
> Should I be able to do a requestDispatcher.Include followed by a
> requestDispatcher.Forward?
>
> Is anyone knowledgable enough to suggest whether this might be a bug?
>
> If it is a bug how should I report it?
>
The basic restriction causing this message is that you cannot do a
RequestDispatcher.forward() call after the response has been committed -- in
other words, when one of the following things happens:
* You write more data than can fit in the buffer size for this response.
* You call response.flushBuffer().
Normally, you should be able to do an include before a forward (although the
included JSP page might itself cause the response to become committed, so this
is pretty risky). However, late in the development cycle of Tomcat 3.2 a
fundamental architectural problem was discovered that caused incorrect behavior
in a lot of "include" cases. The only feasible workaround was to insert a
response.flushBuffer() call before the include was actually processed -- which
will make your proposed approach fail with the error you are getting.
Workaround approaches to consider:
* Use a RequestDispatcher.include() rather than forward()
to invoke the view component at the end (since you are doing it last).
* Redesign so that the logic performed in your "controller"
function is regular Java code, rather than an "included" servlet
that has no visual result. What your design calls the "controller"
would be called an Action that contains business logic in the
Struts framework, for example <http://jakarta.apache.org/struts>.
* Try this with Tomcat 4.0.
Craig McClanahan
request dispatch woes
Posted by Alan Wright <At...@btinternet.com>.
Hi
I have an application working well under Tomcat 3.1 and am trying to get it
to work under 3.2.
I had a sort of MVC thing going with a main servlet handling all requests
by handing off to specific controller servlets using
requestDispatcher.Include(request, response) then returning to the user
the results of a JSP using requestDispatcher.Forward(request, response).
This approach worked just fine under 3.1 but fails under 3.2.
The the first step is OK but when the application tries to Forward it fails
with an error "Cannot forward as output stream or writer has already been
obtained". If I comment out the requestDispatcher.Include statement the
JSP page returns OK but obvoiusly without any of the required changes to
the data having taken place.
Should I be able to do a requestDispatcher.Include followed by a
requestDispatcher.Forward?
Is anyone knowledgable enough to suggest whether this might be a bug?
If it is a bug how should I report it?
The code below indicates what I am doing - I apologise if any Java experts
find it offensive!
Alan Wright
public void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
// N.B. Declare variables in procedure not as member variables of
class.
// This is to avoid thread issues in a multiuser environment (I hope!).
String controller = ""; // servlet used to process request
String viewName = ""; // presentation element for return to user
String errorViewName = "error.jsp"; // presentation element for return
to user on error
boolean authorisedMemberExpected = true; // can we reasonably expect
authenticated memberInfo object to exist?
RequestDispatcher rd; //used for include of servlet processing or
forward of request to presentation element
// Lets look at the request and set up environment prior to handling
String requestPath = request.getPathInfo();
System.out.println("in do get");
if (requestPath.endsWith("Logout")) {
controller = "/control/abernathy.Logout";
viewName = "/loggedout.jsp";
errorViewName = "/error.jsp";
authorisedMemberExpected = false;
}
else if (requestPath.endsWith("TryCookieLogin")) {
System.out.println("in TryCookieLogin");
controller = "/control/abernathy.TryCookieLogin";
viewName = "/memberinfo.jsp";
errorViewName = "/loginerror.jsp";
authorisedMemberExpected = false;
//clear up any old session which could arise with multi users on one
PC
HttpSession oldSession = request.getSession(false);
if (oldSession != null) oldSession.invalidate();
System.out.println("end TryCookieLogin");
}
else {
controller = "";
viewName = "/error.jsp";
errorViewName = "/error.jsp";
}
// Create session if it doesn't exist
HttpSession session = request.getSession();
// if user should be authenticated make sure they are...
if (authorisedMemberExpected) { //default is true except for login and
authentication
MemberBean memberInfo = (MemberBean)
session.getAttribute("memberInfo");
if ((memberInfo.equals(null)) || (!memberInfo.isAuthenticated())) {
controller = "";
viewName = "/authenticationrequired.jsp";
errorViewName = "/error.jsp";
}
}
// pass request to appropriate servlet for processing
// then forward request to presentation element...
try {
// first we invoke the controller to perform any required
processing...
if (!controller.equals("")) {
rd = getServletContext().getRequestDispatcher(controller);
if (rd == null) {
getServletContext().log("No controller named " + controller);
response.sendError(response.SC_NO_CONTENT);
}
else {
System.out.println("in controller no rd");
rd.include(request, response);
}
}
// Before forwarding to the view we check to see if the servlet has
set
// the request attribute for viewName in a catch statement. If this
is the
// case we want to override the default viewName for the URL...
String viewNameOverride = (String)
request.getAttribute("errorViewName");
if (viewNameOverride != null) {
viewName = viewNameOverride;
}
// next we forward responsability for generating response to the
client...
rd = getServletContext().getRequestDispatcher(viewName);
if (rd == null) {
getServletContext().log("No view named " + viewName);
response.sendError(response.SC_NO_CONTENT);
}
else {
System.out.println("in view");
System.out.println(request.getContextPath());
System.out.println(request.getPathInfo());
System.out.println(request.getPathTranslated());
System.out.println(request.getRequestURI());
System.out.println(request.getServerName());
System.out.println(request.getServletPath());
System.out.println(rd.toString());
rd.forward(request, response);
}
}
// if there is an error we forward to the named error view
catch (Exception e) {
request.setAttribute("exception", e.toString());
rd = getServletContext().getRequestDispatcher(errorViewName);
if (rd == null) {
getServletContext().log("No error view named " + errorViewName);
response.sendError(response.SC_NO_CONTENT);
}
else {
System.out.println("in error");
System.out.println(e.getMessage());
//e.printStackTrace();
getServletContext().log("Error response via" + errorViewName);
//rd.forward(request, response);
}
}
}
Re: More Tomcat problems.
Posted by Dave Smith <sa...@home.com>.
Endre,
Tomcat isn't "crashing", it's doing what it is supposed to,
namely passing an exception on up the handler chain.
Other servlets and JSP continue to operate normally.
This is the opposite of "crashing." Scalability depends
on reliable exception handling.
The point of my post was to suggest Panagiotis try
debugging his base code before putting it into the servlet
runner, then blaiming tomcat/apache for "not reporting
the error" when his code fails. The servlet runner itself
is actually pretty stable, not to talk about apache, which
is rock solid.
Regards,
Dave
----- Original Message -----
From: "Endre Stølsvik" <En...@Stolsvik.com>
To: <to...@jakarta.apache.org>
Sent: Sunday, December 03, 2000 1:02 PM
Subject: Re: More Tomcat problems.
> On Mon, 2 Oct 2000, Dave Smith wrote:
>
> | More Tomcat problems.Panagiotis,
> |
> | Are you using a try block around the code to catch SQLExceptions
> | in your development setup?
> |
> | This is what is happening: you are throwing an exception without
> | a handler. The jvm just unwinds to the top and drops you out.
>
> I'm just curious; isn't this strange behaviour? Could a "bad" servlet
> crash Tomcat totally, then? I'm thinking of virtual servers, several
> domains sharing a Tomcat.
>
>
> --
> Mvh,
> Endre
>
Re: More Tomcat problems.
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Mon, 2 Oct 2000, Dave Smith wrote:
| More Tomcat problems.Panagiotis,
|
| Are you using a try block around the code to catch SQLExceptions
| in your development setup?
|
| This is what is happening: you are throwing an exception without
| a handler. The jvm just unwinds to the top and drops you out.
I'm just curious; isn't this strange behaviour? Could a "bad" servlet
crash Tomcat totally, then? I'm thinking of virtual servers, several
domains sharing a Tomcat.
--
Mvh,
Endre