cleaning up groovy stacktraces

View: New views
12 Messages — Rating Filter:   Alert me  

cleaning up groovy stacktraces

by phil swenson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I just ran a unit test in groovy and got a big stack dump (intentional).  If you take a look, the interesting part is:
 at test.testcases.db.UpdateDbConfUnitTest.testLog(UpdateDbConfUnitTest.groovy:42)

all the groovy added sun.reflect,lang.MetaClassImpl, InvokerHelper, ScriptByteCodeAdapter, etc stuff is not useful.

Are there any plans on cleaning this up or having a flag to turn off the noise? 

Thanks
phil

(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR: java.lang.RuntimeException: blah
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at org.codehaus.groovy.runtime.MetaClassHelper.doConstructorInvoke(MetaClassHelper.java:535)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at groovy.lang.MetaClassImpl.doConstructorInvoke(MetaClassImpl.java:2356)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:1255)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:1185)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at org.codehaus.groovy.runtime.InvokerHelper.invokeConstructorOf(InvokerHelper.java:809)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeNewN(ScriptBytecodeAdapter.java:230)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at test.testcases.db.UpdateDbConfUnitTest.testLog(UpdateDbConfUnitTest.groovy:42)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at java.lang.reflect.Method.invoke(Method.java:585)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at junit.framework.TestCase.runTest(TestCase.java:164)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at junit.framework.TestCase.runBare(TestCase.java:130)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at junit.framework.TestResult$1.protect(TestResult.java:106)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at junit.framework.TestResult.runProtected(TestResult.java:124)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at junit.framework.TestResult.run(TestResult.java:109)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at junit.framework.TestCase.run(TestCase.java:120)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at junit.textui.TestRunner.doRun(TestRunner.java:121)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at com.intellij.rt.execution.junit.IdeaTestRunner.doRun(IdeaTestRunner.java:65)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT ERROR:   at junit.textui.TestRunner.doRun(TestRunner.java:114)


Re: cleaning up groovy stacktraces

by Andres Almiray :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

GroovyConsole already supports stack trace sanitizing. IDEs should be responsible for doing the same.
That leaves groovysh and the groovy interpreter, which I believe the former to have something similar to groovyConsole but I'm not exactly sure.

You can also wire a stack trace filter of your own depending on your logging strategy (I have done it with log4j), it really is not that difficult, sometimes is better to roll your own =)

phil swenson wrote:
I just ran a unit test in groovy and got a big stack dump (intentional).  If
you take a look, the interesting part is:
 at
test.testcases.db.UpdateDbConfUnitTest.testLog(UpdateDbConfUnitTest.groovy:42)

all the groovy added sun.reflect,lang.MetaClassImpl, InvokerHelper,
ScriptByteCodeAdapter, etc stuff is not useful.

Are there any plans on cleaning this up or having a flag to turn off the
noise?

Thanks
phil

(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR: java.lang.RuntimeException: blah
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
org.codehaus.groovy.runtime.MetaClassHelper.doConstructorInvoke(MetaClassHelper.java:535)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
groovy.lang.MetaClassImpl.doConstructorInvoke(MetaClassImpl.java:2356)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:1255)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:1185)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
org.codehaus.groovy.runtime.InvokerHelper.invokeConstructorOf(InvokerHelper.java:809)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeNewN(ScriptBytecodeAdapter.java:230)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
test.testcases.db.UpdateDbConfUnitTest.testLog(UpdateDbConfUnitTest.groovy:42)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at java.lang.reflect.Method.invoke(Method.java:585)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at junit.framework.TestCase.runTest(TestCase.java:164)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at junit.framework.TestCase.runBare(TestCase.java:130)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at junit.framework.TestResult$1.protect(TestResult.java:106)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at junit.framework.TestResult.runProtected(TestResult.java:124)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at junit.framework.TestResult.run(TestResult.java:109)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at junit.framework.TestCase.run(TestCase.java:120)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at junit.textui.TestRunner.doRun(TestRunner.java:121)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at
com.intellij.rt.execution.junit.IdeaTestRunner.doRun(IdeaTestRunner.java:65)
(OPTIMIZE) [AE.UpdateDbConfUnitTest.UnknownKey] 2008-06-26 14:58:48.397 MDT
ERROR:   at junit.textui.TestRunner.doRun(TestRunner.java:114)

Re: cleaning up groovy stacktraces

by Peter Niederwieser :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I really think Groovy should come with an official stack trace filter, because
1. it's not so easy to implement a good filter (e.g. you cannot just filter out all reflection stuff)
2. such a filter has to evolve with the language implementation (I wrote a filter for 1.5 which is completely obsolete as of 1.6)

Cheers,
Peter

Andres Almiray wrote:
You can also wire a stack trace filter of your own depending on your logging strategy (I have done it with log4j), it really is not that difficult, sometimes is better to roll your own =)

Re: cleaning up groovy stacktraces

by Andres Almiray :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Peter Niederwieser wrote:
I really think Groovy should come with an official stack trace filter, because
1. it's not so easy to implement a good filter (e.g. you cannot just filter out all reflection stuff)
2. such a filter has to evolve with the language implementation (I wrote a filter for 1.5 which is completely obsolete as of 1.6)

Cheers,
Peter
#1 reasonable enough, can you take the issue to the dev list? =)
#2 may I ask why your filter doesn't work with 1.6? my log4j version is independent of any version, except that it requires the target to use log4j of course.

Re: cleaning up groovy stacktraces

by Peter Niederwieser :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The filter identifies MOP calls by matching the stack trace against a fixed set of patterns. With the introduction of call sites, these patterns have changed a lot.

Andres Almiray wrote:
#2 may I ask why your filter doesn't work with 1.6? my log4j version is independent of any version, except that it requires the target to use log4j of course.

