By the way, Log4J supports this as a default.

logger.debug(String message, Throwable e) to print out the stack trace.

And finally Java5 seems to support package level logging (as always,
log4j has supported this too) so that we can specify something like:

org.hackystat.kernel.level=INFO
org.hackystat.app.review.level=FINER

Philip, this would be good feature for our development since we
basically don't care for the module such as the kernel that includes the
SensorDataEntry.getEntry log with fine level to print out a bunch of
entries in kernel.

Cheers,

Takuya

On Wed, 11 May 2005 06:10:41 -1000
Philip Johnson <[EMAIL PROTECTED]> wrote:

> I just did a little googling, and the references I saw all iterated through
> the stack trace records similarly to Aaron's solution. So, it looks like
> his way is the best available for generating the trace.
>
> Good job, Aaron, and thanks to Hongbing and Cedric for coming up with some
> other ideas!
>
> Cheers,
> Philip
>
> p.s. It seems ridiculous that there isn't a built-in method for this,
> however.  Maybe in Java 5?
>
> --On Tuesday, May 10, 2005 8:25 PM -1000 Aaron Kagawa <[EMAIL PROTECTED]>
> wrote:
>
> > Thanks for the suggestions:
> >
> > Here is the output from using my method:
> >
> >     try {
> >       nullString.toLowerCase();
> >     }
> >     catch (Exception e) {
> >       String stackTrace = serverProperties.convertStackTraceToString(e,
> > e.getStackTrace());       serverProperties.getLogger().info(stackTrace);
> >     }
> >
> > 05/10 20:16:20 java.lang.NullPointerException
> >  at
> > org.hackystat.kernel.admin.TestServerProperties.testConvertStackTraceToSt
> > ring(TestServerProperties.java:52)  at
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >  at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
> > :39)  at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
> > mpl.java:25)  at java.lang.reflect.Method.invoke(Method.java:324)
> >  at junit.framework.TestCase.runTest(TestCase.java:154)
> >  at junit.framework.TestCase.runBare(TestCase.java:127)
> >  at junit.framework.TestResult$1.protect(TestResult.java:106)
> >  at junit.framework.TestResult.runProtected(TestResult.java:124)
> >  at junit.framework.TestResult.run(TestResult.java:109)
> >  at junit.framework.TestCase.run(TestCase.java:118)
> >  at junit.framework.TestSuite.runTest(TestSuite.java:208)
> >  at junit.framework.TestSuite.run(TestSuite.java:203)
> >  at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTes
> > tRunner.java:421)  at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunn
> > er.java:305)  at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRun
> > ner.java:186)
> >
> >
> > At 07:39 PM 5/10/2005, Cedric wrote:
> >
> > Good suggestion to log stack trace. But I have a different approach:
> >
> > But what about:
> >   java.util.logging.Logger.throwing(String sourceClass, String
> > sourceMethod, Throwable thrown).
> >
> > I have never used this method, but I guess this might be what we need.
> >
> >
> > Here is the output from Cedric's suggestion:
> >
> >     try {
> >       nullString.toLowerCase();
> >     }
> >     catch (Exception e) {
> >       serverProperties.getLogger().throwing( "class" , "method", e);
> >     }
> >
> > 05/10 20:13:05 THROW
> >
> >
> > At 08:01 PM 5/10/2005, Hongbing wrote:
> >
> > There is a better one.
> >  log(Level level, String msg, Throwable thrown)
> >
> >
> > Here is the output from Hongbing's suggestion:
> >
> >     try {
> >       nullString.toLowerCase();
> >     }
> >     catch (Exception e) {
> >       serverProperties.getLogger().log(Level.SEVERE, "exception", e);
> >     }
> >
> > 05/10 20:04:54 exception
> >
> >
> > It seems that using these methods requires some additional extensions to
> > the Logger. The Javadoc for both these methods say, "Note that the thrown
> > argument is stored in the LogRecord thrown property, rather than the
> > LogRecord parameters property. Thus is it processed specially by output
> > Formatters and is not treated as a formatting parameter to the LogRecord
> > message property."
> >
> > I think my solution is a little simpler than creating special output
> > Formatters.
> >
> > thanks, aaron



================================
Takuya Yamashita
E-mail: [EMAIL PROTECTED]
================================

Reply via email to