Hi All,
We are having an issue with the latest version of Tomcat and how the Content
Type header is being set by it now - in particular with PDFs generated by
our application. The following is taken straight from the
RequestDumperValve:
OLD (Tomcat 4.1.24)
2003-11-11 16:11:19 RequestDumperValve[
Just an FYI.
I appear to have solved this problem - a variable was 'magically' nulling
itself when I did NOT null it at random intervals (I am suspicious of our
Garbage Collection settings right now but we shall see...)
Still doesnt explain why there was no stacktrace attached with the
printStack
No - its a printStackTrace() that is being used - we dont use getMessage()
at that point at all - if we had it would be in the stdout log though - we
only use System.out for debugging messages.
-Original Message-
From: Tim Funk [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2003 2:
Yoav,
If that were the case the report should bomb out every time it was ran on
the same set of data - which its not :(
There is a catch in the base servlet that should throw a stack trace for ANY
error.
After some more debugging, the exception is being caught by this base
Exception catch (identi
Hi there,
I have spent a bit of time trying to figure out why this problem is
happening with no luck - so I decided to email the mailing list.
The issue is this:
We have a PDF reporting engine running from Tomcat 4.1.24 - in a Production
environment.
I have a particular report that is erroring o
Elizabeth,
Tomcat does support this if I understand you correctly.
The following should hopefully achieve this for you (Put these into a JSP):
ByteArrayOutputStream ba = new ByteArrayOutputStream();
Read your PDF into ba ...
response.setContentType("application/pdf");
response.setContentLe
Shawn,
It shouldnt be DBCP that would cause getGeneratedKeys() to not work - its
the JDBC Driver that doesnt support it - my (limited) knowledge of the
various different databases is that very few support the JDBC 3.0
specification yet so you might have to do a work-around.
Its worth checking the
Lior,
One easy way to do this is to store something in the session when you log
the user on (a user name or some unique piece of information) - you probably
already do this - and when you do any jsps or servlets, try doing
session.getAttribute on that item - if its null - the session is timed out.
Andy,
There are two builds of 4.1.10 as far as I recall - one that is built with
JDK 1.4, and one that is not. The one that is built with 1.4 is a
'lightweight' install that doesnt include various APIs that come with
1.4.
You can find both on the jakarta downloads
Steve
-Original M
You'll want to do if( !(paramPassword.equalsIgnoreCase(secretCode))) { }
else { }
You cant use logical operators on Strings for what you're trying to do!
Look up the java.lang.String javadocs for more information on the equals and
equalsIgnoreCase methods.
Steve
-Original Message-
From
Hit Send too early!
To continue:
Otherwise you could just have your manager app in another browser window and
hit reload in the webapp in question - this will re-load the webapp and any
classes associated with it.
Hope this helps - been a while since I played with this so I HOPE this
Hi Nate,
I believe if you add an explicit Context entry to your server.xml with the
reloadable=true attribute, this should force Tomcat to detect when classes
have been recompiled, and it restarts your webapp. E.g. :
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
12 matches
Mail list logo
