|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
|
|
cleaning up groovy stacktracesI 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 stacktracesGroovyConsole 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 =)
|
|
|
Re: cleaning up groovy stacktracesI 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
|
|
|
Re: cleaning up groovy stacktraces#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 stacktracesThe 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.
|
|
|
Re: cleaning up groovy stacktracesOn 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 stacktracesdid anyone open a JIRA on this? Should I?
On Fri, Jun 27, 2008 at 11:17 PM, Russel Winder <russel.winder@...> wrote:
|
|
|
RE: cleaning up groovy stacktracesWhat 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 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: Sounds like a very good reason for opening a JIRA issue... |
|
|
RE: cleaning up groovy stacktracesDavid,
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 |
|
|
Re: cleaning up groovy stacktracesOn 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 |
|
|
Re: cleaning up groovy stacktracesOn 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 stacktracesI 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:
|
| Free Forum Powered by Nabble | Forum Help |