You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "metatech (Created) (JIRA)" <ji...@apache.org> on 2011/12/02 15:55:40 UTC
[jira] [Created] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
NoClassDefFoundError when using CXF JAX-RS in OSGi environment
--------------------------------------------------------------
Key: CXF-3949
URL: https://issues.apache.org/jira/browse/CXF-3949
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.3.2
Environment: ServiceMix 4.3
Reporter: metatech
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:
javax.ws.rs
javax.ws.rs.core
javax.ws.rs.ext
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162880#comment-13162880 ]
Sergey Beryozkin commented on CXF-3949:
---------------------------------------
I updated the cxf-jaxrs bundle only to drop the resolution=optional.
Metatech, I guess we should document what needs to be done in case of the DOSGi multibundle distribution (which depends on cxf-minimal bundle); if you could experiment with setting up the start-up levels then it would be great.
Cheers, Sergey
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "metatech (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172300#comment-13172300 ]
metatech commented on CXF-3949:
-------------------------------
New info : the problem happened again, with the edited manifest workaround present, therefore the origin of the race condition is not the dependency of the CXF bundle, but something else, most probably not related to CXF itself.
Unfortunately, the "PropertyBatchUpdateException" of Spring seems to drop one level of "caused by" on the exception, so it is not easy to tell which class exactly is not found.
Caused by: org.springframework.beans.PropertyBatchUpdateException; nested PropertyAccessExceptions (1) are:
PropertyAccessException 1: org.springframework.beans.MethodInvocationException: Property 'myBean' threw exception; nested exception is java.lang.NoClassDefFoundError: Could not initialize class org.apache.cxf.jaxrs.utils.JAXRSUtils
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409374#comment-13409374 ]
Sergey Beryozkin commented on CXF-3949:
---------------------------------------
Hi Stephan, I added the static initializer to CXFNonSpringJaxrsServlet, thanks
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "metatech (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
metatech updated CXF-3949:
--------------------------
Description:
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:
javax.ws.rs
javax.ws.rs.core
javax.ws.rs.ext
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.
was:
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:
javax.ws.rs
javax.ws.rs.core
javax.ws.rs.ext
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.
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "metatech (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163472#comment-13163472 ]
metatech commented on CXF-3949:
-------------------------------
Daniel,
I did not install CXF manuallly, it got installed by default in the ServiceMix 4.3 distribution.
The problem is, I think, that the CXF bundle gets installed a few milliseconds too early, before the JSR 311 is completely installed, which means that the OSGi framework does not wait for the JSR 311 bundle to become available, but ignores this dependency and installs the CXF bundle without it.
In Felix 3.0.9 (provided in SMX 4.3), manually executing a OSGI refresh of both bundles does not help, because the class ModuleImpl caches the dependencies (in member variable "m_cachedRequirements"), and the only way to update the dependencies is to uninstall/install the bundle, which cannot be practically performed if many other bundles depend on it.
Regarding the change of the start-level, I experienced that it does not work in all cases, but that it merely reduces the window of the race condition, see my comment in https://issues.apache.org/jira/browse/SMX4-744.
The ideal solution would be that the optional features of the CXF bundle are delivered as separate optional bundles, but I understand that this will create a higher complexity for the CXF distribution.
Regards.
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "metatech (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184084#comment-13184084 ]
metatech commented on CXF-3949:
-------------------------------
I found 2 workarounds to make it work with ServiceMix 4.3 (which includes component "specs-1.7.0") :
1. osgi:bundle-level <ID of org.apache.servicemix.specs.jsr311-api-1.1> 50
2. osgi:bundle-level <ID of application using CXF> 80 #for *all* applications using CXF
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "metatech (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183968#comment-13183968 ]
metatech commented on CXF-3949:
-------------------------------
Maybe SMX4-860 will make the problem disappear ?
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "metatech (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183964#comment-13183964 ]
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 RuntimeDelegate.
The problem still happens even after several SMX restarts.
Any idea ?
{code}
"SpringOsgiExtenderThread-16" prio=10 tid=0x08ba1400 nid=0x316c runnable [0x8aeb9000]
java.lang.Thread.State: RUNNABLE
at org.apache.servicemix.specs.locator.OsgiLocator.locate(OsgiLocator.java:58)
- locked <0x925e62d8> (a java.lang.Class for org.apache.servicemix.specs.locator.OsgiLocator)
at javax.ws.rs.ext.FactoryFinder.find(FactoryFinder.java:79)
at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:105)
at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:91)
- locked <0x91fd0a48> (a java.lang.Class for javax.ws.rs.ext.RuntimeDelegate)
at javax.ws.rs.core.MediaType.<clinit>(MediaType.java:44)
at org.apache.cxf.jaxrs.utils.JAXRSUtils.<clinit>(JAXRSUtils.java:104)
at org.apache.cxf.jaxrs.model.OperationResourceInfo.checkMediaTypes(OperationResourceInfo.java:169)
at org.apache.cxf.jaxrs.model.OperationResourceInfo.<init>(OperationResourceInfo.java:74)
at org.apache.cxf.jaxrs.utils.ResourceUtils.createOperationInfo(ResourceUtils.java:341)
at org.apache.cxf.jaxrs.utils.ResourceUtils.evaluateResourceClass(ResourceUtils.java:218)
at org.apache.cxf.jaxrs.utils.ResourceUtils.createClassResourceInfo(ResourceUtils.java:204)
at org.apache.cxf.jaxrs.JAXRSServiceFactoryBean.setResourceClassesFromBeans(JAXRSServiceFactoryBean.java:214)
at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setServiceBeans(JAXRSServerFactoryBean.java:188)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1114)
at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:900)
at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:76)
at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:58)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1358)
{code}
{code}
"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(OsgiLocator.java:44)
- waiting to lock <0x925e62d8> (a java.lang.Class for org.apache.servicemix.specs.locator.OsgiLocator)
at org.apache.servicemix.specs.locator.Activator.register(Activator.java:116)
at org.apache.servicemix.specs.locator.Activator.start(Activator.java:70)
- locked <0x970ce220> (a org.apache.servicemix.specs.locator.Activator)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1842)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1759)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1163)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:662)
{code}
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "metatech (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173020#comment-13173020 ]
metatech commented on CXF-3949:
-------------------------------
Freeman,
The problem is not really reproduceable. It occurred only twice :
1. on one of the 2 nodes on a large machine (similar to our production machine)
2. on a laptop under a debugging session, with breakpoints in SMX deploying/starting tasks (SpringOsgiExtenderThread, FelixStartLevel, Blueprint Extender, DirectoryWatcher, ...).
This leads me to believe that this is really a narrow race condition that can occur under some very specific timings, which the "start-level" workaround does not allow to fix.
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "Freeman Fang (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172894#comment-13172894 ]
Freeman Fang commented on CXF-3949:
-----------------------------------
Hi,
Is there any chance that you can append a testcase(src project which we can build and deploy) to reproduce it?
Freeman
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "Daniel Kulp (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162847#comment-13162847 ]
Daniel Kulp commented on CXF-3949:
----------------------------------
This is working properly at this point. The JSR-311 bundle needs to be installed prior to installing the CXF bundle. (or the CXF bundle would need to be refreshed after installing it)
If you use the karaf features file that we provide with CXF, all of this is taken care of for you and the api jars are set with a much earlier start level to make sure they are installed and started first.
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Beryozkin resolved CXF-3949.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.7.0
2.6.2
2.5.5
2.4.9
Assignee: Sergey Beryozkin
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.3.2
> Environment: ServiceMix 4.3
> Reporter: metatech
> Assignee: Sergey Beryozkin
> Fix For: 2.4.9, 2.5.5, 2.6.2, 2.7.0
>
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183986#comment-13183986 ]
Sergey Beryozkin commented on CXF-3949:
---------------------------------------
> Maybe SMX4-860 will make the problem disappear ?
Hopefully, CXF & DOSGi 1.3-snapshot also have a 1.9.0 dependency
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3949) NoClassDefFoundError when using CXF
JAX-RS in OSGi environment
Posted by "Stephan Klevenz (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252274#comment-13252274 ]
Stephan Klevenz commented on CXF-3949:
--------------------------------------
Hi,
I found another workaround to get rid of this issue:
public class CXFNonSpringJaxrsServlet2 extends CXFNonSpringJaxrsServlet {
static {
// workaround for OSGi environment
// ensure that the correct JAX-RS implementation is loaded
RuntimeDelegate runtimeDelegate = new org.apache.cxf.jaxrs.impl.RuntimeDelegateImpl();
RuntimeDelegate.setInstance(runtimeDelegate);
}
}
Maybe you can make this as standard for the original CXFNonSpringJaxrsServlet.
> NoClassDefFoundError when using CXF JAX-RS in OSGi environment
> --------------------------------------------------------------
>
> Key: CXF-3949
> URL: https://issues.apache.org/jira/browse/CXF-3949
> 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:
> javax.ws.rs
> javax.ws.rs.core
> javax.ws.rs.ext
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira