cobertura-devel — General questions about using and developing Cobertura.

Re: [Cobertura-devel] Cobertura Limits

[Steven C. <ste...@re...>]

I am currently using trunk,  I have yet to try your changes.
The failure is occurring during 'business', I also notice it is doing 
flushes correctly, and it's producing results. The cobertura.ser file 
gets to about 2mb before the crash occurs. I am flushing after every 
test with the assumption garbage collection will clean up everything, 
and garbage collection will shrink the array size. I want to refrain 
from doing explicit GC calls unless absolutely necessary.

On 1/21/2011 2:49 PM, Piotr Tabor wrote:
> Steven,
>
> Do you have problems with both branches, or only with trunk.
> AFAIK the running size of instrumented code in my branch does not grow 
> in time ?
> Are your code going out of memory during 'business' run or during flush ?
>
> Piotr
>
> On Fri, Jan 21, 2011 at 5:29 PM, Steven Christou 
> <ste...@re... 
> <mailto:ste...@re...>> wrote:
>
>     We changed our code recently to include the ability to flush cobertura
>     data in our JVM at any point using the suggested code in the FAQ page.
>     Is this going to help remove this memory limit? We set our heap
>     space to
>     -Xmx1400m which I believe is really high, and it did not solve the
>     issue
>     with memory.
>
>
>     On 1/11/2011 5:07 PM, John W. Lewis wrote:
>     > There is a memory limit.   All of the line and conditional
>     counts are kept in memory till the JVM is shut down and they are
>     flushed to disk.
>     >
>     > So, as more instrumented code is executed in the test process,
>     the more memory is used by the test process.
>     >
>     > Then, when the shutdown occurs, the cobertura.ser file is loaded
>     into memory, and the in-memory counts are merged before being
>     written to the disk again.
>     >
>     > John
>     >
>     >
>     > -----Original Message-----
>     > From: Steven Christou [mailto:ste...@re...
>     <mailto:ste...@re...>]
>     > Sent: Tuesday, January 11, 2011 5:48 PM
>     > To: 'cob...@li...
>     <mailto:cob...@li...>'
>     > Subject: [Cobertura-devel] Cobertura Limits
>     >
>     > I was wondering if cobertura had any kind of limits. I ran into
>     an issue where I believe something was happening and the server
>     was starting to crash. The JVM never shut down, but at the same
>     time, when running fitnesse tests, I was getting nothing but
>     failures. I could run all my tests uninstrumented, and they would
>     all pass. This happens after I run several hundred tests though,
>     so I'm assuming I must be hitting a limit.
>     >
>     > I tried running with Piotr's changes, but I am running into an
>     issue where the tests do not even run.
>     > Email Disclaimer:
>     > http://www.redprairie.com/emaildisclaimer/
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Protect Your Site and Customers from Malware Attacks
>     > Learn about various malware tactics and how to avoid them.
>     Understand
>     > malware threats, the impact they can have on your business, and
>     how you
>     > can protect your company and customers by using code signing.
>     > http://p.sf.net/sfu/oracle-sfdevnl
>     > _______________________________________________
>     > Cobertura-devel mailing list
>     > Cob...@li...
>     <mailto:Cob...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>     >
>     >
>     Email Disclaimer:
>     http://www.redprairie.com/emaildisclaimer/
>
>
>     ------------------------------------------------------------------------------
>     Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>     Finally, a world-class log management solution at an even better
>     price-free!
>     Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>     February 28th, so secure your free ArcSight Logger TODAY!
>     http://p.sf.net/sfu/arcsight-sfd2d
>     _______________________________________________
>     Cobertura-devel mailing list
>     Cob...@li...
>     <mailto:Cob...@li...>
>     https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
>
>
> -- 
> Pozdrawiam,
> Piotr Tabor

Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Cobertura Limits

[Piotr T. <pi...@ta...>]

Steven,

Do you have problems with both branches, or only with trunk.
AFAIK the running size of instrumented code in my branch does not grow in
time ?
Are your code going out of memory during 'business' run or during flush ?

Piotr

On Fri, Jan 21, 2011 at 5:29 PM, Steven Christou <
ste...@re...> wrote:

> We changed our code recently to include the ability to flush cobertura
> data in our JVM at any point using the suggested code in the FAQ page.
> Is this going to help remove this memory limit? We set our heap space to
> -Xmx1400m which I believe is really high, and it did not solve the issue
> with memory.
>
>
> On 1/11/2011 5:07 PM, John W. Lewis wrote:
> > There is a memory limit.   All of the line and conditional counts are
> kept in memory till the JVM is shut down and they are flushed to disk.
> >
> > So, as more instrumented code is executed in the test process, the more
> memory is used by the test process.
> >
> > Then, when the shutdown occurs, the cobertura.ser file is loaded into
> memory, and the in-memory counts are merged before being written to the disk
> again.
> >
> > John
> >
> >
> > -----Original Message-----
> > From: Steven Christou [mailto:ste...@re...]
> > Sent: Tuesday, January 11, 2011 5:48 PM
> > To: 'cob...@li...'
> > Subject: [Cobertura-devel] Cobertura Limits
> >
> > I was wondering if cobertura had any kind of limits. I ran into an issue
> where I believe something was happening and the server was starting to
> crash. The JVM never shut down, but at the same time, when running fitnesse
> tests, I was getting nothing but failures. I could run all my tests
> uninstrumented, and they would all pass. This happens after I run several
> hundred tests though, so I'm assuming I must be hitting a limit.
> >
> > I tried running with Piotr's changes, but I am running into an issue
> where the tests do not even run.
> > Email Disclaimer:
> > http://www.redprairie.com/emaildisclaimer/
> >
> >
> >
> ------------------------------------------------------------------------------
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > Cobertura-devel mailing list
> > Cob...@li...
> > https://lists.sourceforge.net/lists/listinfo/cobertura-devel
> >
> >
> Email Disclaimer:
> http://www.redprairie.com/emaildisclaimer/
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>



-- 
Pozdrawiam,
Piotr Tabor

Re: [Cobertura-devel] Cobertura Limits

[John W. L. <Joh...@sa...>]

I am not aware of a time where the size of a class file affected the speed of Cobertura.    If Java does not care, Cobertura should not care how big the classfile is.

-----Original Message-----
From: Steven Christou [mailto:ste...@re...] 
Sent: Friday, January 21, 2011 1:58 PM
To: John W. Lewis
Cc: 'cob...@li...'
Subject: Re: [Cobertura-devel] Cobertura Limits

I have a test run going right now, but I removed the .ser file, so it will create a few one and keep appending the flush data to the file, to see how much code out of the actual instrumented code is actually being ran. These tests pull from probably a few hundred or thousand classes, and are not simple tests. You might actually be right about a possible deadlock issue. My next approach is to remove about the top 20 classes to see if that might be the issue. If that doesn't work, I will run the few tests before the crashing of the server and see if there is some kind of deadlocking issue. Hopefully this won't take too long to run. I was wondering how big of a .class file is too big and could cause cobertura to slow down? Or what do you consider a .class file being too big? Thanks.



