You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2017/10/11 11:32:00 UTC
[jira] [Resolved] (CXF-7528) [osgi] rt-transports-http should not
fail during servlet unregistration
[ https://issues.apache.org/jira/browse/CXF-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang resolved CXF-7528.
-------------------------------
Resolution: Fixed
> [osgi] rt-transports-http should not fail during servlet unregistration
> -----------------------------------------------------------------------
>
> Key: CXF-7528
> URL: https://issues.apache.org/jira/browse/CXF-7528
> Project: CXF
> Issue Type: Improvement
> Components: OSGi
> Affects Versions: 3.2.0
> Reporter: Grzegorz Grzybek
> Assignee: Freeman Fang
> Priority: Minor
> Fix For: 3.1.14, 3.2.1
>
>
> When OSGi framework is reprovisioned (e.g., during Karaf feature reinstallation), there may be a race related to CXF servlet registration/unregistration and we can see this in logs:
> {noformat}
> 2017-08-02 09:04:23,554 | ERROR | lixDispatchQueue | cxf-rt-transports-http | FrameworkEvent ERROR - org.apache.cxf.cxf-rt-transports-http
> java.lang.IllegalArgumentException: Alias [/cxf] was never registered
> at org.ops4j.pax.web.service.internal.HttpServiceStarted.unregister(HttpServiceStarted.java:278)
> at org.ops4j.pax.web.service.internal.HttpServiceProxy.unregister(HttpServiceProxy.java:77)
> at org.apache.cxf.transport.http.osgi.ServletExporter.updated(ServletExporter.java:54)
> at org.apache.cxf.transport.http.osgi.HttpServiceTrackerCust.removedService(HttpServiceTrackerCust.java:52)
> at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1)
> at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
> at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902)
> at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:943)
> at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:794)
> at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:544)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4445)
> at org.apache.felix.framework.Felix.access$000(Felix.java:77)
> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:404)
> at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:153)
> at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:128)
> at org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:336)
> at org.ops4j.pax.web.service.internal.Activator$2.run(Activator.java:286)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I think it'd be good to just print warning (or information) and continue. When http service is reregistered, servlet will be registered in proper instance of HttpService
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)