cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "metatech (Commented) (JIRA)" <>
Subject [jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF JAX-RS in OSGi environment
Date Wed, 11 Jan 2012 10:29:39 GMT


metatech commented on CXF-3949:

The problem happened again, this time with a possibility to debug.
It looks like a race condition in the OsgiLocator between the JSR 311 bundle still starting
(trying to register the RuntimeDelegate) and the application bundle trying to retrieve the
The problem still happens even after several SMX restarts.
Any idea ?

"SpringOsgiExtenderThread-16" prio=10 tid=0x08ba1400 nid=0x316c runnable [0x8aeb9000]
   java.lang.Thread.State: RUNNABLE
	at org.apache.servicemix.specs.locator.OsgiLocator.locate(
	- locked <0x925e62d8> (a java.lang.Class for org.apache.servicemix.specs.locator.OsgiLocator)
	- locked <0x91fd0a48> (a java.lang.Class for
	at org.apache.cxf.jaxrs.utils.JAXRSUtils.<clinit>(
	at org.apache.cxf.jaxrs.model.OperationResourceInfo.checkMediaTypes(
	at org.apache.cxf.jaxrs.model.OperationResourceInfo.<init>(
	at org.apache.cxf.jaxrs.utils.ResourceUtils.createOperationInfo(
	at org.apache.cxf.jaxrs.utils.ResourceUtils.evaluateResourceClass(
	at org.apache.cxf.jaxrs.utils.ResourceUtils.createClassResourceInfo(
	at org.apache.cxf.jaxrs.JAXRSServiceFactoryBean.setResourceClassesFromBeans(
	at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setServiceBeans(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at org.springframework.beans.BeanWrapperImpl.setPropertyValue(
	at org.springframework.beans.BeanWrapperImpl.setPropertyValue(
	at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(
	at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(

"FelixStartLevel" daemon prio=10 tid=0x8e39ec00 nid=0x3003 waiting for monitor entry [0x8ec73000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.apache.servicemix.specs.locator.OsgiLocator.register(
	- waiting to lock <0x925e62d8> (a java.lang.Class for org.apache.servicemix.specs.locator.OsgiLocator)
	at org.apache.servicemix.specs.locator.Activator.register(
	at org.apache.servicemix.specs.locator.Activator.start(
	- locked <0x970ce220> (a org.apache.servicemix.specs.locator.Activator)
	at org.apache.felix.framework.util.SecureAction.startActivator(
	at org.apache.felix.framework.Felix.activateBundle(
	at org.apache.felix.framework.Felix.startBundle(
	at org.apache.felix.framework.Felix.setActiveStartLevel(


> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>                 Key: CXF-3949
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.3.2
>         Environment: ServiceMix 4.3
>            Reporter: metatech
>   Original Estimate: 8h
>  Remaining Estimate: 8h
> When using the CXF JAX-RS implementation in an OSGi environment, the CXF implementation
might fail to initialize properly.
> The problem is non-consistently reproduceable, but more likely to occur on machines with
high parallelism (due to several cores/threads).
> The CXF bundle ("org.apache.cxf.bundle") has a dependency on the JSR 311 API JAR ("org.apache.servicemix.specs.jsr311-api-1.1").
> But the dependency is marked as "resolution=optional" in the OSGi headers of the CXF
bundle manifest.
> As a result, if the JSR-311 bundle is not yet fully started when the CXF bundle is started,
OSGi does not "wire" these packages into the imports of the CXF bundle:
> The error is the following : 
> java.lang.NoClassDefFoundError: Could not initialize class org.apache.cxf.jaxrs.utils.JAXRSUtils
> See similar error DOSGI-1
> I guess that these packages are marked as optional because CXF can be used in an environment
where no JAX-RS is available, and it works fine as long as the application does not use this
API.  However, when an application is known to use the API, the dependency marked as "optional"
is not correct.
> Long-term solution : split CXF bundle into smaller bundles (like Jetty).
> Workaround : edit the manifest of the CXF bundle, and remove the "resolution=optional"
for the packages which are known to be used by the application.  Tip : replace "resolution"
by "resolutio2", this tricks prevents from changing the alignment of the 80-characters columns.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message