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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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
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.