On 1/21/2011 12:31 PM, John W. Lewis wrote:
> Another thought just came to mind.   Since the instrumentation method calls affect the timing of your code, if your code has a synchronization problem that does not normally show up in a normal running environment, the problem may happen more readily with instrumented code.   Perhaps the timeouts are happening because of a deadlock scenario that does not normally happen but is more likely when the code is slowed down.
>
> -----Original Message-----
> From: John W. Lewis
> Sent: Friday, January 21, 2011 12:21 PM
> To: 'Steven Christou'
> Cc: 'cob...@li...'
> Subject: RE: [Cobertura-devel] Cobertura Limits
>
>
> Ah!   Well, that probably is not due to memory.
>
> The instrumentation process puts a method call or two just before each line of your source.   So, if you have a bit of code like this:
>
> while (a>  0) {
> 	a--;
> }
>
> You can expect that to take many times longer to execute than with the uninstrumented code.
>
> I'd either instrument larger and larger subsets of the classes till you isolate which classes may have slow instrumented code, or I would use a profiler.
>
> John
>
>
> -----Original Message-----
> From: Steven Christou [mailto:ste...@re...]
> Sent: Friday, January 21, 2011 12:12 PM
> To: John W. Lewis
> Cc: 'cob...@li...'
> Subject: Re: [Cobertura-devel] Cobertura Limits
>
> Our cobertura.ser file is 15,437 KB which equals a little under 4,000 classes. We are not getting any out-of-memory exceptions, but instead our test units takes so long to run, that eventually the server times out.
>
> On 1/21/2011 10:56 AM, John W. Lewis wrote:
>> Another thing that occurred to me just now is that the counts are held as statics.   So, make sure Cobertura is only loaded by the root classloader.   If there are multiple classloaders that are loading Cobertura, they will each have their own copy of the counts.
>>
>> -----Original Message-----
>> From: John W. Lewis
>> Sent: Friday, January 21, 2011 11:51 AM
>> To: 'Steven Christou'
>> Cc: 'cob...@li...'
>> Subject: RE: [Cobertura-devel] Cobertura Limits
>>
>>
>> I'm not sure.   Let me explain the details.
>>
>> When a new line or condition is covered, Cobertura will store the new count in memory.   As more and more lines/conditions are covered, the number of counts grows.   If a line/condition is run again, the count will be incremented, but this should not increase the memory.
>>
>> When you flush the counts, the existing cobertura.ser file is read into memory.   The counts of the file are then merged with the collected counts since the last flush.   After the flush, all the counter's memory should be available for garbage collection unless we are holding onto a reference (we should not be).
>>
>> In any case, I don't believe the memory that is needed should be over two times the size of the cobertura.ser file at any given moment.   How big is the cobertura.ser file that is created by the instrumentation?
>>
>> The size of the cobertura.ser file increases with the number of class files that are instrumented.   It might give some clues if you instrument subsets.
>>
>> If you get an out-of-memory exception with a stack trace, that may explain what is causing the overrun.   Please send that.
>>
>> John
>>
>>
>> -----Original Message-----
>> From: Steven Christou [mailto:ste...@re...]
>> Sent: Friday, January 21, 2011 11:30 AM
>> To: John W. Lewis
>> Cc: 'cob...@li...'
>> Subject: Re: [Cobertura-devel] Cobertura Limits
>>
>> We changed our code recently to include the ability to flush cobertura data in our JVM at any point using the suggested code in the FAQ page.
>> Is this going to help remove this memory limit? We set our heap space to -Xmx1400m which I believe is really high, and it did not solve the issue with memory.
>>
>>
>> On 1/11/2011 5:07 PM, John W. Lewis wrote:
>>> There is a memory limit.   All of the line and conditional counts are kept in memory till the JVM is shut down and they are flushed to disk.
>>>
>>> So, as more instrumented code is executed in the test process, the more memory is used by the test process.
>>>
>>> Then, when the shutdown occurs, the cobertura.ser file is loaded into memory, and the in-memory counts are merged before being written to the disk again.
>>>
>>> John
>>>
>>>
>>> -----Original Message-----
>>> From: Steven Christou [mailto:ste...@re...]
>>> Sent: Tuesday, January 11, 2011 5:48 PM
>>> To: 'cob...@li...'
>>> Subject: [Cobertura-devel] Cobertura Limits
>>>
>>> I was wondering if cobertura had any kind of limits. I ran into an issue where I believe something was happening and the server was starting to crash. The JVM never shut down, but at the same time, when running fitnesse tests, I was getting nothing but failures. I could run all my tests uninstrumented, and they would all pass. This happens after I run several hundred tests though, so I'm assuming I must be hitting a limit.
>>>
>>> I tried running with Piotr's changes, but I am running into an issue where the tests do not even run.
>>> Email Disclaimer:
>>> http://www.redprairie.com/emaildisclaimer/
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> -------- Protect Your Site and Customers from Malware Attacks Learn 
>>> about various malware tactics and how to avoid them. Understand 
>>> malware threats, the impact they can have on your business, and how 
>>> you can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Cobertura-devel mailing list
>>> Cob...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>>
>>>
>> Email Disclaimer:
>> http://www.redprairie.com/emaildisclaimer/
>>
>>
>>
> Email Disclaimer:
> http://www.redprairie.com/emaildisclaimer/
>
>
>
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Cobertura Limits

[Steven C. <ste...@re...>]

I have a test run going right now, but I removed the .ser file, so it 
will create a few one and keep appending the flush data to the file, to 
see how much code out of the actual instrumented code is actually being 
ran. These tests pull from probably a few hundred or thousand classes, 
and are not simple tests. You might actually be right about a possible 
deadlock issue. My next approach is to remove about the top 20 classes 
to see if that might be the issue. If that doesn't work, I will run the 
few tests before the crashing of the server and see if there is some 
kind of deadlocking issue. Hopefully this won't take too long to run. I 
was wondering how big of a .class file is too big and could cause 
cobertura to slow down? Or what do you consider a .class file being too 
big? Thanks.



On 1/21/2011 12:31 PM, John W. Lewis wrote:
> Another thought just came to mind.   Since the instrumentation method calls affect the timing of your code, if your code has a synchronization problem that does not normally show up in a normal running environment, the problem may happen more readily with instrumented code.   Perhaps the timeouts are happening because of a deadlock scenario that does not normally happen but is more likely when the code is slowed down.
>
> -----Original Message-----
> From: John W. Lewis
> Sent: Friday, January 21, 2011 12:21 PM
> To: 'Steven Christou'
> Cc: 'cob...@li...'
> Subject: RE: [Cobertura-devel] Cobertura Limits
>
>
> Ah!   Well, that probably is not due to memory.
>
> The instrumentation process puts a method call or two just before each line of your source.   So, if you have a bit of code like this:
>
> while (a>  0) {
> 	a--;
> }
>
> You can expect that to take many times longer to execute than with the uninstrumented code.
>
> I'd either instrument larger and larger subsets of the classes till you isolate which classes may have slow instrumented code, or I would use a profiler.
>
> John
>
>
> -----Original Message-----
> From: Steven Christou [mailto:ste...@re...]
> Sent: Friday, January 21, 2011 12:12 PM
> To: John W. Lewis
> Cc: 'cob...@li...'
> Subject: Re: [Cobertura-devel] Cobertura Limits
>
> Our cobertura.ser file is 15,437 KB which equals a little under 4,000 classes. We are not getting any out-of-memory exceptions, but instead our test units takes so long to run, that eventually the server times out.
>
> On 1/21/2011 10:56 AM, John W. Lewis wrote:
>> Another thing that occurred to me just now is that the counts are held as statics.   So, make sure Cobertura is only loaded by the root classloader.   If there are multiple classloaders that are loading Cobertura, they will each have their own copy of the counts.
>>
>> -----Original Message-----
>> From: John W. Lewis
>> Sent: Friday, January 21, 2011 11:51 AM
>> To: 'Steven Christou'
>> Cc: 'cob...@li...'
>> Subject: RE: [Cobertura-devel] Cobertura Limits
>>
>>
>> I'm not sure.   Let me explain the details.
>>
>> When a new line or condition is covered, Cobertura will store the new count in memory.   As more and more lines/conditions are covered, the number of counts grows.   If a line/condition is run again, the count will be incremented, but this should not increase the memory.
>>
>> When you flush the counts, the existing cobertura.ser file is read into memory.   The counts of the file are then merged with the collected counts since the last flush.   After the flush, all the counter's memory should be available for garbage collection unless we are holding onto a reference (we should not be).
>>
>> In any case, I don't believe the memory that is needed should be over two times the size of the cobertura.ser file at any given moment.   How big is the cobertura.ser file that is created by the instrumentation?
>>
>> The size of the cobertura.ser file increases with the number of class files that are instrumented.   It might give some clues if you instrument subsets.
>>
>> If you get an out-of-memory exception with a stack trace, that may explain what is causing the overrun.   Please send that.
>>
>> John
>>
>>
>> -----Original Message-----
>> From: Steven Christou [mailto:ste...@re...]
>> Sent: Friday, January 21, 2011 11:30 AM
>> To: John W. Lewis
>> Cc: 'cob...@li...'
>> Subject: Re: [Cobertura-devel] Cobertura Limits
>>
>> We changed our code recently to include the ability to flush cobertura data in our JVM at any point using the suggested code in the FAQ page.
>> Is this going to help remove this memory limit? We set our heap space to -Xmx1400m which I believe is really high, and it did not solve the issue with memory.
>>
>>
>> On 1/11/2011 5:07 PM, John W. Lewis wrote:
>>> There is a memory limit.   All of the line and conditional counts are kept in memory till the JVM is shut down and they are flushed to disk.
>>>
>>> So, as more instrumented code is executed in the test process, the more memory is used by the test process.
>>>
>>> Then, when the shutdown occurs, the cobertura.ser file is loaded into memory, and the in-memory counts are merged before being written to the disk again.
>>>
>>> John
>>>
>>>
>>> -----Original Message-----
>>> From: Steven Christou [mailto:ste...@re...]
>>> Sent: Tuesday, January 11, 2011 5:48 PM
>>> To: 'cob...@li...'
>>> Subject: [Cobertura-devel] Cobertura Limits
>>>
>>> I was wondering if cobertura had any kind of limits. I ran into an issue where I believe something was happening and the server was starting to crash. The JVM never shut down, but at the same time, when running fitnesse tests, I was getting nothing but failures. I could run all my tests uninstrumented, and they would all pass. This happens after I run several hundred tests though, so I'm assuming I must be hitting a limit.
>>>
>>> I tried running with Piotr's changes, but I am running into an issue where the tests do not even run.
>>> Email Disclaimer:
>>> http://www.redprairie.com/emaildisclaimer/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> -------- Protect Your Site and Customers from Malware Attacks Learn
>>> about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how
>>> you can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Cobertura-devel mailing list
>>> Cob...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>>
>>>
>> Email Disclaimer:
>> http://www.redprairie.com/emaildisclaimer/
>>
>>
>>
> Email Disclaimer:
> http://www.redprairie.com/emaildisclaimer/
>
>
>
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Cobertura Limits

