You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Alex Chaffee <gu...@edamame.stinky.com> on 2000/07/06 18:58:03 UTC
Re: Bugs/patches - need help
On Thu, Jul 06, 2000 at 02:51:44PM -0700, Costin Manolache wrote:
> - log() fails in jsp
Done
> - few stack traces should be removed
Which ones?
- Alex
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Bugs/patches - need help
Posted by Costin Manolache <co...@eng.sun.com>.
Alex Chaffee wrote:
> > > OK, I'm going through and wiping out all stack traces. I don't know
> > > how long it will take; I doubt it will be done for 3.2 beta 1. I've
> >
> > I think the problem is a bit more complex.
> Right, I agree completely. I didn't really mean "wipe out" -- I meant
> "convert literal t.printStackTrace() to loghelper.log("reason", t)"
> where loghelper prints the exception to a log (or to System.err if the
> log is unavailable), and also prints the root cause (which
> printStackTrace does not). Also, I'm adding in a few.
:-)
> Shall I show you the changes I've made, so you can confirm they're OK
> before I check them in?
No, just check in.
I think the rules are:
- anything can go into main branch, if someone doesn't like it and -1 it - we
roll back the change ( or convince the -1 to become -0 )
- for a release branch, the volunteered release manager decides what goes in
and what doesn't. For most simple bugs or non-dangerous changes ( like that -
I think ) we can probably commit ( and rollback if Sam have any doubt about
the change )
> > The main problem is with exceptions that are frequent and we know
> > what is wrong - BrokenPipe for example. The difficulty consist in
> > filtering BrokenPipe, but to display all other IOExceptions.
> > What we do now is to check for "Broken Pipe" in the message -but that
> > doesn't work in foreign langauges.
> > Right now I don't know any solution for that...
>
> I agree; this is something I keep hoping will be fixed in the next
> version of Java (more, better-defined IO/net sub-exceptions) but never
> seems to happen.
Yes, but we still don't have a solution...
Costin
Re: Bugs/patches - need help
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
> > OK, I'm going through and wiping out all stack traces. I don't know
> > how long it will take; I doubt it will be done for 3.2 beta 1. I've
>
> I think the problem is a bit more complex.
>
> First, we need to have the stack traces in all places where something
> shouldn't happen. A good way to find the extra ones is to run watchdog
> and verify that no stack trace is printed.
> We should add more stack traces and messages for abnormal situations,
> it is very important to have this.
Right, I agree completely. I didn't really mean "wipe out" -- I meant
"convert literal t.printStackTrace() to loghelper.log("reason", t)"
where loghelper prints the exception to a log (or to System.err if the
log is unavailable), and also prints the root cause (which
printStackTrace does not). Also, I'm adding in a few.
Shall I show you the changes I've made, so you can confirm they're OK
before I check them in?
> The main problem is with exceptions that are frequent and we know
> what is wrong - BrokenPipe for example. The difficulty consist in
> filtering BrokenPipe, but to display all other IOExceptions.
> What we do now is to check for "Broken Pipe" in the message -but that
> doesn't work in foreign langauges.
> Right now I don't know any solution for that...
I agree; this is something I keep hoping will be fixed in the next
version of Java (more, better-defined IO/net sub-exceptions) but never
seems to happen.
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Bugs/patches - need help
Posted by Costin Manolache <co...@eng.sun.com>.
> > It seems in some cases we still get ConnectionReset or
> > BrokenPipe exception.
> >
> > I have no idea how this can be filtered without removing all
> > IOExceptions, but at least in some clear cases we should do it.
> >
> > In EmbededTomcat ( or Tomcat with SSL enabled in server.xml )
> > we show traces when .keystore is missing or broken. A cleaner message
> > will help. ( I started fixing that )
> >
> > Also, we need to make sure all debugging is disabled and no
> > println or log sneaks in for the release.
> >
>
> OK, I'm going through and wiping out all stack traces. I don't know
> how long it will take; I doubt it will be done for 3.2 beta 1. I've
I think the problem is a bit more complex.
First, we need to have the stack traces in all places where something
shouldn't happen. A good way to find the extra ones is to run watchdog
and verify that no stack trace is printed.
We should add more stack traces and messages for abnormal situations,
it is very important to have this.
The main problem is with exceptions that are frequent and we know
what is wrong - BrokenPipe for example. The difficulty consist in
filtering BrokenPipe, but to display all other IOExceptions.
What we do now is to check for "Broken Pipe" in the message -but that
doesn't work in foreign langauges.
Right now I don't know any solution for that...
> Sam - is the plan to use the same branch (tomcat_32) all the way up to
> the 3.2 release, or will you make a new branch for each 3.2 beta
> release?
I guess the new branch for 3.2 beta will be out of tomcat_32 branch, isn't
it ?
BTW, is it the -j option for synchronizing 2 branches ?
Costin
Re: Bugs/patches - need help
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
On Thu, Jul 06, 2000 at 05:25:36PM -0700, Costin Manolache wrote:
> >
> > > - few stack traces should be removed
> >
> > Which ones?
>
> It seems in some cases we still get ConnectionReset or
> BrokenPipe exception.
>
> I have no idea how this can be filtered without removing all
> IOExceptions, but at least in some clear cases we should do it.
>
> In EmbededTomcat ( or Tomcat with SSL enabled in server.xml )
> we show traces when .keystore is missing or broken. A cleaner message
> will help. ( I started fixing that )
>
> Also, we need to make sure all debugging is disabled and no
> println or log sneaks in for the release.
>
OK, I'm going through and wiping out all stack traces. I don't know
how long it will take; I doubt it will be done for 3.2 beta 1. I've
also tidied up LogHelper in a way that will hopefully make it easier
to eventually attach separate Loggers to individual Contexts (afaik,
that doesn't work yet).
Sam - is the plan to use the same branch (tomcat_32) all the way up to
the 3.2 release, or will you make a new branch for each 3.2 beta
release?
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Stack Traces in standalone classes
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
>
> A "non-Tomcat context" in which logging already causes grief is Catalina.
> It does not utilize Tomcat's org.apache.tomcat.logging package itself
> (based on philosophical reasons -- there will be people who want all
> events from all components related to things like a particular virtual
> host or a particular application logged to the same place), and has to go
> to some pretty incredible pains to make a Tomcat-compatible logger
> available for Jasper.
>
That's a great idea. It should (should!) be possible to make a
logging facility that works for (a) Tomcat, (b) Catalina, (c)
standalone classes, that satisfies the following:
- simple API, so programmers have no excuse for not using it
- predictable and consistent behavior
- prints to a log file, or to System.err (degrades gracefully)
- can defer to a superior (the point you made above)
- can specify verbosity level
- expands nested exceptions
- "debug" messages don't take up any CPU if debugging is turned off
The solution I've been slowly incorporating into the Tomcat tree has
most of the above; I'd love to discuss what would need to be done to
make it acceptable to Catalina. Basically, you instantiate a helper
class that does all the work for you. This would be a "mixin" in C++
but with Java there's a little extra typing, e.g.:
class Foo {
Logger.Helper loghelper = new Logger.Helper("tc_log", "Foo");
...
loghelper.log("Something happened");
...
loghelper.log("Starting something", Logger.DEBUG);
...
catch (IOException e) {
loghelper.log("While doing something", e);
}
The "degrades gracefully" aspect should (!) make it acceptable to
include in classes like XmlMapper.
I'm psyched that a common log API is in JSR
(http://java.sun.com/aboutJava/communityprocess/jsr/jsr_047_log.html )
-- but until that materializes, we can probably make a usable system
ourselves.
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Stack Traces in standalone classes
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Alex Chaffee wrote:
> I've been going through and converting various printStackTrace() calls
> and System.out.println()s to use loghelper.log("reason", exception).
> This is safe even if there are no loggers yet, since if it can't find
> a good logger, it prints to System.err. It also uses
> Logger.throwableToString, which is smart obout printing nested
> exceptions (ServletException and TomcatException -- hmm, it occurs to
> me that it should be smart about JDBCException too.)
>
> Certain classes feel like they want to be independent of all
> references to other Tomcat packages/classes. Some even say so in the
> documentation. To wit:
>
> XmlMapper
> SSLSocketFactory
> AdaptiveClassLoader
>
> and probably a few others.
>
> Any strong feelings about using/not using the above logging technique
> in these classes? I feel it's probably OK, since it's "just" Logger,
> and it's a known behavior that degrades gracefully in a non-Tomcat
> context.
>
A "non-Tomcat context" in which logging already causes grief is Catalina.
It does not utilize Tomcat's org.apache.tomcat.logging package itself
(based on philosophical reasons -- there will be people who want all
events from all components related to things like a particular virtual
host or a particular application logged to the same place), and has to go
to some pretty incredible pains to make a Tomcat-compatible logger
available for Jasper.
I would personally prefer that Tomcat 3.x logger dependencies *not* be
introduced into the classes you have listed above.
>
> - Alex
>
Craig McClanahan
Re: Stack Traces in standalone classes
Posted by Costin Manolache <co...@eng.sun.com>.
Alex Chaffee wrote:
> I've been going through and converting various printStackTrace() calls
> and System.out.println()s to use loghelper.log("reason", exception).
> This is safe even if there are no loggers yet, since if it can't find
> a good logger, it prints to System.err. It also uses
> Logger.throwableToString, which is smart obout printing nested
> exceptions (ServletException and TomcatException -- hmm, it occurs to
> me that it should be smart about JDBCException too.)
>
> Certain classes feel like they want to be independent of all
> references to other Tomcat packages/classes. Some even say so in the
> documentation. To wit:
>
> XmlMapper
> SSLSocketFactory
> AdaptiveClassLoader
>
> and probably a few others.
>
> Any strong feelings about using/not using the above logging technique
> in these classes? I feel it's probably OK, since it's "just" Logger,
> and it's a known behavior that degrades gracefully in a non-Tomcat
> context.
I'm -0 ( i.e. I wouldn't complain if you add dependencies to Logger,
since the logger is a standalone component too and can be included
easily ).
I would feel more comfortable for a next release, and after a round
of "evolution" for Logger. I think you made huge improvements to
it, and we are very close to something really good :-)
Costin
Stack Traces in standalone classes
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
I've been going through and converting various printStackTrace() calls
and System.out.println()s to use loghelper.log("reason", exception).
This is safe even if there are no loggers yet, since if it can't find
a good logger, it prints to System.err. It also uses
Logger.throwableToString, which is smart obout printing nested
exceptions (ServletException and TomcatException -- hmm, it occurs to
me that it should be smart about JDBCException too.)
Certain classes feel like they want to be independent of all
references to other Tomcat packages/classes. Some even say so in the
documentation. To wit:
XmlMapper
SSLSocketFactory
AdaptiveClassLoader
and probably a few others.
Any strong feelings about using/not using the above logging technique
in these classes? I feel it's probably OK, since it's "just" Logger,
and it's a known behavior that degrades gracefully in a non-Tomcat
context.
- Alex
P.S. By the way, the point here is to make sure no exceptions are
silently swallowed -- that they all show up in a log file. A big push
towards removing/streamlining log/debug messages to increase
performance will have to take place at a later date.
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Bugs/patches - need help
Posted by Costin Manolache <co...@eng.sun.com>.
>
> > - few stack traces should be removed
>
> Which ones?
It seems in some cases we still get ConnectionReset or
BrokenPipe exception.
I have no idea how this can be filtered without removing all
IOExceptions, but at least in some clear cases we should do it.
In EmbededTomcat ( or Tomcat with SSL enabled in server.xml )
we show traces when .keystore is missing or broken. A cleaner message
will help. ( I started fixing that )
Also, we need to make sure all debugging is disabled and no
println or log sneaks in for the release.
Costin