Re: [Code Coverage] running tests leads to huge stacktrace

[Antoine Roux]

I usually have this kind of exception when one of the files (plugin or jar) is corrupted. Maybe you could try to remove the plugins and folders from your disk to let them be downloaded again, hoping they won't be corrupted?

On Wed, Mar 30, 2011 at 4:56 PM, Lucas F. A. Teixeira <[hidden email]> wrote:

Robin,

That output was when i just ran the code as you can see.

But then, the test runs normally, after that I get another exception, I think it is the same..

https://gist.github.com/894549

But as I said before, the test reports gets generated.

[]s,

 

Lucas Frare Teixeira .·.
- [hidden email]
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex

On Wed, Mar 30, 2011 at 11:43 AM, Lucas F. A. Teixeira <[hidden email]> wrote:

I'm using 1.3.6...

This is the output I've got: https://gist.github.com/894526

[]s,

Lucas Frare Teixeira .·.
- [hidden email]
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex

On Wed, Mar 30, 2011 at 11:27 AM, rbramley <[hidden email]> wrote:

Code coverage 1.2 is definitely working for me with Grails 1.3.5.
Just tested again with "grails test-app -coverage -xml" against a test
application (available from https://github.com/rbramley/GroovyMag29).

Will upgrade the Grails version when I get a chance later on to see what
happens...


--
View this message in context: http://grails.1312388.n4.nabble.com/Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3417930p3418227.html

Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email

[lucastex]

Hi Antoine,

I bet this wouldn't be the problem, since I have my project in my notebook, work's desktop, home desktop and jenkins CI, all giving the same error.

Maybe a corrupted file in the plugin structure in the plugin repo, but this would trigger the exception to everyone... :(

[]s,

 

Lucas Frare Teixeira .·.
- [hidden email]
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex

On Thu, Mar 31, 2011 at 6:22 AM, Antoine Roux <[hidden email]> wrote:

I usually have this kind of exception when one of the files (plugin or jar) is corrupted. Maybe you could try to remove the plugins and folders from your disk to let them be downloaded again, hoping they won't be corrupted?

On Wed, Mar 30, 2011 at 4:56 PM, Lucas F. A. Teixeira <[hidden email]> wrote:

Robin,

That output was when i just ran the code as you can see.

But then, the test runs normally, after that I get another exception, I think it is the same..

https://gist.github.com/894549

But as I said before, the test reports gets generated.

[]s,

 

Lucas Frare Teixeira .·.
- [hidden email]
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex

On Wed, Mar 30, 2011 at 11:43 AM, Lucas F. A. Teixeira <[hidden email]> wrote:

I'm using 1.3.6...

This is the output I've got: https://gist.github.com/894526

[]s,

Lucas Frare Teixeira .·.
- [hidden email]
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex

On Wed, Mar 30, 2011 at 11:27 AM, rbramley <[hidden email]> wrote:

Code coverage 1.2 is definitely working for me with Grails 1.3.5.
Just tested again with "grails test-app -coverage -xml" against a test
application (available from https://github.com/rbramley/GroovyMag29).

Will upgrade the Grails version when I get a chance later on to see what
happens...


--
View this message in context: http://grails.1312388.n4.nabble.com/Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3417930p3418227.html

Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email

[Mike Joyce]

After facing the same problem for weeks, I finally took time to investigate it. It looks like some plugins (such as the export plugin) have non-jar files in their lib dir. As the AntClassLoader is going through each of the files in the classpath, the AntClassLoader.getResourceURL() method is called for each of them, and if the resource is a valid file, it attempts to open it as a ZipFile. When java.util.zip.ZipFile throws the exception because the file is not a zip file, the stacktrace is printed to the screen, causing the ugly stack we see in the console.

Because I don't have enough knowledge about the Ant classpath loading, my solution was to simply remove the TXT license files which the export plugin put into it's lib directory. I realize this is a hacky fix and the problem will crop up again when we upgrade the plugin. But for now, it'll get rid of the stack trace.

I hope this helps,

Mike Joyce

[Andreas Schmitt]

Hi Mike,

thank you very much for posting this. In which context do you get this
error concerning the export plugin?
I would like to fix this issue, currently I'm thinking about where one
should put the license files that are related to those jars.
Ideally those files shouldn't be picked up, because they are nor jar files.

Best regards,
Andreas

2011/5/2 Mike Joyce <[hidden email]>:

> After facing the same problem for weeks, I finally took time to investigate
> it. It looks like some plugins (such as the export plugin) have non-jar
> files in their lib dir. As the AntClassLoader is going through each of the
> files in the classpath, the AntClassLoader.getResourceURL() method is called
> for each of them, and if the resource is a valid file, it attempts to open
> it as a ZipFile. When java.util.zip.ZipFile throws the exception because the
> file is not a zip file, the stacktrace is printed to the screen, causing the
> ugly stack we see in the console.
>
> Because I don't have enough knowledge about the Ant classpath loading, my
> solution was to simply remove the TXT license files which the export plugin
> put into it's lib directory. I realize this is a hacky fix and the problem
> will crop up again when we upgrade the plugin. But for now, it'll get rid of
> the stack trace.
>
> I hope this helps,
>
> Mike Joyce
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3491065.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Konstantinos Kostarellis]

Hi Andreas,

when looking at grails plugins in general authors tend to use a LICENSE.txt file in the plugins main directory. Some of them simply list all licences of all plugin artefacts in there. 

So you could either extend your LICENSE.txt or put the others (itext, odf, jexcelapi, opencsv, xercesimpl) aside. Just a suggestion. << The bug affects me too.

As an alternative approach the code-coverage plugin could ignore those ;)

Cheers,

   Kosta

On Tue, May 3, 2011 at 5:53 PM, Andreas Schmitt <[hidden email]> wrote:

Hi Mike,

thank you very much for posting this. In which context do you get this
error concerning the export plugin?
I would like to fix this issue, currently I'm thinking about where one
should put the license files that are related to those jars.
Ideally those files shouldn't be picked up, because they are nor jar files.

Best regards,
Andreas

2011/5/2 Mike Joyce <[hidden email]>:

> After facing the same problem for weeks, I finally took time to investigate
> it. It looks like some plugins (such as the export plugin) have non-jar
> files in their lib dir. As the AntClassLoader is going through each of the
> files in the classpath, the AntClassLoader.getResourceURL() method is called
> for each of them, and if the resource is a valid file, it attempts to open
> it as a ZipFile. When java.util.zip.ZipFile throws the exception because the
> file is not a zip file, the stacktrace is printed to the screen, causing the
> ugly stack we see in the console.
>
> Because I don't have enough knowledge about the Ant classpath loading, my
> solution was to simply remove the TXT license files which the export plugin
> put into it's lib directory. I realize this is a hacky fix and the problem
> will crop up again when we upgrade the plugin. But for now, it'll get rid of
> the stack trace.
>
> I hope this helps,
>
> Mike Joyce
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3491065.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

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

   http://xircles.codehaus.org/manage_email

[Mike Joyce]

My understanding is that the test classpath includes all of the plugin lib directories ($GRAILS_HOME/scripts/_GrailsClasspath.groovy; testClasspath() closure), and all of the files in it. When the code-coverage plugin initializes it's ant task, it needs to load the "tasks.properties" out of the cobertura jar file ($PROJECT/plugins/code-coverage-1.2.4/scripts/_Events.groovy; defineCoberturaPathAndTasks() ). The "java.util.zip.ZipException: error in opening zip file" stack trace is shown as Ant is looping through every file on the classpath and opening it to see if it contains the desired "tasks.properties". When it hits the license files that the export plugin has in the lib directory, we see the stack trace since they are not zip files (jars).

After digging looking through the AntClassLoader closer, it looks like they intended to call log() instead of e.printStackTrace() when this exception occurs. Infact, in v1.8.0 of ant, that catch block has already been fixed to use the proper log() instead of just e.printStackTrace()... so if ant v1.8.0 was being used, then we're be able to ignore the logs via log config.

Since I don't think ant 1.8.0 is planning to be brought into Grails, I think the best solution is to have the license files in the export plugin removed from the lib directory.

Mike

On Wed, May 4, 2011 at 2:31 AM, Konstantinos Kostarellis [via Grails] <[hidden email]> wrote:

Hi Andreas,

when looking at grails plugins in general authors tend to use a LICENSE.txt file in the plugins main directory. Some of them simply list all licences of all plugin artefacts in there. 

So you could either extend your LICENSE.txt or put the others (itext, odf, jexcelapi, opencsv, xercesimpl) aside. Just a suggestion. << The bug affects me too.

As an alternative approach the code-coverage plugin could ignore those ;)