Re: cleaning up groovy stacktraces

by Russel Winder-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, 2008-06-27 at 11:44 -0700, Peter Niederwieser wrote:
> I really think Groovy should come with an official stack trace filter,
> because
> 1. it's not so easy to implement a good filter (e.g. you cannot just filter
> out all reflection stuff)
> 2. such a filter has to evolve with the language implementation (I wrote a
> filter for 1.5 which is completely obsolete as of 1.6)

Sounds like a very good reason for opening a JIRA issue...

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077


signature.asc (196 bytes) Download Attachment

Re: cleaning up groovy stacktraces

by phil swenson-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

did anyone open a JIRA on this?  Should I?

On Fri, Jun 27, 2008 at 11:17 PM, Russel Winder <russel.winder@...> wrote:
On Fri, 2008-06-27 at 11:44 -0700, Peter Niederwieser wrote:
> I really think Groovy should come with an official stack trace filter,
> because
> 1. it's not so easy to implement a good filter (e.g. you cannot just filter
> out all reflection stuff)
> 2. such a filter has to evolve with the language implementation (I wrote a
> filter for 1.5 which is completely obsolete as of 1.6)

Sounds like a very good reason for opening a JIRA issue...

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077


RE: cleaning up groovy stacktraces

by David Sills :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.

What is the status of Apache Commons things in Groovy? (Of course, I know they can be used, but are they?)

 

Their ExceptionUtils is remarkably able at taking a long, complex stack trace and reducing it to clear, simple, relevant output. I use it often in Java.

 


From: phil.swenson@... [mailto:phil.swenson@...] On Behalf Of phil swenson
Sent: Monday, July 07, 2008 6:43 PM
To: user@...
Subject: Re: [groovy-user] cleaning up groovy stacktraces

 

did anyone open a JIRA on this?  Should I?

On Fri, Jun 27, 2008 at 11:17 PM, Russel Winder <russel.winder@...> wrote:

On Fri, 2008-06-27 at 11:44 -0700, Peter Niederwieser wrote:
> I really think Groovy should come with an official stack trace filter,
> because
> 1. it's not so easy to implement a good filter (e.g. you cannot just filter
> out all reflection stuff)
> 2. such a filter has to evolve with the language implementation (I wrote a
> filter for 1.5 which is completely obsolete as of 1.6)

Sounds like a very good reason for opening a JIRA issue...

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

 


RE: cleaning up groovy stacktraces

by Russel Winder-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

David,

On Mon, 2008-07-07 at 19:02 -0400, David Sills wrote:
> What is the status of Apache Commons things in Groovy? (Of course, I
> know they can be used, but are they?)

A Groovy installation comes complete with Commons CLI 1.0 and Commons
Logging 1.1.  So for a standard installation you can use them, but any
other Commons stuff you have top load up yourself.  Of course if you are
using groovy-all then there are no Commons jars available since the
dependencies are JarJar'd.

>
--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077


signature.asc (196 bytes) Download Attachment

Re: cleaning up groovy stacktraces

by Russel Winder-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Mon, 2008-07-07 at 16:43 -0600, phil swenson wrote:
> did anyone open a JIRA on this?  Should I?

I think that would be a good move.

All Apache Commons CLI activity appears to have ceased again.  I cannot
see 1.2 or 2.0 actually seeing the light of day at this rate.

> On Fri, Jun 27, 2008 at 11:17 PM, Russel Winder
> <russel.winder@...> wrote:
>         On Fri, 2008-06-27 at 11:44 -0700, Peter Niederwieser wrote:
>         > I really think Groovy should come with an official stack
>         trace filter,
>         > because
>         > 1. it's not so easy to implement a good filter (e.g. you
>         cannot just filter
>         > out all reflection stuff)
>         > 2. such a filter has to evolve with the language
>         implementation (I wrote a
>         > filter for 1.5 which is completely obsolete as of 1.6)
>        
>        
>         Sounds like a very good reason for opening a JIRA issue...

>
--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077


signature.asc (196 bytes) Download Attachment

Re: cleaning up groovy stacktraces

by hdockter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Jun 26, 2008, at 11:04 PM, phil swenson wrote:

> I just ran a unit test in groovy and got a big stack dump  
> (intentional).  If you take a look, the interesting part is:
>  at test.testcases.db.UpdateDbConfUnitTest.testLog
> (UpdateDbConfUnitTest.groovy:42)
>
> all the groovy added sun.reflect,lang.MetaClassImpl, InvokerHelper,  
> ScriptByteCodeAdapter, etc stuff is not useful.
>
> Are there any plans on cleaning this up or having a flag to turn  
> off the noise?
>

There is the class: org.codehaus.groovy.runtime.StackTraceUtils which  
offers methods for filtering the Groovy stacktrace.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: cleaning up groovy stacktraces

by phil swenson-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I created a JIRA for this.   Please feel free to add any comments/suggestions on this.

http://jira.codehaus.org/browse/GROOVY-2944

On Tue, Jul 8, 2008 at 8:29 AM, Hans Dockter <mail@...> wrote:

On Jun 26, 2008, at 11:04 PM, phil swenson wrote:

I just ran a unit test in groovy and got a big stack dump (intentional).  If you take a look, the interesting part is:
 at test.testcases.db.UpdateDbConfUnitTest.testLog(UpdateDbConfUnitTest.groovy:42)

all the groovy added sun.reflect,lang.MetaClassImpl, InvokerHelper, ScriptByteCodeAdapter, etc stuff is not useful.

Are there any plans on cleaning this up or having a flag to turn off the noise?


There is the class: org.codehaus.groovy.runtime.StackTraceUtils which offers methods for filtering the Groovy stacktrace.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email



LightInTheBox - Buy quality products at wholesale price