[John W. L. <Joh...@sa...>]

Another thought just came to mind.   Since the instrumentation method calls affect the timing of your code, if your code has a synchronization problem that does not normally show up in a normal running environment, the problem may happen more readily with instrumented code.   Perhaps the timeouts are happening because of a deadlock scenario that does not normally happen but is more likely when the code is slowed down. 

-----Original Message-----
From: John W. Lewis 
Sent: Friday, January 21, 2011 12:21 PM
To: 'Steven Christou'
Cc: 'cob...@li...'
Subject: RE: [Cobertura-devel] Cobertura Limits


Ah!   Well, that probably is not due to memory.

The instrumentation process puts a method call or two just before each line of your source.   So, if you have a bit of code like this:

while (a > 0) {
	a--;
}

You can expect that to take many times longer to execute than with the uninstrumented code.

I'd either instrument larger and larger subsets of the classes till you isolate which classes may have slow instrumented code, or I would use a profiler.

John


-----Original Message-----
From: Steven Christou [mailto:ste...@re...]
Sent: Friday, January 21, 2011 12:12 PM
To: John W. Lewis
Cc: 'cob...@li...'
Subject: Re: [Cobertura-devel] Cobertura Limits

Our cobertura.ser file is 15,437 KB which equals a little under 4,000 classes. We are not getting any out-of-memory exceptions, but instead our test units takes so long to run, that eventually the server times out.

On 1/21/2011 10:56 AM, John W. Lewis wrote:
> Another thing that occurred to me just now is that the counts are held as statics.   So, make sure Cobertura is only loaded by the root classloader.   If there are multiple classloaders that are loading Cobertura, they will each have their own copy of the counts.
>
> -----Original Message-----
> From: John W. Lewis
> Sent: Friday, January 21, 2011 11:51 AM
> To: 'Steven Christou'
> Cc: 'cob...@li...'
> Subject: RE: [Cobertura-devel] Cobertura Limits
>
>
> I'm not sure.   Let me explain the details.
>
> When a new line or condition is covered, Cobertura will store the new count in memory.   As more and more lines/conditions are covered, the number of counts grows.   If a line/condition is run again, the count will be incremented, but this should not increase the memory.
>
> When you flush the counts, the existing cobertura.ser file is read into memory.   The counts of the file are then merged with the collected counts since the last flush.   After the flush, all the counter's memory should be available for garbage collection unless we are holding onto a reference (we should not be).
>
> In any case, I don't believe the memory that is needed should be over two times the size of the cobertura.ser file at any given moment.   How big is the cobertura.ser file that is created by the instrumentation?
>
> The size of the cobertura.ser file increases with the number of class files that are instrumented.   It might give some clues if you instrument subsets.
>
> If you get an out-of-memory exception with a stack trace, that may explain what is causing the overrun.   Please send that.
>
> John
>
>
> -----Original Message-----
> From: Steven Christou [mailto:ste...@re...]
> Sent: Friday, January 21, 2011 11:30 AM
> To: John W. Lewis
> Cc: 'cob...@li...'
> Subject: Re: [Cobertura-devel] Cobertura Limits
>
> We changed our code recently to include the ability to flush cobertura data in our JVM at any point using the suggested code in the FAQ page.
> Is this going to help remove this memory limit? We set our heap space to -Xmx1400m which I believe is really high, and it did not solve the issue with memory.
>
>
> On 1/11/2011 5:07 PM, John W. Lewis wrote:
>> There is a memory limit.   All of the line and conditional counts are kept in memory till the JVM is shut down and they are flushed to disk.
>>
>> So, as more instrumented code is executed in the test process, the more memory is used by the test process.
>>
>> Then, when the shutdown occurs, the cobertura.ser file is loaded into memory, and the in-memory counts are merged before being written to the disk again.
>>
>> John
>>
>>
>> -----Original Message-----
>> From: Steven Christou [mailto:ste...@re...]
>> Sent: Tuesday, January 11, 2011 5:48 PM
>> To: 'cob...@li...'
>> Subject: [Cobertura-devel] Cobertura Limits
>>
>> I was wondering if cobertura had any kind of limits. I ran into an issue where I believe something was happening and the server was starting to crash. The JVM never shut down, but at the same time, when running fitnesse tests, I was getting nothing but failures. I could run all my tests uninstrumented, and they would all pass. This happens after I run several hundred tests though, so I'm assuming I must be hitting a limit.
>>
>> I tried running with Piotr's changes, but I am running into an issue where the tests do not even run.
>> Email Disclaimer:
>> http://www.redprairie.com/emaildisclaimer/
>>
>>
>> ---------------------------------------------------------------------
>> -
>> -------- Protect Your Site and Customers from Malware Attacks Learn 
>> about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how 
>> you can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Cobertura-devel mailing list
>> Cob...@li...
>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>
>>
> Email Disclaimer:
> http://www.redprairie.com/emaildisclaimer/
>
>
>
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Cobertura Limits

[John W. L. <Joh...@sa...>]

Ah!   Well, that probably is not due to memory.

The instrumentation process puts a method call or two just before each line of your source.   So, if you have a bit of code like this:

while (a > 0) {
	a--;
}

You can expect that to take many times longer to execute than with the uninstrumented code.

I'd either instrument larger and larger subsets of the classes till you isolate which classes may have slow instrumented code, or I would use a profiler.

John


-----Original Message-----
From: Steven Christou [mailto:ste...@re...] 
Sent: Friday, January 21, 2011 12:12 PM
To: John W. Lewis
Cc: 'cob...@li...'
Subject: Re: [Cobertura-devel] Cobertura Limits

Our cobertura.ser file is 15,437 KB which equals a little under 4,000 classes. We are not getting any out-of-memory exceptions, but instead our test units takes so long to run, that eventually the server times out.

On 1/21/2011 10:56 AM, John W. Lewis wrote:
> Another thing that occurred to me just now is that the counts are held as statics.   So, make sure Cobertura is only loaded by the root classloader.   If there are multiple classloaders that are loading Cobertura, they will each have their own copy of the counts.
>
> -----Original Message-----
> From: John W. Lewis
> Sent: Friday, January 21, 2011 11:51 AM
> To: 'Steven Christou'
> Cc: 'cob...@li...'
> Subject: RE: [Cobertura-devel] Cobertura Limits
>
>
> I'm not sure.   Let me explain the details.
>
> When a new line or condition is covered, Cobertura will store the new count in memory.   As more and more lines/conditions are covered, the number of counts grows.   If a line/condition is run again, the count will be incremented, but this should not increase the memory.
>
> When you flush the counts, the existing cobertura.ser file is read into memory.   The counts of the file are then merged with the collected counts since the last flush.   After the flush, all the counter's memory should be available for garbage collection unless we are holding onto a reference (we should not be).
>
> In any case, I don't believe the memory that is needed should be over two times the size of the cobertura.ser file at any given moment.   How big is the cobertura.ser file that is created by the instrumentation?
>
> The size of the cobertura.ser file increases with the number of class files that are instrumented.   It might give some clues if you instrument subsets.
>
> If you get an out-of-memory exception with a stack trace, that may explain what is causing the overrun.   Please send that.
>
> John
>
>
> -----Original Message-----
> From: Steven Christou [mailto:ste...@re...]
> Sent: Friday, January 21, 2011 11:30 AM
> To: John W. Lewis
> Cc: 'cob...@li...'
> Subject: Re: [Cobertura-devel] Cobertura Limits
>
> We changed our code recently to include the ability to flush cobertura data in our JVM at any point using the suggested code in the FAQ page.
> Is this going to help remove this memory limit? We set our heap space to -Xmx1400m which I believe is really high, and it did not solve the issue with memory.
>
>
> On 1/11/2011 5:07 PM, John W. Lewis wrote:
>> There is a memory limit.   All of the line and conditional counts are kept in memory till the JVM is shut down and they are flushed to disk.
>>
>> So, as more instrumented code is executed in the test process, the more memory is used by the test process.
>>
>> Then, when the shutdown occurs, the cobertura.ser file is loaded into memory, and the in-memory counts are merged before being written to the disk again.
>>
>> John
>>
>>
>> -----Original Message-----
>> From: Steven Christou [mailto:ste...@re...]
>> Sent: Tuesday, January 11, 2011 5:48 PM
>> To: 'cob...@li...'
>> Subject: [Cobertura-devel] Cobertura Limits
>>
>> I was wondering if cobertura had any kind of limits. I ran into an issue where I believe something was happening and the server was starting to crash. The JVM never shut down, but at the same time, when running fitnesse tests, I was getting nothing but failures. I could run all my tests uninstrumented, and they would all pass. This happens after I run several hundred tests though, so I'm assuming I must be hitting a limit.
>>
>> I tried running with Piotr's changes, but I am running into an issue where the tests do not even run.
>> Email Disclaimer:
>> http://www.redprairie.com/emaildisclaimer/
>>
>>
>> ---------------------------------------------------------------------
>> -
>> -------- Protect Your Site and Customers from Malware Attacks Learn 
>> about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how 
>> you can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Cobertura-devel mailing list
>> Cob...@li...
>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>
>>
> Email Disclaimer:
> http://www.redprairie.com/emaildisclaimer/
>
>
>
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Cobertura Limits

