cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Freeman Fang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-7528) [osgi] rt-transports-http should not fail during servlet unregistration
Date Wed, 11 Oct 2017 13:37:00 GMT

    [ https://issues.apache.org/jira/browse/CXF-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200279#comment-16200279
] 

Freeman Fang commented on CXF-7528:
-----------------------------------

Patch applied on behalf of Grzegorz Grzybek with thanks!

> [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)

Mime
View raw message