Scott Gray wrote: > On 8/04/2010, at 10:54 AM, Adam Heath wrote: > >> Robert Morley wrote: >>> Hey Adam, this is not what my results have shown. When I execute the >>> tests in our current trunk there are 216 tests executed (from the JUnit >>> reports) and I get code coverage on UtilValidate based on my initial >>> comment in the other thread "Here is my question -- when looking at the >>> reports it showed 100% line code coverage in UtilValidate (for example) >>> but this was for 111 lines. Clearly this class has many more lines than >>> that, and when I opened it up I saw that large portions of it were not >>> marked green or red in the report. What gives? :)" >> You misunderstand. The classes are marked 100% covered, but that is >> the problem. They are *not* 100% covered. The bug is that the double >> class loaders are writing to the same cobertura.dat file, and the >> first classloader, that contains framework/base code, gets corrupted >> output. >> >> You loading framework/base as a component, so it's testdef files can >> be run, will not solve the actual problem, of the double classloaders, >> and 2 cobertura instances. >> >> Without loading any of the framework/base tests, we should still get >> correct coverage values on base, just because it happens to be called >> by everything else in the system. But we don't, the numbers are wrong. > > Shooting from the hip here but couldn't the classpath entries be removed from > the base ofbiz-component file?
Wouldn't have anything to do with the problem. framework/start reads foo.properties file. Finds location of framework/base/lib. Does a recursive directory scan, creates classloader will all found jars. With this first classloader, it now starts loading component/container classes, which read all the rest of the defined components in the rest of framework, applications, and specialpurpose. Now that we have a list of components, a second classloader is created, with all their defined classpath entries. It's parent is the first classloader. In both cases, these classloaders are instrumented dynamically at construction time. All found jars are copied to $TEMP, and instrumented on the fly. Both classloaders are configured to write to the same cobertura.dat file. Ideally, I'd like to see some of component/container moved into start. Then base would be just like any other component.