[Steven C. <ste...@re...>]

Our cobertura.ser file is 15,437 KB which equals a little under 4,000 
classes. We are not getting any out-of-memory exceptions, but instead 
our test units takes so long to run, that eventually the server times out.

On 1/21/2011 10:56 AM, John W. Lewis wrote:
> Another thing that occurred to me just now is that the counts are held as statics.   So, make sure Cobertura is only loaded by the root classloader.   If there are multiple classloaders that are loading Cobertura, they will each have their own copy of the counts.
>
> -----Original Message-----
> From: John W. Lewis
> Sent: Friday, January 21, 2011 11:51 AM
> To: 'Steven Christou'
> Cc: 'cob...@li...'
> Subject: RE: [Cobertura-devel] Cobertura Limits
>
>
> I'm not sure.   Let me explain the details.
>
> When a new line or condition is covered, Cobertura will store the new count in memory.   As more and more lines/conditions are covered, the number of counts grows.   If a line/condition is run again, the count will be incremented, but this should not increase the memory.
>
> When you flush the counts, the existing cobertura.ser file is read into memory.   The counts of the file are then merged with the collected counts since the last flush.   After the flush, all the counter's memory should be available for garbage collection unless we are holding onto a reference (we should not be).
>
> In any case, I don't believe the memory that is needed should be over two times the size of the cobertura.ser file at any given moment.   How big is the cobertura.ser file that is created by the instrumentation?
>
> The size of the cobertura.ser file increases with the number of class files that are instrumented.   It might give some clues if you instrument subsets.
>
> If you get an out-of-memory exception with a stack trace, that may explain what is causing the overrun.   Please send that.
>
> John
>
>
> -----Original Message-----
> From: Steven Christou [mailto:ste...@re...]
> Sent: Friday, January 21, 2011 11:30 AM
> To: John W. Lewis
> Cc: 'cob...@li...'
> Subject: Re: [Cobertura-devel] Cobertura Limits
>
> We changed our code recently to include the ability to flush cobertura data in our JVM at any point using the suggested code in the FAQ page.
> Is this going to help remove this memory limit? We set our heap space to -Xmx1400m which I believe is really high, and it did not solve the issue with memory.
>
>
> On 1/11/2011 5:07 PM, John W. Lewis wrote:
>> There is a memory limit.   All of the line and conditional counts are kept in memory till the JVM is shut down and they are flushed to disk.
>>
>> So, as more instrumented code is executed in the test process, the more memory is used by the test process.
>>
>> Then, when the shutdown occurs, the cobertura.ser file is loaded into memory, and the in-memory counts are merged before being written to the disk again.
>>
>> John
>>
>>
>> -----Original Message-----
>> From: Steven Christou [mailto:ste...@re...]
>> Sent: Tuesday, January 11, 2011 5:48 PM
>> To: 'cob...@li...'
>> Subject: [Cobertura-devel] Cobertura Limits
>>
>> I was wondering if cobertura had any kind of limits. I ran into an issue where I believe something was happening and the server was starting to crash. The JVM never shut down, but at the same time, when running fitnesse tests, I was getting nothing but failures. I could run all my tests uninstrumented, and they would all pass. This happens after I run several hundred tests though, so I'm assuming I must be hitting a limit.
>>
>> I tried running with Piotr's changes, but I am running into an issue where the tests do not even run.
>> Email Disclaimer:
>> http://www.redprairie.com/emaildisclaimer/
>>
>>
>> ----------------------------------------------------------------------
>> -------- Protect Your Site and Customers from Malware Attacks Learn
>> about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how
>> you can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Cobertura-devel mailing list
>> Cob...@li...
>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>
>>
> Email Disclaimer:
> http://www.redprairie.com/emaildisclaimer/
>
>
>
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Cobertura Limits

[John W. L. <Joh...@sa...>]

Another thing that occurred to me just now is that the counts are held as statics.   So, make sure Cobertura is only loaded by the root classloader.   If there are multiple classloaders that are loading Cobertura, they will each have their own copy of the counts.

-----Original Message-----
From: John W. Lewis 
Sent: Friday, January 21, 2011 11:51 AM
To: 'Steven Christou'
Cc: 'cob...@li...'
Subject: RE: [Cobertura-devel] Cobertura Limits


I'm not sure.   Let me explain the details.

When a new line or condition is covered, Cobertura will store the new count in memory.   As more and more lines/conditions are covered, the number of counts grows.   If a line/condition is run again, the count will be incremented, but this should not increase the memory.

When you flush the counts, the existing cobertura.ser file is read into memory.   The counts of the file are then merged with the collected counts since the last flush.   After the flush, all the counter's memory should be available for garbage collection unless we are holding onto a reference (we should not be).

In any case, I don't believe the memory that is needed should be over two times the size of the cobertura.ser file at any given moment.   How big is the cobertura.ser file that is created by the instrumentation?  

The size of the cobertura.ser file increases with the number of class files that are instrumented.   It might give some clues if you instrument subsets.

If you get an out-of-memory exception with a stack trace, that may explain what is causing the overrun.   Please send that.

John


-----Original Message-----
From: Steven Christou [mailto:ste...@re...]
Sent: Friday, January 21, 2011 11:30 AM
To: John W. Lewis
Cc: 'cob...@li...'
Subject: Re: [Cobertura-devel] Cobertura Limits

We changed our code recently to include the ability to flush cobertura data in our JVM at any point using the suggested code in the FAQ page. 
Is this going to help remove this memory limit? We set our heap space to -Xmx1400m which I believe is really high, and it did not solve the issue with memory.


On 1/11/2011 5:07 PM, John W. Lewis wrote:
> There is a memory limit.   All of the line and conditional counts are kept in memory till the JVM is shut down and they are flushed to disk.
>
> So, as more instrumented code is executed in the test process, the more memory is used by the test process.
>
> Then, when the shutdown occurs, the cobertura.ser file is loaded into memory, and the in-memory counts are merged before being written to the disk again.
>
> John
>
>
> -----Original Message-----
> From: Steven Christou [mailto:ste...@re...]
> Sent: Tuesday, January 11, 2011 5:48 PM
> To: 'cob...@li...'
> Subject: [Cobertura-devel] Cobertura Limits
>
> I was wondering if cobertura had any kind of limits. I ran into an issue where I believe something was happening and the server was starting to crash. The JVM never shut down, but at the same time, when running fitnesse tests, I was getting nothing but failures. I could run all my tests uninstrumented, and they would all pass. This happens after I run several hundred tests though, so I'm assuming I must be hitting a limit.
>
> I tried running with Piotr's changes, but I am running into an issue where the tests do not even run.
> Email Disclaimer:
> http://www.redprairie.com/emaildisclaimer/
>
>
> ----------------------------------------------------------------------
> -------- Protect Your Site and Customers from Malware Attacks Learn 
> about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how 
> you can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Cobertura Limits

[John W. L. <Joh...@sa...>]

I'm not sure.   Let me explain the details.

When a new line or condition is covered, Cobertura will store the new count in memory.   As more and more lines/conditions are covered, the number of counts grows.   If a line/condition is run again, the count will be incremented, but this should not increase the memory.

When you flush the counts, the existing cobertura.ser file is read into memory.   The counts of the file are then merged with the collected counts since the last flush.   After the flush, all the counter's memory should be available for garbage collection unless we are holding onto a reference (we should not be).

In any case, I don't believe the memory that is needed should be over two times the size of the cobertura.ser file at any given moment.   How big is the cobertura.ser file that is created by the instrumentation?  

The size of the cobertura.ser file increases with the number of class files that are instrumented.   It might give some clues if you instrument subsets.

If you get an out-of-memory exception with a stack trace, that may explain what is causing the overrun.   Please send that.

John


-----Original Message-----
From: Steven Christou [mailto:ste...@re...] 
Sent: Friday, January 21, 2011 11:30 AM
To: John W. Lewis
Cc: 'cob...@li...'
Subject: Re: [Cobertura-devel] Cobertura Limits

We changed our code recently to include the ability to flush cobertura data in our JVM at any point using the suggested code in the FAQ page. 
Is this going to help remove this memory limit? We set our heap space to -Xmx1400m which I believe is really high, and it did not solve the issue with memory.


