Menu
▾
▴
cobertura-patches — Automated emails from our patch tracking system
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(12) |
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(13) |
Dec
(2) |
| 2009 |
Jan
(21) |
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(14) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(5) |
Dec
(1) |
| 2010 |
Jan
(1) |
Feb
(8) |
Mar
(4) |
Apr
|
May
|
Jun
(1) |
Jul
(9) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2011 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(6) |
Dec
(1) |
| 2013 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2010-02-10 19:31:14
|
Patches item #2948696, was opened at 2010-02-09 15:45 Message generated for change (Settings changed) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2948696&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: John Lewis (lewijw) Summary: Performance patch Initial Comment: Makes cobertura 1.9.3 (trunk) up to 10x faster. Aggregates changes in temporary TouchCollector class (thread-safe, but lock-free) and after that applies it on real model (ProjectData) as a batch operation. ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-02-10 14:31 Message: Piotr, there is no license in your new files. Do you mind if I add the dual GPL/Apache license that I have been adding to all new files? (Make sure you login to comment). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2948696&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-02-09 20:49:34
|
Patches item #2934083, was opened at 2010-01-17 22:57 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2934083&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Charlie Squires (rockonword) >Assigned to: John Lewis (lewijw) Summary: Fix for 2875576 (Some packages are included more then once) Initial Comment: The code had been looking for subpackages by doing a startsWith() on the package name. If you have packages named 'org.something' and 'org.somethingelse', 'org.somethingelse' would match the startsWith() and would be listed as a subpackage even though it's not. I changed it to look for a '.' at the end of the package name, for the package name itself (the code comments indicate the search is inclusive), and for a wildcard search using a blank package name (""). I also included a test to catch the bug, and it passes with the patch applied. Regression testing found no problems. ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-02-09 15:49 Message: Thanks, Charlie! Committed revision 690. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2934083&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-02-09 20:45:13
|
Patches item #2948696, was opened at 2010-02-09 20:45 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2948696&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Performance patch Initial Comment: Makes cobertura 1.9.3 (trunk) up to 10x faster. Aggregates changes in temporary TouchCollector class (thread-safe, but lock-free) and after that applies it on real model (ProjectData) as a batch operation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2948696&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-01-18 03:57:01
|
Patches item #2934083, was opened at 2010-01-17 22:57 Message generated for change (Tracker Item Submitted) made by rockonword You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2934083&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Charlie Squires (rockonword) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 2875576 (Some packages are included more then once) Initial Comment: The code had been looking for subpackages by doing a startsWith() on the package name. If you have packages named 'org.something' and 'org.somethingelse', 'org.somethingelse' would match the startsWith() and would be listed as a subpackage even though it's not. I changed it to look for a '.' at the end of the package name, for the package name itself (the code comments indicate the search is inclusive), and for a wildcard search using a blank package name (""). I also included a test to catch the bug, and it passes with the patch applied. Regression testing found no problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2934083&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 20:45:14
|
Patches item #2907100, was opened at 2009-12-01 15:45 Message generated for change (Tracker Item Submitted) made by gliptak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2907100&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gábor Lipták (gliptak) Assigned to: Nobody/Anonymous (nobody) Summary: completion coloring change Initial Comment: This makes the coloring the same between the completion bars and the source code and improves readability of the text on the bar. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2907100&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-11-12 14:00:22
|
Patches item #2896609, was opened at 2009-11-12 09:00 Message generated for change (Tracker Item Submitted) made by gliptak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896609&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gábor Lipták (gliptak) Assigned to: Nobody/Anonymous (nobody) Summary: replacing jakarta-oro with java.util.regex calls Initial Comment: Patch attached. As per http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html it should be noted that some Perl5 specific regexes are NOT supported with java.util.regex. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896609&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-11-12 13:27:40
|
Patches item #2896586, was opened at 2009-11-12 08:25 Message generated for change (Settings changed) made by gliptak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896586&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Gábor Lipták (gliptak) Assigned to: Nobody/Anonymous (nobody) Summary: improved coverage for JavaToHtml Initial Comment: Patch attached. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896586&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-11-12 13:25:53
|
Patches item #2896586, was opened at 2009-11-12 08:25 Message generated for change (Tracker Item Submitted) made by gliptak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896586&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gábor Lipták (gliptak) Assigned to: Nobody/Anonymous (nobody) Summary: improved coverage for JavaToHtml Initial Comment: Patch attached. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896586&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-11-11 19:05:14
|
Patches item #2896144, was opened at 2009-11-11 14:05 Message generated for change (Tracker Item Submitted) made by gliptak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896144&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gábor Lipták (gliptak) Assigned to: Nobody/Anonymous (nobody) Summary: improved coverage for JavaToHtml Initial Comment: Patch attached. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896144&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-11-11 17:58:14
|
Patches item #2896100, was opened at 2009-11-11 12:58 Message generated for change (Tracker Item Submitted) made by gliptak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896100&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gábor Lipták (gliptak) Assigned to: Nobody/Anonymous (nobody) Summary: buffering for coverage load/save Initial Comment: This patch adds BufferedStream-s There is no or minimal overhead for small .ser files, but significant performance gains for large .ser files. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2896100&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-09-15 14:08:13
|
Patches item #2859245, was opened at 2009-09-15 05:53 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2859245&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Hofer (jmhofer) Assigned to: Nobody/Anonymous (nobody) Summary: Removed oro regex dependency & some collection cleanup Initial Comment: Hi! While trying to understand the cobertura code, I did a few simple modifications: I removed the dependency on the Apache ORO matcher in favor of java.util.regex. - Or is there a reason for using ORO instead? Also, I did some collections cleanup concerning generics for increased type-safety. Also, I corrected a typo in ClassInstrumenter (regexs vs regexes). - I've now discovered that there's already another patch for that on the tracker. I hope you find this useful. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2009-09-15 07:08 Message: My guess at the reason for using Apache ORO is that java.util.regex wasn't added until java 1.4, and Cobertura used to be compatible with Java 1.3. But I think that compatibility has been dropped, so I think this should be fine. But I'm sure the ever-wise John Lewis will take a look at it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2859245&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-09-15 12:53:14
|
Patches item #2859245, was opened at 2009-09-15 14:53 Message generated for change (Tracker Item Submitted) made by jmhofer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2859245&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Hofer (jmhofer) Assigned to: Nobody/Anonymous (nobody) Summary: Removed oro regex dependency & some collection cleanup Initial Comment: Hi! While trying to understand the cobertura code, I did a few simple modifications: I removed the dependency on the Apache ORO matcher in favor of java.util.regex. - Or is there a reason for using ORO instead? Also, I did some collections cleanup concerning generics for increased type-safety. Also, I corrected a typo in ClassInstrumenter (regexs vs regexes). - I've now discovered that there's already another patch for that on the tracker. I hope you find this useful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2859245&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-08-03 16:13:25
|
Patches item #2831576, was opened at 2009-08-03 18:13 Message generated for change (Tracker Item Submitted) made by jooooooon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2831576&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Clarke (jooooooon) Assigned to: Nobody/Anonymous (nobody) Summary: Access to instrumenter class by Java call Initial Comment: Hi, I'm currently using a web development framework that compiles source code on-the-fly, to Java bytecode (the Play! framework). To integrate cobertura test coverage into the testing process, I need to instrument the generated bytecode via a Java call to cobertura's libraries. I have acheived this using the net.sourceforge.cobertura.instrument.ClassInstrumenter class. However, this class is not public. By making it public via the attached patch, and re-building the cobertura jar, all is fine, and my java classes can be compiled, instrumented and tested on the fly. Would you consider this patch for inclusion in Cobertura? If there are any feeling that this class should remain private, I would be very open to discuss alternatives. Regards, Jonathan Clarke ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2831576&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-07-10 18:20:02
|
Patches item #2035169, was opened at 2008-08-01 18:52 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2035169&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Scott Frederick (scottyfred) Assigned to: Nobody/Anonymous (nobody) Summary: Exclude methods from instrumentation (two for one sale) Initial Comment: This patch is a merge of two previous patches: 1576631 and 2009489. Patch 1576631 needed to be migrated from Cobertura 1.8 to 1.9, and there was significant overlap in the implementation of these two patches, so I merged them into one. There are a few use cases for ignoring entire methods when generating coverage metrics. One is to ignore getters and setters that follow the JavaBean pattern. There is usually little value in testing these methods, as their implementation is trivial and reliable. Another use case is to ignore code that is generated by another tool or technology during the build process. There are other use cases as well. These two patches are meant to address use cases like these. *** Ignore named methods *** Patch 2009489 implemented a new optional parameter to specify the names of methods which should be excluded from instrumentation. The optional parameter "ignoreMethod", which can be used from command line or ant tasks, excludes entire methods from instrumentation. For method name matching, the specified ignore statement can be any substring of the actual method -- making the ignore method more powerful (e.g. ".set*" and ".get*" to ignore all setters and getters). *** Ignore trivial methods *** Patch 1576631 implemented a new optional parameter that enables the inspection of methods to identify those methods that follow the JavaBean pattern for getters and setters, and excludes those methods from instrumentation. The Ant task and command-line Main accept a new boolean option named "ignoreTrivial". If this option is set to "true", methods that match the criteria below are excluded from coverage. If the option is set to "false", all methods are included as Cobertura does today. The criteria for deciding a method is trivial are: getters: - method name begins with "get", "is", or "has" - method accepts no arguments - method return type is non-void - method contains only bytecode instructions for getting member field values setters: - method name begins with "set" - method accepts exactly one argument - method return type is void - method contains only bytecode instructions for setting member field values initializers: - method name is "<init>" (constructors and implicit initializers) - method contains only bytecode instructions for setting member field values and calling initializer method of immediate superclass (e.g. "super();") ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-10 18:19 Message: There are lots of suggested ways to control what is measured for coverage. To reiterate my requirements and motivation for this patch: - I do NOT want to specify a method name pattern for exclusion/ignoring. This leaves me open to ignoring methods that look like getters/setters but in fact are not trivial and should be tested. - I do NOT wan to annotate, otherwise decorate, or provide a list of all methods to exclude/ignore. It would be a lot of work to manually identify all the candidate methods and it would become a maintenance headache. - I DO want the tool to automatically identify methods that are truly trivial, using a very tight and conservative set of heuristics (as detailed in the patch description). In other words, in the case of trivial getters and setters I don't care to have complete control over what is excluded, I want the tool to help me out and allow me to do less configuration work to get the desires outcome. ---------------------------------------------------------------------- Comment By: Ho Tri Bao (hotribao) Date: 2008-12-09 16:33 Message: Well, I totally agree with the point of scottyfred: "it is dangerous to exclude getters and setters from coverage metrics based only on the name of the method". But let me state it in a different way: "It is dangerous to exclude methods from coverage metrics based on method name pattern. AND we have no control on what were excluded" But we have to agree that this is a real need. I submitted a patch which solve these issues: - Excluded methods (I called it ignored methods) can be enumerated, wildcard is supported (I think using wildcard is simply enough for all people) - Excluded methods are reported (easy to realize) on source code view of a class - Risky Excluded methods are also reported: risky excluded methods are the ones that are complex but were excluded So, you are fully control what were excluded. Since the feature uses complexity calculation. And there is a bug for this in JDK 1.5+. This bug was also fixed in this patch. There are more features included in that patch also, such as top project risks (risky classes, risky methods) The patch is here: https://sourceforge.net/tracker/index.php?func=detail&aid=2353196&group_id=130558&atid=720017 ---------------------------------------------------------------------- Comment By: Scott Frederick (scottyfred) Date: 2008-08-01 19:03 Message: Logged In: YES user_id=294534 Originator: YES So, which new option to use? This has been debated in the descriptions and comments of the related patches. In my opinion, it is dangerous to exclude getters and setters from coverage metrics based only on the name of the method. Methods that start with "get" can contain calculations, and methods that start with "set" can have side-effects beyond just setting the value of a single data member. These "non-trivial" getters and setters (which probably violate the JavaBean pattern) should be tested, and should not be excluded from coverage metrics. The "ignoreTrivial" enhancement in this patch goes beyond inspecting just the method name, to inspect the method signature (to match only methods that follow the JavaBean signature pattern) and the byte code contained in the method (to match only methods that get or set the value of a single data member as appropriate). If you have some other way (like static code checking) to enforce that methods named with "get" and "set" follow a pattern, the excluding coverage by name might work just file. Otherwise, I think "ignoreTrivial" comes a lot closer to what you want for this use case than simple name matching does. This was the original thinking behind patch 1576631. That's just my opinion; your team and your project are almost certainly different than mine. Two options are provided here, other patches have been submitted to support annotation-based exclusion. Use whichever method works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2035169&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-25 14:56:07
|
Patches item #2806475, was opened at 2009-06-15 04:08 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Chris van Es (cvanes) Assigned to: John Lewis (lewijw) Summary: FileLocker exception when writing coverage data Initial Comment: With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2009-06-25 09:55 Message: Turns out that the delete of the lock file cannot be done while the lock is in place. So, since the FileLocker.release() method deletes the file anyway, I'm removing the FileLocker.delete method. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 09:19 Message: Rick, I see your point. I forgot the release method is doing a delete. I've removed the delete method, and within release(), I have moved the delete of the file before the release of the lock. John ---------------------------------------------------------------------- Comment By: Rick Riemer (ricq) Date: 2009-06-25 07:54 Message: The patch seems to do the job. It seems strange to add the delete call to ProjectData though, because release() already does a delete(). Two consecutive deletes won't make the file go more away. Looking forward to the release. ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-25 06:57 Message: Yes, it does seem better to catch Throwable, although I think you're right that current behaviour should remain, it's an error that we can't really recover from. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 05:47 Message: Thanks for the patch Chris! I applied your patch pretty much the way you submitted it with the following changes: 1. I delete the file before releasing the lock. Let me know if you see a problem with this. 2. I removed the catch (Exception). I hope to release 1.9.2 today, and I am more comfortable with keeping the current behavior when an Exception is thrown. We can add the print of the stack trace later if that is better, but if we do, isn't it better to catch (Throwable) instead of just Exception? Revision 604. Thanks again! John ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-16 03:37 Message: Ok, I've updated the ProjectData class to print out some info if an exception is thrown whilst attempting to output coverage data. I haven't verified but this issue may only affect java 6_14 at the minute, I haven't had a chance to determine if this is an issue with earlier updates. ---------------------------------------------------------------------- Comment By: wyvern5 (wyvern5) Date: 2009-06-15 19:33 Message: I cast a vote in favor of prioritizing this fix. :) Are you sure that the empty catch block is appropriate, though? It'd mean errors when merging and saving coverage data would be silently ignored, if I'm understanding that snippet correctly. (I haven't looked into what the calls inside the try {} are doing, though -- I'm just guessing based on the method names.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-25 14:20:03
|
Patches item #2806475, was opened at 2009-06-15 04:08 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Chris van Es (cvanes) Assigned to: John Lewis (lewijw) Summary: FileLocker exception when writing coverage data Initial Comment: With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2009-06-25 09:19 Message: Rick, I see your point. I forgot the release method is doing a delete. I've removed the delete method, and within release(), I have moved the delete of the file before the release of the lock. John ---------------------------------------------------------------------- Comment By: Rick Riemer (ricq) Date: 2009-06-25 07:54 Message: The patch seems to do the job. It seems strange to add the delete call to ProjectData though, because release() already does a delete(). Two consecutive deletes won't make the file go more away. Looking forward to the release. ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-25 06:57 Message: Yes, it does seem better to catch Throwable, although I think you're right that current behaviour should remain, it's an error that we can't really recover from. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 05:47 Message: Thanks for the patch Chris! I applied your patch pretty much the way you submitted it with the following changes: 1. I delete the file before releasing the lock. Let me know if you see a problem with this. 2. I removed the catch (Exception). I hope to release 1.9.2 today, and I am more comfortable with keeping the current behavior when an Exception is thrown. We can add the print of the stack trace later if that is better, but if we do, isn't it better to catch (Throwable) instead of just Exception? Revision 604. Thanks again! John ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-16 03:37 Message: Ok, I've updated the ProjectData class to print out some info if an exception is thrown whilst attempting to output coverage data. I haven't verified but this issue may only affect java 6_14 at the minute, I haven't had a chance to determine if this is an issue with earlier updates. ---------------------------------------------------------------------- Comment By: wyvern5 (wyvern5) Date: 2009-06-15 19:33 Message: I cast a vote in favor of prioritizing this fix. :) Are you sure that the empty catch block is appropriate, though? It'd mean errors when merging and saving coverage data would be silently ignored, if I'm understanding that snippet correctly. (I haven't looked into what the calls inside the try {} are doing, though -- I'm just guessing based on the method names.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-25 12:54:56
|
Patches item #2806475, was opened at 2009-06-15 11:08 Message generated for change (Comment added) made by ricq You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Chris van Es (cvanes) Assigned to: John Lewis (lewijw) Summary: FileLocker exception when writing coverage data Initial Comment: With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method ---------------------------------------------------------------------- Comment By: Rick Riemer (ricq) Date: 2009-06-25 14:54 Message: The patch seems to do the job. It seems strange to add the delete call to ProjectData though, because release() already does a delete(). Two consecutive deletes won't make the file go more away. Looking forward to the release. ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-25 13:57 Message: Yes, it does seem better to catch Throwable, although I think you're right that current behaviour should remain, it's an error that we can't really recover from. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 12:47 Message: Thanks for the patch Chris! I applied your patch pretty much the way you submitted it with the following changes: 1. I delete the file before releasing the lock. Let me know if you see a problem with this. 2. I removed the catch (Exception). I hope to release 1.9.2 today, and I am more comfortable with keeping the current behavior when an Exception is thrown. We can add the print of the stack trace later if that is better, but if we do, isn't it better to catch (Throwable) instead of just Exception? Revision 604. Thanks again! John ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-16 10:37 Message: Ok, I've updated the ProjectData class to print out some info if an exception is thrown whilst attempting to output coverage data. I haven't verified but this issue may only affect java 6_14 at the minute, I haven't had a chance to determine if this is an issue with earlier updates. ---------------------------------------------------------------------- Comment By: wyvern5 (wyvern5) Date: 2009-06-16 02:33 Message: I cast a vote in favor of prioritizing this fix. :) Are you sure that the empty catch block is appropriate, though? It'd mean errors when merging and saving coverage data would be silently ignored, if I'm understanding that snippet correctly. (I haven't looked into what the calls inside the try {} are doing, though -- I'm just guessing based on the method names.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-25 11:57:38
|
Patches item #2806475, was opened at 2009-06-15 10:08 Message generated for change (Comment added) made by cvanes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Chris van Es (cvanes) Assigned to: John Lewis (lewijw) Summary: FileLocker exception when writing coverage data Initial Comment: With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-25 12:57 Message: Yes, it does seem better to catch Throwable, although I think you're right that current behaviour should remain, it's an error that we can't really recover from. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 11:47 Message: Thanks for the patch Chris! I applied your patch pretty much the way you submitted it with the following changes: 1. I delete the file before releasing the lock. Let me know if you see a problem with this. 2. I removed the catch (Exception). I hope to release 1.9.2 today, and I am more comfortable with keeping the current behavior when an Exception is thrown. We can add the print of the stack trace later if that is better, but if we do, isn't it better to catch (Throwable) instead of just Exception? Revision 604. Thanks again! John ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-16 09:37 Message: Ok, I've updated the ProjectData class to print out some info if an exception is thrown whilst attempting to output coverage data. I haven't verified but this issue may only affect java 6_14 at the minute, I haven't had a chance to determine if this is an issue with earlier updates. ---------------------------------------------------------------------- Comment By: wyvern5 (wyvern5) Date: 2009-06-16 01:33 Message: I cast a vote in favor of prioritizing this fix. :) Are you sure that the empty catch block is appropriate, though? It'd mean errors when merging and saving coverage data would be silently ignored, if I'm understanding that snippet correctly. (I haven't looked into what the calls inside the try {} are doing, though -- I'm just guessing based on the method names.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-25 11:10:42
|
Patches item #1918079, was opened at 2008-03-18 06:49 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1918079&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: John Lewis (lewijw) Summary: Fix for ArrayIndexOutOfBoundsException Initial Comment: When running cobertura (v 1.9) in our multithreded tests, often an ArrayIndexOutOfBoundsException occurs when starting up our application server (similar to bugs 1838589 and 1913421). We fixed the LineData class and made 2 methods synchronized (but may be, some of the ClassData and other methods which fill the collections are also in need of synchronization). ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2009-06-25 06:10 Message: Thanks for submitting the patch. This was fixed on June 5th with revision 602. I hope to release 1.9.2 today. I was concerned with a possible deadlock during merges and equals, so I ended up using the java concurrent Lock object added with Java 5. I am aquiring a lock on both objects involved in the merge/equals before proceeding. ---------------------------------------------------------------------- Comment By: Rick Oosterholt (ricktw) Date: 2009-03-03 10:55 Message: Hi, the patch is working; thanks for that! It might be better though to make the merge function synchronized as well: public synchronized void merge(CoverageData coverageData) thanks anyways for this patch! grtz, Rick ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1918079&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-25 11:05:57
|
Patches item #2722288, was opened at 2009-03-30 13:08 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2722288&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: GS FitNesse (gs-fitnesse) >Assigned to: John Lewis (lewijw) Summary: Fix LineData so that it can be used during across threads Initial Comment: Fix LineData so that it can be used during across threads. Fixed bugs registered like this. http://www.nabble.com/Cobertura-1.9-potential-threading-bug-fix-td19326045.html ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2009-06-25 06:05 Message: Thanks for submitting the patch. As Piotr has commented, this issue was fixed on June 5th with revision 602. I hope to release 1.9.2 today. I was concerned with a possible deadlock during merges and equals, so I ended up using the java concurrent Lock object added with Java 5. I am aquiring a lock on both objects involved in the merge/equals before proceeding. ---------------------------------------------------------------------- Comment By: Piotr Tabor (ptab) Date: 2009-06-06 02:27 Message: Having the same problem. Seems to be already fixed in trunk (1.9.1 is still corrupted, by trunk seems to be ok): JumpData getJumpData(int jumpNumber) { lock.lock(); try { if (jumps == null) { jumps = new ArrayList(); } if (jumps.size() <= jumpNumber) { for (int i = jumps.size(); i <= jumpNumber; jumps.add(new JumpData(i++))); } return (JumpData) jumps.get(jumpNumber); } finally { lock.unlock(); } } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2722288&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-25 10:55:56
|
Patches item #2792112, was opened at 2009-05-15 03:48 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2792112&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: John Lewis (lewijw) Summary: Cobertura fails with JUnit tests that uses multiple threads Initial Comment: A JUnit test with a number of threads which makes calls to the same class (not necessaries the same object) will fail with Cobertura because of a bug in Cobertura. The problem is that the classes inside Cobertura's coveragedata package is not thread safe and when collecting data from concurrent threads this can result in an exception which look something like: java.lang.IndexOutOfBoundsException: Index: 0, Size: 1 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at net.sourceforge.cobertura.coveragedata.LineData.getJumpData(LineData.java:316) at net.sourceforge.cobertura.coveragedata.LineData.touchJump(LineData.java:259) at net.sourceforge.cobertura.coveragedata.ClassData.touchJump(ClassData.java:453) at code.ConcurrentAccessObject.addText(ConcurrentAccessObject.java:25) at test.ConcurrentAccessObjectTest$TestThread.run(ConcurrentAccessObjectTest.java:30) I have written a fix for the bug which makes the touch methods on the ClassData class synchronized. This does that only one thread is allowed to update the coveragedata when running tests. Please note that the bug is not easy to reproduce consistently because it is a concurrency bug. The included JUnit test case will therefore not always work. Also note that is fixes the same problem as Cobertura patch 2722288 in SourceForge. But I think that my patch may be a simpler and better solution. ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2009-06-25 05:55 Message: Thanks for the patch, but I cannot open it for some reason. Is it corrupt? This issue has recently been fixed. I hope to release 1.9.2 today. It will have the fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2792112&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-25 10:47:26
|
Patches item #2806475, was opened at 2009-06-15 04:08 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Chris van Es (cvanes) Assigned to: John Lewis (lewijw) Summary: FileLocker exception when writing coverage data Initial Comment: With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2009-06-25 05:47 Message: Thanks for the patch Chris! I applied your patch pretty much the way you submitted it with the following changes: 1. I delete the file before releasing the lock. Let me know if you see a problem with this. 2. I removed the catch (Exception). I hope to release 1.9.2 today, and I am more comfortable with keeping the current behavior when an Exception is thrown. We can add the print of the stack trace later if that is better, but if we do, isn't it better to catch (Throwable) instead of just Exception? Revision 604. Thanks again! John ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-16 03:37 Message: Ok, I've updated the ProjectData class to print out some info if an exception is thrown whilst attempting to output coverage data. I haven't verified but this issue may only affect java 6_14 at the minute, I haven't had a chance to determine if this is an issue with earlier updates. ---------------------------------------------------------------------- Comment By: wyvern5 (wyvern5) Date: 2009-06-15 19:33 Message: I cast a vote in favor of prioritizing this fix. :) Are you sure that the empty catch block is appropriate, though? It'd mean errors when merging and saving coverage data would be silently ignored, if I'm understanding that snippet correctly. (I haven't looked into what the calls inside the try {} are doing, though -- I'm just guessing based on the method names.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-25 10:43:59
|
Patches item #2806475, was opened at 2009-06-15 04:08 Message generated for change (Settings changed) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris van Es (cvanes) >Assigned to: John Lewis (lewijw) Summary: FileLocker exception when writing coverage data Initial Comment: With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-16 03:37 Message: Ok, I've updated the ProjectData class to print out some info if an exception is thrown whilst attempting to output coverage data. I haven't verified but this issue may only affect java 6_14 at the minute, I haven't had a chance to determine if this is an issue with earlier updates. ---------------------------------------------------------------------- Comment By: wyvern5 (wyvern5) Date: 2009-06-15 19:33 Message: I cast a vote in favor of prioritizing this fix. :) Are you sure that the empty catch block is appropriate, though? It'd mean errors when merging and saving coverage data would be silently ignored, if I'm understanding that snippet correctly. (I haven't looked into what the calls inside the try {} are doing, though -- I'm just guessing based on the method names.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-16 08:37:56
|
Patches item #2806475, was opened at 2009-06-15 10:08 Message generated for change (Comment added) made by cvanes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris van Es (cvanes) Assigned to: Nobody/Anonymous (nobody) Summary: FileLocker exception when writing coverage data Initial Comment: With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-16 09:37 Message: Ok, I've updated the ProjectData class to print out some info if an exception is thrown whilst attempting to output coverage data. I haven't verified but this issue may only affect java 6_14 at the minute, I haven't had a chance to determine if this is an issue with earlier updates. ---------------------------------------------------------------------- Comment By: wyvern5 (wyvern5) Date: 2009-06-16 01:33 Message: I cast a vote in favor of prioritizing this fix. :) Are you sure that the empty catch block is appropriate, though? It'd mean errors when merging and saving coverage data would be silently ignored, if I'm understanding that snippet correctly. (I haven't looked into what the calls inside the try {} are doing, though -- I'm just guessing based on the method names.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2009-06-16 00:33:09
|
Patches item #2806475, was opened at 2009-06-15 02:08 Message generated for change (Comment added) made by wyvern5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris van Es (cvanes) Assigned to: Nobody/Anonymous (nobody) Summary: FileLocker exception when writing coverage data Initial Comment: With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method ---------------------------------------------------------------------- Comment By: wyvern5 (wyvern5) Date: 2009-06-15 17:33 Message: I cast a vote in favor of prioritizing this fix. :) Are you sure that the empty catch block is appropriate, though? It'd mean errors when merging and saving coverage data would be silently ignored, if I'm understanding that snippet correctly. (I haven't looked into what the calls inside the try {} are doing, though -- I'm just guessing based on the method names.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 |
1 message has been excluded from this view by a project administrator.
