Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Problem loading bundles after instrumentation

Satyendra
2012-06-11
2013-05-09
  • Satyendra
    Satyendra
    2012-06-11

    I am facing some problem after instrumenting .class files.

    Service bundles are coming up, throwing exception

    SEVERE|null|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=12;_ThreadName=Thread-1;|org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.scr .
            at org.apache.felix.framework.Felix.activateBundle(Felix.java:1751)
            at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
            at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
            at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)
            at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1027)
            at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1013)
            at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1006)
            at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:396)
            at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:206)
    Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.apache.felix.scr.impl.Activator
            at sun.reflect.GeneratedConstructorAccessor33.newInstance(Unknown Source)
            at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
            at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
            at java.lang.Class.newInstance0(Class.java:355)
            at java.lang.Class.newInstance(Class.java:308)
            at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3520)
            at org.apache.felix.framework.Felix.activateBundle(Felix.java:1695)
            … 8 more
    |#]

    Please guide if someone knows about this problem.

     
  • Hi,

    the reason for this problem can be probably found further down in your stacktrace: EMMA instrumented classes get an dependency on on emma.jar itself - which is not accessible within a OSGi container. Some years ago I analyzed this issue and described a solution for Equinox. The paper is available here:

      http://www.eclemma.org/research/instrumentingosgi/index.html

    Cheers,
    -marc

     
  • Satyendra
    Satyendra
    2012-06-12

    Hi Marc,

    Thanks for you reply.

    I am using EMMA coverage tool on Linux platform. So as per your comment what I am getting is that in Manifest file of Emma.jar i need to export the path  "Export-Package: com.vladium.emma.rt " and the instrumented jars will import the same package "Export-Package: com.vladium.emma.rt " in their respective manifest files.

    Let me know if I am wrong in this.

    Thanks.

     
  • Correct! If it is possible for you to modify your manifests in this way this should work.

    Note that EMMA isn't a OSGi bundle. So you need to specify a proper manifest first an make sure to install it in your felix instance.

    -marc

     
  • Satyendra
    Satyendra
    2012-06-12

    I have modified the manifest files for emma.jar and service bundles.

    Install it in your felix instance?? I didn't get this.  What exactly did u mean by this?

    I have put my emma.jar in the jre extensions.

    Thanks,
    Satyendra

     
  • Sorry for this confusion, I don't know felix. Let's phrase it this way: The bundled version of emma.jar needs to be made available to felix as a regular bundle, like the instrumented bundles.

    The JRE extensions trick won't work as per default a OSGi container only allows to load java.* from the JRE.

     
  • BTW, due to all these hassles with containers I created an alternative code coverage library JaCoCo which does not have these issues by design.