Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5148

Cobertura code coverage plugin breaks unit tests

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • cobertura-plugin
    • None

      We have a maven 2.0.10 build that buids a product that uses servlets, hibernate, spring and jersey.

      The maven build runs fine from the command line. We added a profile to turn on cobertura and is activated using the BUILD_NUMBER property. The build runs fine with the profile loaded explicitly using the -P maven switch. However, when run from hudson with cobertura code coverage turned on, we get exceptions from spring:

      org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'liveResource' must be of type [com.corp.m5es.rest.resources.livepc.LiveResource], but was actually of type [$Proxy114]
      at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:322)
      at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
      at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:168)
      at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:884)
      at com.sun.jersey.spi.spring.container.SpringComponentProviderFactory$SpringManagedComponentProvider.getInstance(SpringComponentProviderFactory.java:182)
      at com.sun.jersey.server.impl.component.IoCResourceFactory$PerRequestWrapper.getInstance(IoCResourceFactory.java:138)
      at com.sun.jersey.server.impl.application.WebApplicationContext.getResource(WebApplicationContext.java:160)
      at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:64)
      at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:111)
      at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:63)
      at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:654)
      at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:612)
      at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:603)
      at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:309)
      at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:425)
      at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:590)
      at com.corp.m5es.spring.M5SpringServlet.service(M5SpringServlet.java:94)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
      at com.sun.grizzly.http.servlet.FilterChainImpl.doFilter(FilterChainImpl.java:141)
      at com.sun.grizzly.http.servlet.ServletAdapter.service(ServletAdapter.java:220)
      at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:148)
      at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:621)
      at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:552)
      at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:800)
      at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
      at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
      at com.sun.grizzly.http.SelectorThread$1.execute(SelectorThread.java:649)
      at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
      at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

      We are not sure what is causing this. Perhaps byte-code engineering is broken.

      suspecting it might be an OS related issue ( hudson is running on CentOS and our dev machines are windows), we created a windows slave and directed the build to that slave. But we got the same errors.

      LiveResource is a java class with class level @Component and @Scope("prototype") annotations and has spring auto-wired members.

      I haven't been able to craete a test case that can reproduce this yet.

          [JENKINS-5148] Cobertura code coverage plugin breaks unit tests

          emmulator added a comment -

          Unless you can run the cobertura goal outside of hudson, I don't think this is a hudson issue. Cobertura needs to instrument your classes, and Spring is also instrumenting them, and these two processes clash if Spring is generating subclasses instead of implementing an interface. Is LiveResource a concrete type? If so, then you can get around this problem by creating an interface for it and injecting the interface type instead of the concrete type.

          It is unfortunate that Spring and Cobertura collide in this manner, but if you Google around a bit, you will see that this is a known issue. It's a pain to have to change your code and create interfaces just to get around this, but in the few places I found it in our code, it turned out we probably should have had an interface anyway.

          emmulator added a comment - Unless you can run the cobertura goal outside of hudson, I don't think this is a hudson issue. Cobertura needs to instrument your classes, and Spring is also instrumenting them, and these two processes clash if Spring is generating subclasses instead of implementing an interface. Is LiveResource a concrete type? If so, then you can get around this problem by creating an interface for it and injecting the interface type instead of the concrete type. It is unfortunate that Spring and Cobertura collide in this manner, but if you Google around a bit, you will see that this is a known issue. It's a pain to have to change your code and create interfaces just to get around this, but in the few places I found it in our code, it turned out we probably should have had an interface anyway.

          moizd added a comment -

          I probably wasn't clear about this in my initial bug report. The maven build runs the cobertura goal. It runs fine stand-alone from the command line. LivepcResrouce is a concrete type. However, I can't make it an interface since that will break integration with Jersey.

          Our primary development platform is Windows, while Hudson runs on a CentOS host. I thought that maybe that had something to do with this issue. So, I set up my own development workstation as a slave and tied the build to the Hudson slave running on my workstation. It still failed with the same problem.

          moizd added a comment - I probably wasn't clear about this in my initial bug report. The maven build runs the cobertura goal. It runs fine stand-alone from the command line. LivepcResrouce is a concrete type. However, I can't make it an interface since that will break integration with Jersey. Our primary development platform is Windows, while Hudson runs on a CentOS host. I thought that maybe that had something to do with this issue. So, I set up my own development workstation as a slave and tied the build to the Hudson slave running on my workstation. It still failed with the same problem.

          Last two releases (separated by over a year) were by olivergondza so looks like the maintainer

          Stephen Connolly added a comment - Last two releases (separated by over a year) were by olivergondza so looks like the maintainer

            Unassigned Unassigned
            moizd moizd
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: