on the side effects of the original flushBuffer() (e.g. that
exceptions are raised when calling methods like sendRedirect() afterwards).
Although this is highly unlikely, you have to "simulate" these effects in
your wrapper if you want to be _absolutely_ sure your application runs in
ever
---------
Dipl.-Inform.(FH) Andreas Junghans
Steinbeis-Transferzentrum Industrielle Datenverarbeitung und Automation
Moltkestrasse 30 - 76133 Karlsruhe
Fon.: +49-721-925-1485 --- Fax: +49-721-925-1488
email: [EMA
o that, it's too work for what you get at the end. BTW, I
don't think you can sell (or other html tags) to Jasper as custom
tags without a namespace prefix: . And this looks _really_
ugly!
Best regards
Andreas Junghans
PS Sorry for being so lengthy, it's a bad habit of mine .
Hi Bojan,
you can use JavaMail for that. Below is a code snippet that extracts all the
parts of the form data (probably could need some cleanup though). I don't
know if this solution works under all circumstances, but we're using it
regularly with no problems so far.
Best regards
it's not there, it should be added. Of
course, a clean solution that only affects individual webapps would be
better. Does it help using PureTLS?
Best regards
Andreas Junghans
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
t path should be introduced. The best
solution would be if the spec mandated such attributes, e.g.
"javax.servlet.actual_path.servlet_path" etc. Should I write to
[EMAIL PROTECTED] about it or is there a better place? Or
maybe I'm missing something and the issue can be solved more eleg
d first like some opinions. Could the 4.x guys
please look at it? I know it's a lot to read, but the problem and proposed
fix are too complex to explain in just a few lines.
Best regards
Andreas Junghans
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Hi Remy,
> As I stated in the comments of the bug, I don't agree with your
> interpretation about the JSP displaying "code".
Sorry again for not making myself clear. To put it exact (I hope ...):
There are cases in complex include/forward scenarios where Tomcat serves
JSPs as static resources.
Hi Remy,
> I actually tried the test case (I guess I should have tried it before
...),
> and it didn't do what I thought it would do. This does not qualify as a
> security issue by my book, though (it is recommended to test your
> application before putting it in production).
Now I have a simple
Hi Bill,
> billbarker02/04/16 22:49:59
>
> Modified:catalina/src/share/org/apache/catalina/core
> ApplicationHttpRequest.java
>catalina/src/share/org/apache/catalina/servlets
> DefaultServlet.java
> Log:
> Attempt to po
r things like this, I usually use a
session attribute that implements HttpSessionBindingListener. In its
valueUnbound() method, you can perform cleanup actions for the session.
Regards
Andreas Junghans
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
11 matches
Mail list logo