Cheers,

   Kosta

On Tue, May 3, 2011 at 5:53 PM, Andreas Schmitt <[hidden email]> wrote:

Hi Mike,

thank you very much for posting this. In which context do you get this
error concerning the export plugin?
I would like to fix this issue, currently I'm thinking about where one
should put the license files that are related to those jars.
Ideally those files shouldn't be picked up, because they are nor jar files.

Best regards,
Andreas

2011/5/2 Mike Joyce <[hidden email]>:

> After facing the same problem for weeks, I finally took time to investigate
> it. It looks like some plugins (such as the export plugin) have non-jar
> files in their lib dir. As the AntClassLoader is going through each of the
> files in the classpath, the AntClassLoader.getResourceURL() method is called
> for each of them, and if the resource is a valid file, it attempts to open
> it as a ZipFile. When java.util.zip.ZipFile throws the exception because the
> file is not a zip file, the stacktrace is printed to the screen, causing the
> ugly stack we see in the console.
>
> Because I don't have enough knowledge about the Ant classpath loading, my
> solution was to simply remove the TXT license files which the export plugin
> put into it's lib directory. I realize this is a hacky fix and the problem
> will crop up again when we upgrade the plugin. But for now, it'll get rid of
> the stack trace.
>
> I hope this helps,
>
> Mike Joyce
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3491065.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

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

   http://xircles.codehaus.org/manage_email