On 1/11/2011 5:07 PM, John W. Lewis wrote:
> There is a memory limit.   All of the line and conditional counts are kept in memory till the JVM is shut down and they are flushed to disk.
>
> So, as more instrumented code is executed in the test process, the more memory is used by the test process.
>
> Then, when the shutdown occurs, the cobertura.ser file is loaded into memory, and the in-memory counts are merged before being written to the disk again.
>
> John
>
>
> -----Original Message-----
> From: Steven Christou [mailto:ste...@re...]
> Sent: Tuesday, January 11, 2011 5:48 PM
> To: 'cob...@li...'
> Subject: [Cobertura-devel] Cobertura Limits
>
> I was wondering if cobertura had any kind of limits. I ran into an issue where I believe something was happening and the server was starting to crash. The JVM never shut down, but at the same time, when running fitnesse tests, I was getting nothing but failures. I could run all my tests uninstrumented, and they would all pass. This happens after I run several hundred tests though, so I'm assuming I must be hitting a limit.
>
> I tried running with Piotr's changes, but I am running into an issue where the tests do not even run.
> Email Disclaimer:
> http://www.redprairie.com/emaildisclaimer/
>
>
> ----------------------------------------------------------------------
> -------- Protect Your Site and Customers from Malware Attacks Learn 
> about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how 
> you can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Cobertura Limits

[Steven C. <ste...@re...>]

We changed our code recently to include the ability to flush cobertura 
data in our JVM at any point using the suggested code in the FAQ page. 
Is this going to help remove this memory limit? We set our heap space to 
-Xmx1400m which I believe is really high, and it did not solve the issue 
with memory.


On 1/11/2011 5:07 PM, John W. Lewis wrote:
> There is a memory limit.   All of the line and conditional counts are kept in memory till the JVM is shut down and they are flushed to disk.
>
> So, as more instrumented code is executed in the test process, the more memory is used by the test process.
>
> Then, when the shutdown occurs, the cobertura.ser file is loaded into memory, and the in-memory counts are merged before being written to the disk again.
>
> John
>
>
> -----Original Message-----
> From: Steven Christou [mailto:ste...@re...]
> Sent: Tuesday, January 11, 2011 5:48 PM
> To: 'cob...@li...'
> Subject: [Cobertura-devel] Cobertura Limits
>
> I was wondering if cobertura had any kind of limits. I ran into an issue where I believe something was happening and the server was starting to crash. The JVM never shut down, but at the same time, when running fitnesse tests, I was getting nothing but failures. I could run all my tests uninstrumented, and they would all pass. This happens after I run several hundred tests though, so I'm assuming I must be hitting a limit.
>
> I tried running with Piotr's changes, but I am running into an issue where the tests do not even run.
> Email Disclaimer:
> http://www.redprairie.com/emaildisclaimer/
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Cobertura-devel Digest, Vol 57, Issue 8

[John W. L. <Joh...@sa...>]

Make sure you have tests that cover both the true and the false of the if statement.

From: ashwini shivakumar [mailto:ash...@gm...]
Sent: Wednesday, January 19, 2011 12:11 AM
To: cob...@li...
Subject: Re: [Cobertura-devel] Cobertura-devel Digest, Vol 57, Issue 8

hello,

even i am seeing the same issue. some condition in the coverage report says 1/2 or 50% covered.
looking forward for suggestions

Thanks,
Ashwini
On Wed, Jan 19, 2011 at 2:35 AM, <cob...@li...<mailto:cob...@li...>> wrote:
Send Cobertura-devel mailing list submissions to
       cob...@li...<mailto:cob...@li...>

To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.sourceforge.net/lists/listinfo/cobertura-devel
or, via email, send a message with subject or body 'help' to
       cob...@li...<mailto:cob...@li...>

You can reach the person managing the list at
       cob...@li...<mailto:cob...@li...>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cobertura-devel digest..."


Today's Topics:

  1. Cobertura Question (Parra Virgen Mario-B15605)
  2. Re: Cobertura Question (John W. Lewis)
  3. Re: Cobertura Question (David Read)


----------------------------------------------------------------------

Message: 1
Date: Tue, 18 Jan 2011 20:31:17 +0000
From: Parra Virgen Mario-B15605 <B1...@fr...<mailto:B1...@fr...>>
Subject: [Cobertura-devel] Cobertura Question
To: "cob...@li...<mailto:cob...@li...>"
       <cob...@li...<mailto:cob...@li...>>
Message-ID:
       <007...@03...<mailto:007...@03...>>

Content-Type: text/plain; charset="us-ascii"

Hello,

I'm currently using Cobertura for test coverage reports and I have a question.

I'm doing aggregated test coverage reports across a multi-module project, after I run the reports over the project, sometime I'm getting some lines of the source code in red, but with a number greater than zero on them (please see image attached), and I'm wondering what does this means? Or how can I interpret this?... or maybe this is a bug?

I will really appreciate if you take some time to take a look at this, since I can't find any information on the web.

Thanks in advance.
Mario Parra

-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cobertura_question.JPG
Type: image/jpeg
Size: 4409 bytes
Desc: cobertura_question.JPG

------------------------------

Message: 2
Date: Tue, 18 Jan 2011 20:36:49 +0000
From: "John W. Lewis" <Joh...@sa...<mailto:Joh...@sa...>>
Subject: Re: [Cobertura-devel] Cobertura Question
To: Parra Virgen Mario-B15605 <B1...@fr...<mailto:B1...@fr...>>,
       "cob...@li...<mailto:cob...@li...>"
       <cob...@li...<mailto:cob...@li...>>
Message-ID:
       <EC3...@ME...<mailto:EC3...@ME...>>
Content-Type: text/plain; charset="us-ascii"


The line was executed 3 times, but the true or the false of the if statement was not covered.

Hover over the conditional in the if statement.   You will see something like 1/2 conditionals covered.

From: Parra Virgen Mario-B15605 [mailto:B1...@fr...<mailto:B1...@fr...>]
Sent: Tuesday, January 18, 2011 3:31 PM
To: cob...@li...<mailto:cob...@li...>
Subject: [Cobertura-devel] Cobertura Question

Hello,

I'm currently using Cobertura for test coverage reports and I have a question.

I'm doing aggregated test coverage reports across a multi-module project, after I run the reports over the project, sometime I'm getting some lines of the source code in red, but with a number greater than zero on them (please see image attached), and I'm wondering what does this means? Or how can I interpret this?... or maybe this is a bug?

I will really appreciate if you take some time to take a look at this, since I can't find any information on the web.

Thanks in advance.
Mario Parra

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 3
Date: Tue, 18 Jan 2011 15:34:18 -0500
From: David Read <dav...@bl...<mailto:dav...@bl...>>
Subject: Re: [Cobertura-devel] Cobertura Question
To: Parra Virgen Mario-B15605 <B1...@fr...<mailto:B1...@fr...>>
Cc: "cob...@li...<mailto:cob...@li...>"
       <cob...@li...<mailto:cob...@li...>>
Message-ID:
       <AAN...@ma...<mailto:AANLkTiktzFcfQ-5E%2BL...@ma...>>
Content-Type: text/plain; charset="windows-1252"

Mario,

The issues is that you are not testing all true/false cases in your "if"
statement.  You are probably getting to that "if" statement with req_reply
always being null (or not null).  Cobertura will flag that since you haven't
covered the Boolean completely.

Regards,

Dave


2011/1/18 Parra Virgen Mario-B15605 <B1...@fr...<mailto:B1...@fr...>>

> Hello,
>
>
>
> I?m currently using Cobertura for test coverage reports and I have a
> question.
>
>
>
> I?m doing aggregated test coverage reports across a multi-module project,
> after I run the reports over the project, sometime I?m getting some lines of
> the source code in red, but with a number greater than zero on them (please
> see image attached), and I?m wondering what does this means? Or how can I
> interpret this?... or maybe this is a bug?
>
>
>
> I will really appreciate if you take some time to take a look at this,
> since I can?t find any information on the web.
>
>
>
> Thanks in advance.
>
> Mario Parra
>
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...<mailto:Cob...@li...>
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>


--
David S. Read
CTO
*CISSP, RHCE, SCJP
*Blue Slate Solutions
39 Columbia St.
Albany, NY 12207
518-810-0368
www.blueslate.net<http://www.blueslate.net>

This e-mail and any files transmitted with it are for the sole use of Blue Slate Solutions
and the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message. Any unauthorized review, use, disclosure,
dissemination, forwarding, printing or copying of this email or any action taken in
reliance on this e-mail is strictly prohibited and may be unlawful.

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl

------------------------------

_______________________________________________
Cobertura-devel mailing list
Cob...@li...<mailto:Cob...@li...>
https://lists.sourceforge.net/lists/listinfo/cobertura-devel


End of Cobertura-devel Digest, Vol 57, Issue 8
**********************************************

Re: [Cobertura-devel] Cobertura-devel Digest, Vol 57, Issue 8

[ashwini s. <ash...@gm...>]

hello,

even i am seeing the same issue. some condition in the coverage report says
1/2 or 50% covered.
looking forward for suggestions

