Reputation: 11
I am developing an app in Tomcat 7 on windows with Oracle 11g (thin driver) and Java 6. I am working on a page that lets users validate SQL statements that are stored in an Oracle database. My plan is to use the EXPLAIN PLAN FOR feature in Oracle to do this.
I have a JSP that executes the SQL statements in a try-catch-finally block that looks like this:
String error = "";
try {
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
DataSource ds = (DataSource)envCtx.lookup("jdbc/myDatabase");
con = ds.getConnection();
st = con.prepareStatement(sql);
st.execute();
} catch(SQLException e) {
error = "SQL error: " + e.getMessage();
} finally {
if(rs != null) rs.close();
if(st != null) st.close();
if(con != null) con.close();
}
// respond with error....
When a known valid SQL statement is passed, the JSP responds accordingly. However, when an error is introduced to the SQL statement ("SELECT fubar FROM mytable"), the SQLException is not caught by the JSP and the st.execute() statement does not return, like it's stuck in a loop.
The Tomcat log shows the SQL error. I have tried using different settings in the logging.properties file, and I have also tried using Log4J. I have also tried the the same code in Tomcat 6, and I have tried moving the code in the JSP to a DAO bean. None of this helps.
It sure appears to be the Tomcat logger that is swallowing the SQLExceptions, how can I change this behavior? I recently upgraded to Tomcat 7 from Tomcat 5, I don't recall this being a problem before, but I can't find anything on the internet about this. Anybody have any ideas?
Upvotes: 1
Views: 888
Reputation: 1109142
Tomcat cannot change the response to show the error page in its full glory, because the response is already been committed to the client. The response is already been committed because you're using JSP (which is solely intented to present the results) instead of a normal Java class (like a servlet) to do the pre/post processing job.
Whenver the JSP sends a certain amount of template data (HTML and so on) to the response, it get committed and this is a point of no return. The client has already received the first part of the response. If after that point an exception occurs, then the server simply can't take that part back. The exception will be logged, but the response stucks there. All the client got is a halfbaked response.
Solving this problem is fairly simple: just do not write anything to the response before the business job is finished. There are basically 2 ways to achieve this:
Put all that Java code in one large <% %>
in top of the JSP file. The JSP should not send any character to the response before all that business job is finished.
Get rid of all that Java code in the JSP and move it into a servlet class. Therein you have all the freedom to write Java code the normal way and handle exceptions and control the response.
Needless to say that the second way is preferable in MVC opinion.
Upvotes: 1