---

If you reply to this email, your message will be added to the discussion below:

http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3494736.html

To unsubscribe from Re: [Code Coverage] running tests leads to huge stacktrace, click here.

[rbramley]

A better fix would be for the classpath to ignore any text files in plugin lib folders. Can be achieved with the following patch:


--- grails-1.3.7/scripts/_GrailsClasspath.groovy.orig Wed Feb 16 07:14:06 2011
+++ grails-1.3.7/scripts/_GrailsClasspath.groovy Sat May 28 23:14:36 2011
@@ -119,7 +119,7 @@
 
     def pluginLibDirs = pluginSettings.pluginLibDirectories.findAll { it.exists() }
     for (pluginLib in pluginLibDirs) {
-        fileset(dir: pluginLib.file.absolutePath)
+        fileset(dir: pluginLib.file.absolutePath, excludes:'**/*.txt')
     }
 }
 


Robin

------
Twitter: @rbramley
Blog: http://leanjavaengineering.wordpress.com

[edward.young]

This seems to solve the problem so thanks for the simple fix.

Anyone see any undesirable side effects to this?

On Sat, May 28, 2011 at 4:21 PM, rbramley <[hidden email]> wrote:

A better fix would be for the classpath to ignore any text files in plugin
lib folders. Can be achieved with the following patch:


--- grails-1.3.7/scripts/_GrailsClasspath.groovy.orig   Wed Feb 16 07:14:06
2011
+++ grails-1.3.7/scripts/_GrailsClasspath.groovy        Sat May 28 23:14:36 2011
@@ -119,7 +119,7 @@

    def pluginLibDirs = pluginSettings.pluginLibDirectories.findAll {
it.exists() }
    for (pluginLib in pluginLibDirs) {
-        fileset(dir: pluginLib.file.absolutePath)
+        fileset(dir: pluginLib.file.absolutePath, excludes:'**/*.txt')
    }
 }



Robin

------
Twitter: @rbramley
Blog: http://leanjavaengineering.wordpress.com


--
View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3558137.html

Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email

--
- Ed

[Mike Joyce]

That is perfect for me.

Mike

On Tue, May 31, 2011 at 3:12 PM, edward.young [via Grails] <[hidden email]> wrote:

This seems to solve the problem so thanks for the simple fix.

Anyone see any undesirable side effects to this?

On Sat, May 28, 2011 at 4:21 PM, rbramley <[hidden email]> wrote:

A better fix would be for the classpath to ignore any text files in plugin
lib folders. Can be achieved with the following patch:


--- grails-1.3.7/scripts/_GrailsClasspath.groovy.orig   Wed Feb 16 07:14:06
2011
+++ grails-1.3.7/scripts/_GrailsClasspath.groovy        Sat May 28 23:14:36 2011
@@ -119,7 +119,7 @@

    def pluginLibDirs = pluginSettings.pluginLibDirectories.findAll {
it.exists() }
    for (pluginLib in pluginLibDirs) {
-        fileset(dir: pluginLib.file.absolutePath)
+        fileset(dir: pluginLib.file.absolutePath, excludes:'**/*.txt')
    }
 }



Robin

------
Twitter: @rbramley
Blog: http://leanjavaengineering.wordpress.com

--
View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3558137.html

Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email

--
- Ed

---

If you reply to this email, your message will be added to the discussion below:

http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3564205.html

To unsubscribe from Re: [Code Coverage] running tests leads to huge stacktrace, click here.

[Konstantinos Kostarellis]

Nice tweak,

but you can still run into the problem with other non-"zip-py" files.
E.g. the tomcat .1.3.7.2 plugin comes with a "ivy-1.0.xml" file, which obviously
results in the same problem.

2011/5/29 rbramley <[hidden email]>

A better fix would be for the classpath to ignore any text files in plugin
lib folders. Can be achieved with the following patch:


--- grails-1.3.7/scripts/_GrailsClasspath.groovy.orig   Wed Feb 16 07:14:06
2011
+++ grails-1.3.7/scripts/_GrailsClasspath.groovy        Sat May 28 23:14:<a href="tel:36%202011" value="[phone]">36 2011
@@ -119,7 +119,7 @@

    def pluginLibDirs = pluginSettings.pluginLibDirectories.findAll {
it.exists() }
    for (pluginLib in pluginLibDirs) {
-        fileset(dir: pluginLib.file.absolutePath)
+        fileset(dir: pluginLib.file.absolutePath, excludes:'**/*.txt')
    }
 }



Robin

------
Twitter: @rbramley
Blog: http://leanjavaengineering.wordpress.com


--
View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3558137.html

Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email