Thanks,
Ashwini

On Wed, Jan 19, 2011 at 2:35 AM, <
cob...@li...> wrote:

> Send Cobertura-devel mailing list submissions to
>        cob...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/cobertura-devel
> or, via email, send a message with subject or body 'help' to
>        cob...@li...
>
> You can reach the person managing the list at
>        cob...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cobertura-devel digest..."
>
>
> Today's Topics:
>
>   1. Cobertura Question (Parra Virgen Mario-B15605)
>   2. Re: Cobertura Question (John W. Lewis)
>   3. Re: Cobertura Question (David Read)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 18 Jan 2011 20:31:17 +0000
> From: Parra Virgen Mario-B15605 <B1...@fr...>
> Subject: [Cobertura-devel] Cobertura Question
> To: "cob...@li..."
>        <cob...@li...>
> Message-ID:
>        <
> 007...@03...>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello,
>
> I'm currently using Cobertura for test coverage reports and I have a
> question.
>
> I'm doing aggregated test coverage reports across a multi-module project,
> after I run the reports over the project, sometime I'm getting some lines of
> the source code in red, but with a number greater than zero on them (please
> see image attached), and I'm wondering what does this means? Or how can I
> interpret this?... or maybe this is a bug?
>
> I will really appreciate if you take some time to take a look at this,
> since I can't find any information on the web.
>
> Thanks in advance.
> Mario Parra
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: cobertura_question.JPG
> Type: image/jpeg
> Size: 4409 bytes
> Desc: cobertura_question.JPG
>
> ------------------------------
>
> Message: 2
> Date: Tue, 18 Jan 2011 20:36:49 +0000
> From: "John W. Lewis" <Joh...@sa...>
> Subject: Re: [Cobertura-devel] Cobertura Question
> To: Parra Virgen Mario-B15605 <B1...@fr...>,
>        "cob...@li..."
>        <cob...@li...>
> Message-ID:
>        <EC3...@ME...>
> Content-Type: text/plain; charset="us-ascii"
>
>
> The line was executed 3 times, but the true or the false of the if
> statement was not covered.
>
> Hover over the conditional in the if statement.   You will see something
> like 1/2 conditionals covered.
>
> From: Parra Virgen Mario-B15605 [mailto:B1...@fr...]
> Sent: Tuesday, January 18, 2011 3:31 PM
> To: cob...@li...
> Subject: [Cobertura-devel] Cobertura Question
>
> Hello,
>
> I'm currently using Cobertura for test coverage reports and I have a
> question.
>
> I'm doing aggregated test coverage reports across a multi-module project,
> after I run the reports over the project, sometime I'm getting some lines of
> the source code in red, but with a number greater than zero on them (please
> see image attached), and I'm wondering what does this means? Or how can I
> interpret this?... or maybe this is a bug?
>
> I will really appreciate if you take some time to take a look at this,
> since I can't find any information on the web.
>
> Thanks in advance.
> Mario Parra
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Tue, 18 Jan 2011 15:34:18 -0500
> From: David Read <dav...@bl...>
> Subject: Re: [Cobertura-devel] Cobertura Question
> To: Parra Virgen Mario-B15605 <B1...@fr...>
> Cc: "cob...@li..."
>        <cob...@li...>
> Message-ID:
>        <AAN...@ma...<AANLkTiktzFcfQ-5E%2BL...@ma...>
> >
> Content-Type: text/plain; charset="windows-1252"
>
> Mario,
>
> The issues is that you are not testing all true/false cases in your "if"
> statement.  You are probably getting to that "if" statement with req_reply
> always being null (or not null).  Cobertura will flag that since you
> haven't
> covered the Boolean completely.
>
> Regards,
>
> Dave
>
>
> 2011/1/18 Parra Virgen Mario-B15605 <B1...@fr...>
>
> > Hello,
> >
> >
> >
> > I?m currently using Cobertura for test coverage reports and I have a
> > question.
> >
> >
> >
> > I?m doing aggregated test coverage reports across a multi-module project,
> > after I run the reports over the project, sometime I?m getting some lines
> of
> > the source code in red, but with a number greater than zero on them
> (please
> > see image attached), and I?m wondering what does this means? Or how can I
> > interpret this?... or maybe this is a bug?
> >
> >
> >
> > I will really appreciate if you take some time to take a look at this,
> > since I can?t find any information on the web.
> >
> >
> >
> > Thanks in advance.
> >
> > Mario Parra
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > Cobertura-devel mailing list
> > Cob...@li...
> > https://lists.sourceforge.net/lists/listinfo/cobertura-devel
> >
> >
>
>
> --
> David S. Read
> CTO
> *CISSP, RHCE, SCJP
> *Blue Slate Solutions
> 39 Columbia St.
> Albany, NY 12207
> 518-810-0368
> www.blueslate.net
>
> This e-mail and any files transmitted with it are for the sole use of Blue
> Slate Solutions
> and the intended recipient(s) and may contain confidential and privileged
> information.
> If you are not the intended recipient, please contact the sender by reply
> e-mail and
> destroy all copies of the original message. Any unauthorized review, use,
> disclosure,
> dissemination, forwarding, printing or copying of this email or any action
> taken in
> reliance on this e-mail is strictly prohibited and may be unlawful.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
>
> ------------------------------
>
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
> End of Cobertura-devel Digest, Vol 57, Issue 8
> **********************************************
>

Re: [Cobertura-devel] Cobertura Question

[David R. <dav...@bl...>]

Mario,

The issues is that you are not testing all true/false cases in your "if"
statement.  You are probably getting to that "if" statement with req_reply
always being null (or not null).  Cobertura will flag that since you haven't
covered the Boolean completely.

Regards,

Dave


2011/1/18 Parra Virgen Mario-B15605 <B1...@fr...>

> Hello,
>
>
>
> I’m currently using Cobertura for test coverage reports and I have a
> question.
>
>
>
> I’m doing aggregated test coverage reports across a multi-module project,
> after I run the reports over the project, sometime I’m getting some lines of
> the source code in red, but with a number greater than zero on them (please
> see image attached), and I’m wondering what does this means? Or how can I
> interpret this?... or maybe this is a bug?
>
>
>
> I will really appreciate if you take some time to take a look at this,
> since I can’t find any information on the web.
>
>
>
> Thanks in advance.
>
> Mario Parra
>
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>


-- 
David S. Read
CTO
*CISSP, RHCE, SCJP
*Blue Slate Solutions
39 Columbia St.
Albany, NY 12207
518-810-0368
www.blueslate.net

This e-mail and any files transmitted with it are for the sole use of Blue Slate Solutions
and the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message. Any unauthorized review, use, disclosure,
dissemination, forwarding, printing or copying of this email or any action taken in 
reliance on this e-mail is strictly prohibited and may be unlawful.

Re: [Cobertura-devel] Cobertura Question

[John W. L. <Joh...@sa...>]

The line was executed 3 times, but the true or the false of the if statement was not covered.

Hover over the conditional in the if statement.   You will see something like 1/2 conditionals covered.

From: Parra Virgen Mario-B15605 [mailto:B1...@fr...]
Sent: Tuesday, January 18, 2011 3:31 PM
To: cob...@li...
Subject: [Cobertura-devel] Cobertura Question

Hello,

I'm currently using Cobertura for test coverage reports and I have a question.

I'm doing aggregated test coverage reports across a multi-module project, after I run the reports over the project, sometime I'm getting some lines of the source code in red, but with a number greater than zero on them (please see image attached), and I'm wondering what does this means? Or how can I interpret this?... or maybe this is a bug?

I will really appreciate if you take some time to take a look at this, since I can't find any information on the web.

Thanks in advance.
Mario Parra

Re: [Cobertura-devel] Coverage report "filter"?

[John W. L. <Joh...@sa...>]

For the log.debug() filtering use <ignore regex="org.apache.log4j.*" /> as explained here:  http://cobertura.sourceforge.net/anttaskreference.html

The other functionality will be coming with the next release:

	* New --ignoreTrivial switch that tells Cobertura to ignore the 
	  following in the coverage report: Getter methods that simply 
	  read a class field; Setter methods that set a class field;
	  Constructors that only set class fields and call a super 
	  class constructor.
	  (Patch 3010530 from 1576631) (Scott Frederick/Tad Smith)
	* New --ignoreMethodAnnotation switch used to specify an annotation that, 
	  when present on a method, will cause Cobertura to ignore the 
	  method in the coverage report.
	  (Patch 3010530) (Tad Smith)

The changes are available on the trunk.

John


-----Original Message-----
From: Dmitri Farafonov [mailto:far...@gm...] 
Sent: Monday, January 17, 2011 4:52 PM
To: cob...@li...
Subject: [Cobertura-devel] Coverage report "filter"?

Hi,
I could not find any documentation on that on the site, so: Does anyone know a way to filter out reporting of certain lines of code from coverage report?
For example I want to be able to exclude LOG.debug() calls and getters and setters method from being reporting at all, similar to the way Clover does: "Clover Contexts"http://confluence.atlassian.com/display/CLOVER/Using+Coverage+Contexts

