[
https://issues.apache.org/jira/browse/ARIES-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971071#comment-16971071
]
Arnoud Glimmerveen commented on ARIES-1940:
-------------------------------------------
I thinks I would try to incorporate it in the current cleanup logic.
I noticed a currently unused method in ExportRegistrationImpl called
ExportReferenceAlways(). Which returns the ExportReference value, regardless of
exception/closure of the ExportRegistration.
It should be possible upon export failure to create a ExportReferenceImpl (with
service reference, but without EndpointDescription (as there is no endpoint
created)). The ServiceListener listening to UNREGISTERING events triggers logic
that could use the ExportReferenceAlways() method to see if the
ServiceReference matches and 'close' the failed ExportRegistration.
This approach would have a number of consequences:
* As the ExportReferenceAlways method is not part of the API, there is a need
to downcast to the specific implementation that has the method
** Alternatively you could within RemoteServiceAdminCore always refer to the
implementation class of ExportRegistration and only on the spec API (RSA's
external interface) go back to the API types.
* An ExportReference instance is created also for a failed ExportRegistration.
This instance will not be reachable through the spec API, so I don't think this
will be much of an issue
I have opened a PR with this approach.
> Failure during service export is not properly handled by
> RemoteServiceAdminCore
> -------------------------------------------------------------------------------
>
> Key: ARIES-1940
> URL: https://issues.apache.org/jira/browse/ARIES-1940
> Project: Aries
> Issue Type: Bug
> Components: Remote Service Admin
> Affects Versions: rsa-1.14.0
> Environment: Apache Aries 1.14.0
> Apache Felix Framework 6.0.2
> Reporter: Arnoud Glimmerveen
> Assignee: Christian Schneider
> Priority: Major
> Fix For: rsa-1.15.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a DistributionProvider throws an Exception from the
> DistributionProvider.exportService() method, the RemoteServiceAdminCore
> detects this properly and keeps track of this failure by creating a
> ExportRegistration instance that references the thrown Exception.
> The specification mandates that if a service export failed, the
> ExportRegistration should provide access to the thrown Exception (which the
> current implementation does) and that the ExportReference of the
> ExportRegistration should throw an IllegalStateException.
> The current implementation of RemoteServiceAdminCore handles this in an
> inconsistent way:
> * The ExportRegistration.getExportReference() returns null rather then
> throwing the IllegalStateException
> * The use of ExportRegistration assumes that there always is an
> ExportReference instance. This assumption is wrong in cases that the export
> failed.
> The latter triggers exceptions such as as the one below; typically triggered
> by an event unrelated to the export service failure:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.aries.rsa.core.RemoteServiceAdminCore.removeServiceExports(RemoteServiceAdminCore.java:505)
> at
> org.apache.aries.rsa.core.RemoteServiceAdminCore$2.serviceChanged(RemoteServiceAdminCore.java:104)
> at
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
> at org.apache.felix.framework.Felix.access$000(Felix.java:112)
> at
> org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:434)
> at
> org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:170)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:145)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
