Re: [Cobertura-devel] Wrong variable renaming

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

How did you generated the instrumented code ? Are you using any decompiling
tool ? I hope it is a problem in decompilation process.

The names are only for debugging reasons in JVM code and we are not doing
the renaming process.

Piotr

2010/12/22 Tamás Kende <ken...@gm...>

> Hi all,
>
> I've got a strange problem with cobertura. I have a Spring3 application,
> and I don't understand the result of the instrumentation. Cobertura renames
> the parameter of the method, but keeps the original name in the method
> itself.
> For example a setter from a class:
>
> From the original decompiled class:
>
>  private List<String> domain;
>  public void setDomain(List<String> domain) {
>     this.domain = domain;
>   }
>
> From the instrumented class:
>
>  private List<String> domain;
>  public void setDomain(List<String> arg1) {
>     int i = 0; int __cobertura__branch__number__ = -1;
>     int __cobertura__line__number__;
>     TouchCollector.touch("org.something.Class", 42); this.domain = domain;
>     TouchCollector.touch("org.something.Class", 43);
>   }
>
> So the domain string was renamed to arg1, but it was not changed in the
> method. Why is this happening? Is this because the class level variable has
> the same name as the method level?
>
>
> Thank you for your help,
>
> Regards
>
> Tamas
>
>
> ------------------------------------------------------------------------------
> Forrester recently released a report on the Return on Investment (ROI) of
> Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
> within 7 months.  Over 3 million businesses have gone Google with Google
> Apps:
> an online email calendar, and document program that's accessible from your
> browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>


-- 
Pozdrawiam,
Piotr Tabor