Is there a way to do similar reported content filtering?

Thanks,
Dmitri.

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Cobertura-devel mailing list
Cob...@li...
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

[Cobertura-devel] Coverage report "filter"?

[Dmitri F. <far...@gm...>]

Hi,
I could not find any documentation on that on the site, so: Does
anyone know a way to filter out reporting of certain lines of code
from coverage report?
For example I want to be able to exclude LOG.debug() calls and getters
and setters method from being reporting at all, similar to the way
Clover does: "Clover
Contexts"http://confluence.atlassian.com/display/CLOVER/Using+Coverage+Contexts

Is there a way to do similar reported content filtering?

Thanks,
Dmitri.

Re: [Cobertura-devel] Multiple junit invocations on same cobertura.ser

[John W. L. <Joh...@sa...>]

No.   The counts for the new tests will be merged with the counts that are already in the cobertura.ser file.

From: Daniel Polkinghorne [mailto:Dan...@bj...]
Sent: Wednesday, January 12, 2011 12:53 PM
To: cob...@li...
Subject: [Cobertura-devel] Multiple junit invocations on same cobertura.ser

Hi All,

I have this query and cannot find an answer in docs.

Will subsequent junit invocations using a cobertura.ser file overwrite coverage data from previous junit invocations using the same file (causing coverage data loss)?

Regards,
Dan
________________________________
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed, to persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS do not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, First Floor, Coronet House, Queen Street, Leeds, LS1 2TW

[Cobertura-devel] Multiple junit invocations on same cobertura.ser

[Daniel P. <Dan...@bj...>]

Hi All,

 

I have this query and cannot find an answer in docs.

 

Will subsequent junit invocations using a cobertura.ser file overwrite
coverage data from previous junit invocations using the same file
(causing coverage data loss)?

 

Regards,

Dan



The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed, to persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS do not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, First Floor, Coronet House, Queen Street, Leeds, LS1 2TW

Re: [Cobertura-devel] Cobertura Limits

[John W. L. <Joh...@sa...>]

There is a memory limit.   All of the line and conditional counts are kept in memory till the JVM is shut down and they are flushed to disk.

So, as more instrumented code is executed in the test process, the more memory is used by the test process.

Then, when the shutdown occurs, the cobertura.ser file is loaded into memory, and the in-memory counts are merged before being written to the disk again.

John


-----Original Message-----
From: Steven Christou [mailto:ste...@re...] 
Sent: Tuesday, January 11, 2011 5:48 PM
To: 'cob...@li...'
Subject: [Cobertura-devel] Cobertura Limits

I was wondering if cobertura had any kind of limits. I ran into an issue where I believe something was happening and the server was starting to crash. The JVM never shut down, but at the same time, when running fitnesse tests, I was getting nothing but failures. I could run all my tests uninstrumented, and they would all pass. This happens after I run several hundred tests though, so I'm assuming I must be hitting a limit.

I tried running with Piotr's changes, but I am running into an issue where the tests do not even run.
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Cobertura-devel mailing list
Cob...@li...
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

[Cobertura-devel] Cobertura Limits

[Steven C. <ste...@re...>]

I was wondering if cobertura had any kind of limits. I ran into an issue 
where I believe something was happening and the server was starting to 
crash. The JVM never shut down, but at the same time, when running 
fitnesse tests, I was getting nothing but failures. I could run all my 
tests uninstrumented, and they would all pass. This happens after I run 
several hundred tests though, so I'm assuming I must be hitting a limit.

I tried running with Piotr's changes, but I am running into an issue 
where the tests do not even run.
Email Disclaimer:
http://www.redprairie.com/emaildisclaimer/

Re: [Cobertura-devel] Maven plugin with multiple execution tests

[John W. L. <Joh...@sa...>]

Let us know if they do not respond.   Previous Maven users have not had much luck recently.

From: Jake Cobb [mailto:jak...@ga...]
Sent: Wednesday, January 05, 2011 4:00 PM
To: Flavia Rainone
Cc: cob...@li...
Subject: Re: [Cobertura-devel] Maven plugin with multiple execution tests

This is probably better addressed to the Maven plugin group (which is separate from Cobertura itself): http://mojo.codehaus.org/cobertura-maven-plugin/

-Jake Cobb
On Wed, Jan 5, 2011 at 8:03 AM, Flavia Rainone <fla...@jb...<mailto:fla...@jb...>> wrote:
Can somebody please check if this is a bug?
If there is a workaround I could use, I would be glad.

Em 30-11-2010 14:34, Flavia Rainone escreveu:
> Hi all,
>
> I'm new to this list and I'm a big fan of Cobertura.
>
> I'm sending this e-mail to talk about a problem I'm having.
>
> If I run mvn clean install cobertura:cobertura with this project:
> https://github.com/jbossas/jboss-msc, the results show 0% of coverage.
>
> The problem started when I changed the pom script:
> https://github.com/jbossas/jboss-msc/blob/master/pom.xml
>
> I needed to run one of the tests with a javaagent enabled, so I had to
> create two test executions: one that runs all the other tests, and a
> second one that runs the specific test with javaagent. Given that the
> test that requires javaagent will fail if it's executed without the
> agent, I added a skip true to the surefire-plugin parent configuration,
> and each surefire execution override this value with false.
>
> My previous pom, that contained the tags below, used to work ok with
> cobertura.
>
> So I'm assuming the cause of the problem is the skip true in the parent
> surefire tag. For some reason, cobertura fails to detect that there are
> surefire executions overriding skip value with false. Can somebody look
> into this? It would be great if this were fixed in a future release :-).
>
>
> <plugin>
> <artifactId>maven-surefire-plugin</artifactId>
> <configuration>
> <systemProperties>
> <property>
> <name>jboss.msc.profile.output</name>
> <value>${project.build.testOutputDirectory}/prof.txt</value>
> </property>
> <property>
> <name>java.util.logging.manager</name>
> <value>org.jboss.logmanager.LogManager</value>
> </property>
> </systemProperties>
>
> <includes>
> <include>**/*TestCase.java</include>
> </includes>
> <excludes>
> <exclude>org/jboss/msc/bench/*.java</exclude>
> <exclude>org/jboss/msc/racecondition/*.java</exclude>
> </excludes>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-antrun-plugin</artifactId>
> <version>1.6</version>
> <executions>
> <execution>
> <id>run-racecondition-tests</id>
> <goals>
> <goal>run</goal>
> </goals>
> <phase>test</phase>
> <configuration>
> <target>
> <property name="byteman.path"
> value="${maven.dependency.org.jboss.byteman.byteman.jar.path}" />
> <property name="report.dir"
> value="${project.build.directory}/surefire-reports" />
> <property name="testOutputDirectory"
> value="${project.build.testOutputDirectory}" />
> <property name ="jboss.msc.profile.output"
> value="${project.build.testOutputDirectory}/prof.txt" />
> <property name="java.util.logging.manager"
> value="org.jboss.logmanager.LogManager" />
> <property name="bytemanScript"
> value="${testOutputDirectory}/org/jboss/msc/racecondition/StopRequestedToUpTransitionTestCase.txt"/>
> <junit printsummary="yes" fork="true" haltonfailure="true"
> haltonerror="true">
> <classpath><path refid="maven.test.classpath"/></classpath>
> <jvmarg value="-javaagent:${byteman.path}=script:${bytemanScript}"/>
> <sysproperty key="org.jboss.byteman.debug" value="true"/>
> <formatter
> classname="org.jboss.ant.taskdefs.XMLJUnitMultipleResultFormatter"
> usefile="true" extension=".xml" />
> <formatter type="plain" usefile="true" extension=".txt" />
> <test fork="yes"
> name="org.jboss.msc.racecondition.StopRequestedToUpTransitionTestCase"
> todir="${report.dir}"/>
> </junit>
> </target>
> </configuration>
> </execution>
> </executions>
> <dependencies>
> <dependency>
> <groupId>ant</groupId>
> <artifactId>ant-junit</artifactId>
> <version>1.6.5</version>
> </dependency>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>4.4</version>
> </dependency>
> </dependencies>
> </plugin>
>
> Regards,
>
>

--
Flavia Rainone | JBoss Core Developer

M: (+55) (+11) 8122-5466
YIM/MSNIM: flaviarnn


------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Cobertura-devel mailing list
Cob...@li...<mailto:Cob...@li...>
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

Re: [Cobertura-devel] Maven plugin with multiple execution tests

[Jake C. <jak...@ga...>]

This is probably better addressed to the Maven plugin group (which is
separate from Cobertura itself):
http://mojo.codehaus.org/cobertura-maven-plugin/

-Jake Cobb

On Wed, Jan 5, 2011 at 8:03 AM, Flavia Rainone <fla...@jb...>wrote:

> Can somebody please check if this is a bug?
> If there is a workaround I could use, I would be glad.
>
> Em 30-11-2010 14:34, Flavia Rainone escreveu:
> > Hi all,
> >
> > I'm new to this list and I'm a big fan of Cobertura.
> >
> > I'm sending this e-mail to talk about a problem I'm having.
> >
> > If I run mvn clean install cobertura:cobertura with this project:
> > https://github.com/jbossas/jboss-msc, the results show 0% of coverage.
> >
> > The problem started when I changed the pom script:
> > https://github.com/jbossas/jboss-msc/blob/master/pom.xml
> >
> > I needed to run one of the tests with a javaagent enabled, so I had to
> > create two test executions: one that runs all the other tests, and a
> > second one that runs the specific test with javaagent. Given that the
> > test that requires javaagent will fail if it's executed without the
> > agent, I added a skip true to the surefire-plugin parent configuration,
> > and each surefire execution override this value with false.
> >
> > My previous pom, that contained the tags below, used to work ok with
> > cobertura.
> >
> > So I'm assuming the cause of the problem is the skip true in the parent
> > surefire tag. For some reason, cobertura fails to detect that there are
> > surefire executions overriding skip value with false. Can somebody look
> > into this? It would be great if this were fixed in a future release :-).
> >
> >
> > <plugin>
> > <artifactId>maven-surefire-plugin</artifactId>
> > <configuration>
> > <systemProperties>
> > <property>
> > <name>jboss.msc.profile.output</name>
> > <value>${project.build.testOutputDirectory}/prof.txt</value>
> > </property>
> > <property>
> > <name>java.util.logging.manager</name>
> > <value>org.jboss.logmanager.LogManager</value>
> > </property>
> > </systemProperties>
> >
> > <includes>
> > <include>**/*TestCase.java</include>
> > </includes>
> > <excludes>
> > <exclude>org/jboss/msc/bench/*.java</exclude>
> > <exclude>org/jboss/msc/racecondition/*.java</exclude>
> > </excludes>
> > </configuration>
> > </plugin>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-antrun-plugin</artifactId>
> > <version>1.6</version>
> > <executions>
> > <execution>
> > <id>run-racecondition-tests</id>
> > <goals>
> > <goal>run</goal>
> > </goals>
> > <phase>test</phase>
> > <configuration>
> > <target>
> > <property name="byteman.path"
> > value="${maven.dependency.org.jboss.byteman.byteman.jar.path}" />
> > <property name="report.dir"
> > value="${project.build.directory}/surefire-reports" />
> > <property name="testOutputDirectory"
> > value="${project.build.testOutputDirectory}" />
> > <property name ="jboss.msc.profile.output"
> > value="${project.build.testOutputDirectory}/prof.txt" />
> > <property name="java.util.logging.manager"
> > value="org.jboss.logmanager.LogManager" />
> > <property name="bytemanScript"
> >
> value="${testOutputDirectory}/org/jboss/msc/racecondition/StopRequestedToUpTransitionTestCase.txt"/>
> > <junit printsummary="yes" fork="true" haltonfailure="true"
> > haltonerror="true">
> > <classpath><path refid="maven.test.classpath"/></classpath>
> > <jvmarg value="-javaagent:${byteman.path}=script:${bytemanScript}"/>
> > <sysproperty key="org.jboss.byteman.debug" value="true"/>
> > <formatter
> > classname="org.jboss.ant.taskdefs.XMLJUnitMultipleResultFormatter"
> > usefile="true" extension=".xml" />
> > <formatter type="plain" usefile="true" extension=".txt" />
> > <test fork="yes"
> > name="org.jboss.msc.racecondition.StopRequestedToUpTransitionTestCase"
> > todir="${report.dir}"/>
> > </junit>
> > </target>
> > </configuration>
> > </execution>
> > </executions>
> > <dependencies>
> > <dependency>
> > <groupId>ant</groupId>
> > <artifactId>ant-junit</artifactId>
> > <version>1.6.5</version>
> > </dependency>
> > <dependency>
> > <groupId>junit</groupId>
> > <artifactId>junit</artifactId>
> > <version>4.4</version>
> > </dependency>
> > </dependencies>
> > </plugin>
> >
> > Regards,
> >
> >
>
> --
> Flavia Rainone | JBoss Core Developer
>
> M: (+55) (+11) 8122-5466
> YIM/MSNIM: flaviarnn
>
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>

Re: [Cobertura-devel] cobertura issue

[Piotr T. <pi...@ta...>]

>
> i have deployed the coberturaflush.war also.
>

Have you called the service ?

Piotr

Re: [Cobertura-devel] Maven plugin with multiple execution tests

[Flavia R. <fla...@jb...>]

Can somebody please check if this is a bug?
If there is a workaround I could use, I would be glad.

Em 30-11-2010 14:34, Flavia Rainone escreveu:
> Hi all,
>
> I'm new to this list and I'm a big fan of Cobertura.
>
> I'm sending this e-mail to talk about a problem I'm having.
>
> If I run mvn clean install cobertura:cobertura with this project:
> https://github.com/jbossas/jboss-msc, the results show 0% of coverage.
>
> The problem started when I changed the pom script:
> https://github.com/jbossas/jboss-msc/blob/master/pom.xml
>
> I needed to run one of the tests with a javaagent enabled, so I had to
> create two test executions: one that runs all the other tests, and a
> second one that runs the specific test with javaagent. Given that the
> test that requires javaagent will fail if it's executed without the
> agent, I added a skip true to the surefire-plugin parent configuration,
> and each surefire execution override this value with false.
>
> My previous pom, that contained the tags below, used to work ok with
> cobertura.
>
> So I'm assuming the cause of the problem is the skip true in the parent
> surefire tag. For some reason, cobertura fails to detect that there are
> surefire executions overriding skip value with false. Can somebody look
> into this? It would be great if this were fixed in a future release :-).
>
>
> <plugin>
> <artifactId>maven-surefire-plugin</artifactId>
> <configuration>
> <systemProperties>
> <property>
> <name>jboss.msc.profile.output</name>
> <value>${project.build.testOutputDirectory}/prof.txt</value>
> </property>
> <property>
> <name>java.util.logging.manager</name>
> <value>org.jboss.logmanager.LogManager</value>
> </property>
> </systemProperties>
>
> <includes>
> <include>**/*TestCase.java</include>
> </includes>
> <excludes>
> <exclude>org/jboss/msc/bench/*.java</exclude>
> <exclude>org/jboss/msc/racecondition/*.java</exclude>
> </excludes>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-antrun-plugin</artifactId>
> <version>1.6</version>
> <executions>
> <execution>
> <id>run-racecondition-tests</id>
> <goals>
> <goal>run</goal>
> </goals>
> <phase>test</phase>
> <configuration>
> <target>
> <property name="byteman.path"
> value="${maven.dependency.org.jboss.byteman.byteman.jar.path}" />
> <property name="report.dir"
> value="${project.build.directory}/surefire-reports" />
> <property name="testOutputDirectory"
> value="${project.build.testOutputDirectory}" />
> <property name ="jboss.msc.profile.output"
> value="${project.build.testOutputDirectory}/prof.txt" />
> <property name="java.util.logging.manager"
> value="org.jboss.logmanager.LogManager" />
> <property name="bytemanScript"
> value="${testOutputDirectory}/org/jboss/msc/racecondition/StopRequestedToUpTransitionTestCase.txt"/>
> <junit printsummary="yes" fork="true" haltonfailure="true"
> haltonerror="true">
> <classpath><path refid="maven.test.classpath"/></classpath>
> <jvmarg value="-javaagent:${byteman.path}=script:${bytemanScript}"/>
> <sysproperty key="org.jboss.byteman.debug" value="true"/>
> <formatter
> classname="org.jboss.ant.taskdefs.XMLJUnitMultipleResultFormatter"
> usefile="true" extension=".xml" />
> <formatter type="plain" usefile="true" extension=".txt" />
> <test fork="yes"
> name="org.jboss.msc.racecondition.StopRequestedToUpTransitionTestCase"
> todir="${report.dir}"/>
> </junit>
> </target>
> </configuration>
> </execution>
> </executions>
> <dependencies>
> <dependency>
> <groupId>ant</groupId>
> <artifactId>ant-junit</artifactId>
> <version>1.6.5</version>
> </dependency>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>4.4</version>
> </dependency>
> </dependencies>
> </plugin>
>
> Regards,
>
>    

-- 
Flavia Rainone | JBoss Core Developer

M: (+55) (+11) 8122-5466
YIM/MSNIM: flaviarnn

[Cobertura-devel] cobertura issue

[ashwini s. <ash...@gm...>]

hello,

i am doing a code coverage for web application.

i can instrument the build.

i can deploy the instrumented build.

the cobertura.ser file is generated in tomcat folder which is of size 1KB.

as and when i stop the tomcat the cobertura.ser file is not updated and
remains 1KB only.

i have deployed the coberturaflush.war also.

Please look into this issue.

Thanks,
AShwini