[jira] [Commented] (FELIX-5199) Race condition in HttpServiceFactory.getService() causing exception
[
https://issues.apache.org/jira/browse/FELIX-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15168580#comment-15168580
]
Carsten Ziegeler commented on FELIX-5199:
-
I think we need to check all objects that can get invalidated in stop(). If any
of these is null or closed, we should not return the service anymore. So maybe
using a simple flag (started/stopped) that's set in start/stop and evaluated in
the getService method is safer
> Race condition in HttpServiceFactory.getService() causing exception
> ---
>
> Key: FELIX-5199
> URL: https://issues.apache.org/jira/browse/FELIX-5199
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.6
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: felix-5199.patch
>
>
> The HttpServiceFactory.getService() is as follows:
> {code}
> public HttpService getService(final Bundle bundle, final
> ServiceRegistration reg)
> {
> final ServletContext servletContext = this.context;
> if ( servletContext != null ) {
> return new PerBundleHttpServiceImpl(bundle,
> this.sharedHttpService,
> this.context,
> this.contextAttributeListenerManager,
> this.sharedContextAttributes,
> this.requestListenerManager,
> this.requestAttributeListenerManager);
> }
> return null;
> }{code}
> However it is possible that this.context is set to {{null}} after the check
> for {{null}} is done but before the constructor is called causing a null
> servlet context to be passed to {{PerBundleHttpServiceImpl}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (FELIX-5198) Service should not be available while being unregistered
[ https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened FELIX-5198: - I think there is a difference between the service object and the service reference. I totally agree that the service object should be regarded as valid while the events are sent out. However ServiceRegistration.unregister clearly states that no one is able to obtain the service anymore. So I think it is correct that a service reference does not return the service anymore while unregistartion is in process. And without reading any details, for me this would be the normal behaviour.You already know that this service is dying, why should anyone want get a dying service? Now, there is one problem with this, and I think this covers the use cases mentioned by Richard: the service event contains a service reference and it should be possible to get the service object through this service reference - as this is what the spec says. Which means that the spec is slightly contradicting itself: ServiceRegistration.unregister says, no one is able to obtain the service, the UNREGISTERING event states the opposite. Therefore I think the slightly more correct behaviour would be: all service references given out, get invalidated when unregister is called - but the service reference passed in the event still allows access to the service. However I assume, we might get into trouble with this as we have two differently behaving service reference objects for the same service registration while unregistering. Not sure if its worth the effort. > Service should not be available while being unregistered > > > Key: FELIX-5198 > URL: https://issues.apache.org/jira/browse/FELIX-5198 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.4.0 >Reporter: Carsten Ziegeler >Assignee: David Bosschaert > Fix For: framework-5.6.0 > > Attachments: felix-5198.patch > > > Currently it is possible to get a service while it is being unregistered - > if the service is get during processing of the unregistering event. This is > the order of events: > a) a service (factory) is unregistered in the framework > b) the UNREGISTERING event is sent before the service is actually > unregistered (this is as defined in the spec) > c) the above event is handled synchronously, reactivating dependent components > d) during this reactivation, some component looks up the service that is > unregistered in a). as this service is still registered and marked as valid, > it gets it > According to ServiceRegistration.unregister the service should not be > available anymore while the events are sent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5199) Race condition in HttpServiceFactory.getService() causing exception
[
https://issues.apache.org/jira/browse/FELIX-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-5199:
Attachment: felix-5199.patch
The attached small patch fixes the issue. It would be great if someone could
review that I didn't miss anything.
> Race condition in HttpServiceFactory.getService() causing exception
> ---
>
> Key: FELIX-5199
> URL: https://issues.apache.org/jira/browse/FELIX-5199
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.6
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: felix-5199.patch
>
>
> The HttpServiceFactory.getService() is as follows:
> {code}
> public HttpService getService(final Bundle bundle, final
> ServiceRegistration reg)
> {
> final ServletContext servletContext = this.context;
> if ( servletContext != null ) {
> return new PerBundleHttpServiceImpl(bundle,
> this.sharedHttpService,
> this.context,
> this.contextAttributeListenerManager,
> this.sharedContextAttributes,
> this.requestListenerManager,
> this.requestAttributeListenerManager);
> }
> return null;
> }{code}
> However it is possible that this.context is set to {{null}} after the check
> for {{null}} is done but before the constructor is called causing a null
> servlet context to be passed to {{PerBundleHttpServiceImpl}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (FELIX-5199) Race condition in HttpServiceFactory.getService() causing exception
[
https://issues.apache.org/jira/browse/FELIX-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5199 started by David Bosschaert.
---
> Race condition in HttpServiceFactory.getService() causing exception
> ---
>
> Key: FELIX-5199
> URL: https://issues.apache.org/jira/browse/FELIX-5199
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.6
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>
> The HttpServiceFactory.getService() is as follows:
> {code}
> public HttpService getService(final Bundle bundle, final
> ServiceRegistration reg)
> {
> final ServletContext servletContext = this.context;
> if ( servletContext != null ) {
> return new PerBundleHttpServiceImpl(bundle,
> this.sharedHttpService,
> this.context,
> this.contextAttributeListenerManager,
> this.sharedContextAttributes,
> this.requestListenerManager,
> this.requestAttributeListenerManager);
> }
> return null;
> }{code}
> However it is possible that this.context is set to {{null}} after the check
> for {{null}} is done but before the constructor is called causing a null
> servlet context to be passed to {{PerBundleHttpServiceImpl}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5199) Race condition in HttpServiceFactory.getService() causing exception
David Bosschaert created FELIX-5199:
---
Summary: Race condition in HttpServiceFactory.getService() causing
exception
Key: FELIX-5199
URL: https://issues.apache.org/jira/browse/FELIX-5199
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http.base-3.0.6
Reporter: David Bosschaert
Assignee: David Bosschaert
The HttpServiceFactory.getService() is as follows:
{code}
public HttpService getService(final Bundle bundle, final
ServiceRegistration reg)
{
final ServletContext servletContext = this.context;
if ( servletContext != null ) {
return new PerBundleHttpServiceImpl(bundle,
this.sharedHttpService,
this.context,
this.contextAttributeListenerManager,
this.sharedContextAttributes,
this.requestListenerManager,
this.requestAttributeListenerManager);
}
return null;
}{code}
However it is possible that this.context is set to {{null}} after the check for
{{null}} is done but before the constructor is called causing a null servlet
context to be passed to {{PerBundleHttpServiceImpl}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-5198) Service should not be available while being unregistered
[ https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-5198. - Resolution: Invalid After further consultation with OSGi CPEG, it became clear to me that the current Felix behaviour is the correct one. Specifically, section 5.6.1 of the core spec states: bq. UNREGISTERING - A service object is in the process of being unregistered. This event is synchronously delivered before the service object has completed unregistering. That is, during the delivery of this event, the service object is still valid. The bundle receiving this event must release all references to this service before this method returns. So I'm afraid I have to close this issue as being invalid. Please reopen if anyone disagrees. > Service should not be available while being unregistered > > > Key: FELIX-5198 > URL: https://issues.apache.org/jira/browse/FELIX-5198 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.4.0 >Reporter: Carsten Ziegeler >Assignee: David Bosschaert > Fix For: framework-5.6.0 > > Attachments: felix-5198.patch > > > Currently it is possible to get a service while it is being unregistered - > if the service is get during processing of the unregistering event. This is > the order of events: > a) a service (factory) is unregistered in the framework > b) the UNREGISTERING event is sent before the service is actually > unregistered (this is as defined in the spec) > c) the above event is handled synchronously, reactivating dependent components > d) during this reactivation, some component looks up the service that is > unregistered in a). as this service is still registered and marked as valid, > it gets it > According to ServiceRegistration.unregister the service should not be > available anymore while the events are sent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5198) Service should not be available while being unregistered
[ https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167396#comment-15167396 ] Richard S. Hall commented on FELIX-5198: Of course it will trigger it. The issue was people wanted one last chance to talk to the service before it was gone. My position at the time was, "What's the point, the service probably isn't working anyway." Their position was, "Well, for my components I know they are working." It is legitimate that there is no chance to say goodbye unless we allow retrieval, but whether or not this is useful is totally dependent on the service implementation. I can pretty much guarantee that you will cause some people pain if you do this, but I'm not against it. > Service should not be available while being unregistered > > > Key: FELIX-5198 > URL: https://issues.apache.org/jira/browse/FELIX-5198 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.4.0 >Reporter: Carsten Ziegeler >Assignee: David Bosschaert > Fix For: framework-5.6.0 > > Attachments: felix-5198.patch > > > Currently it is possible to get a service while it is being unregistered - > if the service is get during processing of the unregistering event. This is > the order of events: > a) a service (factory) is unregistered in the framework > b) the UNREGISTERING event is sent before the service is actually > unregistered (this is as defined in the spec) > c) the above event is handled synchronously, reactivating dependent components > d) during this reactivation, some component looks up the service that is > unregistered in a). as this service is still registered and marked as valid, > it gets it > According to ServiceRegistration.unregister the service should not be > available anymore while the events are sent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5198) Service should not be available while being unregistered
[ https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-5198: Attachment: (was: felix-5198.patch) > Service should not be available while being unregistered > > > Key: FELIX-5198 > URL: https://issues.apache.org/jira/browse/FELIX-5198 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.4.0 >Reporter: Carsten Ziegeler >Assignee: David Bosschaert > Fix For: framework-5.6.0 > > Attachments: felix-5198.patch > > > Currently it is possible to get a service while it is being unregistered - > if the service is get during processing of the unregistering event. This is > the order of events: > a) a service (factory) is unregistered in the framework > b) the UNREGISTERING event is sent before the service is actually > unregistered (this is as defined in the spec) > c) the above event is handled synchronously, reactivating dependent components > d) during this reactivation, some component looks up the service that is > unregistered in a). as this service is still registered and marked as valid, > it gets it > According to ServiceRegistration.unregister the service should not be > available anymore while the events are sent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5198) Service should not be available while being unregistered
[
https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-5198:
Attachment: felix-5198.patch
felix-5198.patch
The ServiceRegistration.unregister() javadoc states:
"The following steps are required to unregister a service:
* The service is removed from the Framework service registry so that it can no
longer be obtained.
* A service event of type {{ServiceEvent.UNREGISTERING}} is fired so that
bundles using this service can release their use of the service.
* Once delivery of the service event is complete, the {{ServiceReference}}
objects for the service may no longer be used to get a service object for the
service.
* ..."
I guess the question is: can a reference that is obtained before the service is
unregistered be used _during_ the UNREGISTERING event notification to re-obtain
the service?
The attached very small patch will not return the service any more for
pre-existing references when they try to obtain the service during an
UNREGISTERING callback and fixes the test failure. It also passes the R6 CT.
[~cziegeler], I did modify the test a tiny bit so that the service is
unregistered via ServiceRegistration.unregister().
[~rickhall], do you think the attached patch is acceptible? Or will it trigger
the issues you are referring to?
> Service should not be available while being unregistered
>
>
> Key: FELIX-5198
> URL: https://issues.apache.org/jira/browse/FELIX-5198
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.4.0
>Reporter: Carsten Ziegeler
>Assignee: David Bosschaert
> Fix For: framework-5.6.0
>
> Attachments: felix-5198.patch, felix-5198.patch
>
>
> Currently it is possible to get a service while it is being unregistered -
> if the service is get during processing of the unregistering event. This is
> the order of events:
> a) a service (factory) is unregistered in the framework
> b) the UNREGISTERING event is sent before the service is actually
> unregistered (this is as defined in the spec)
> c) the above event is handled synchronously, reactivating dependent components
> d) during this reactivation, some component looks up the service that is
> unregistered in a). as this service is still registered and marked as valid,
> it gets it
> According to ServiceRegistration.unregister the service should not be
> available anymore while the events are sent
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (FELIX-5198) Service should not be available while being unregistered
[ https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167251#comment-15167251 ] Richard S. Hall edited comment on FELIX-5198 at 2/25/16 2:36 PM: - I won't say I remember all of the specifics, but there are issues around this. I think at one time we did implement it so that a service became unavailable as soon as unregistering started, but we received a lot of blow back from people who wanted to do something with the service to say goodbye. The compromise we came up with was [I think] to only allow people who already had services references to be able to get a service, but to not allow any new lookups once unregistration started. was (Author: rickhall): I won't say I remember all of the specifics, but there are issues around this. I think at one time we did implement it so that a service became unavailable as soon as unregistering started, but we received a lot of blow back from people who wanted to do something with the service to say goodbye. The compromise we came up with was [I think] to only allow people who already had services references to be able to get a service, but to now allow any new lookups once unregistration started. > Service should not be available while being unregistered > > > Key: FELIX-5198 > URL: https://issues.apache.org/jira/browse/FELIX-5198 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.4.0 >Reporter: Carsten Ziegeler >Assignee: David Bosschaert > Fix For: framework-5.6.0 > > > Currently it is possible to get a service while it is being unregistered - > if the service is get during processing of the unregistering event. This is > the order of events: > a) a service (factory) is unregistered in the framework > b) the UNREGISTERING event is sent before the service is actually > unregistered (this is as defined in the spec) > c) the above event is handled synchronously, reactivating dependent components > d) during this reactivation, some component looks up the service that is > unregistered in a). as this service is still registered and marked as valid, > it gets it > According to ServiceRegistration.unregister the service should not be > available anymore while the events are sent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5198) Service should not be available while being unregistered
[ https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167251#comment-15167251 ] Richard S. Hall commented on FELIX-5198: I won't say I remember all of the specifics, but there are issues around this. I think at one time we did implement it so that a service became unavailable as soon as unregistering started, but we received a lot of blow back from people who wanted to do something with the service to say goodbye. The compromise we came up with was [I think] to only allow people who already had services references to be able to get a service, but to now allow any new lookups once unregistration started. > Service should not be available while being unregistered > > > Key: FELIX-5198 > URL: https://issues.apache.org/jira/browse/FELIX-5198 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.4.0 >Reporter: Carsten Ziegeler >Assignee: David Bosschaert > Fix For: framework-5.6.0 > > > Currently it is possible to get a service while it is being unregistered - > if the service is get during processing of the unregistering event. This is > the order of events: > a) a service (factory) is unregistered in the framework > b) the UNREGISTERING event is sent before the service is actually > unregistered (this is as defined in the spec) > c) the above event is handled synchronously, reactivating dependent components > d) during this reactivation, some component looks up the service that is > unregistered in a). as this service is still registered and marked as valid, > it gets it > According to ServiceRegistration.unregister the service should not be > available anymore while the events are sent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4399) UserAdmin MongoDB plugin cannot return role when properties or members is null
[
https://issues.apache.org/jira/browse/FELIX-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.W. Janssen updated FELIX-4399:
Fix Version/s: useradmin-mongo-next
> UserAdmin MongoDB plugin cannot return role when properties or members is null
> --
>
> Key: FELIX-4399
> URL: https://issues.apache.org/jira/browse/FELIX-4399
> Project: Felix
> Issue Type: Bug
> Components: User Admin
> Environment: MongoDB 32-bit, v2.4.9
> Java 1.7
> UserAdmin 1.0.3
>Reporter: Alec de Zegher
>Assignee: J.W. Janssen
> Fix For: useradmin-mongo-next
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> When fetching a role with no properties or roles from mongodb, a null object
> is returned by the DB. This causes a null pointer exception and as a result
> no roles are returned.
> This can be solved by modifying following three methods in
> MongoSerializerHelper.java to:
> /**
> * Deserializes the given {@link DBObject} into the given {@link
> Dictionary}.
> *
> * @param dictionary the dictionary to fill;
> * @param object the {@link DBObject} to deserialize.
> */
> private void deserializeDictionary(Dictionary dictionary, DBObject
> object) {
> if(object != null) {
> for (String key : object.keySet()) {
> dictionary.put(KeyCodec.decode(key), object.get(key));
> }
> }
> }
>
> /**
> * Serializes a given array of {@link Role}s to an list for storing in a
> {@link DBObject}.
> *
> * @param members the {@link Role}s to serialize, cannot be
> null.
> * @return the "serialized" array, never null.
> */
> private List getRoleNames(Role[] members) {
> List result = new ArrayList();
> if (members != null) {
> for (Role member : members) {
> result.add(member.getName());
> }
> }
> return result;
> }
>
> /**
> * Returns all roles mentioned in the given list.
> *
> * @param list the list with role names to convert.
> * @return a list with {@link Role}s, never null.
> */
> private List getRoles(BasicDBList list) {
> List result = new ArrayList();
> if(list !=null) {
> for (int i = 0, size = list.size(); i < size; i++) {
> final String memberName = (String) list.get(i);
> result.add(findExistingMember(memberName));
> }
> }
> return result;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4279) UserAdmin does not export OSGi packages
[ https://issues.apache.org/jira/browse/FELIX-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen updated FELIX-4279: Fix Version/s: useradmin-next > UserAdmin does not export OSGi packages > --- > > Key: FELIX-4279 > URL: https://issues.apache.org/jira/browse/FELIX-4279 > Project: Felix > Issue Type: Bug > Components: User Admin >Reporter: J.W. Janssen >Assignee: J.W. Janssen >Priority: Critical > Fix For: useradmin-next > > > The Felix UserAdmin bundle does not export the `org.osgi.service.useradmin` > package. This means that a compendium bundle should always be deployed along > with this bundle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4280) UserAdmin has hard dependency on EventAdmin
[ https://issues.apache.org/jira/browse/FELIX-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen updated FELIX-4280: Fix Version/s: useradmin-next > UserAdmin has hard dependency on EventAdmin > --- > > Key: FELIX-4280 > URL: https://issues.apache.org/jira/browse/FELIX-4280 > Project: Felix > Issue Type: Bug > Components: User Admin >Reporter: J.W. Janssen >Assignee: J.W. Janssen > Fix For: useradmin-next > > > The import requirements of Felix UserAdmin require > `org.osgi.service.eventadmin` as well. This is not required by the UserAdmin > 1.1 specification and therefore should be optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-3802) Remove MongoDB dependency from NOTICE file
[ https://issues.apache.org/jira/browse/FELIX-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen updated FELIX-3802: Fix Version/s: useradmin-mongo-next > Remove MongoDB dependency from NOTICE file > -- > > Key: FELIX-3802 > URL: https://issues.apache.org/jira/browse/FELIX-3802 > Project: Felix > Issue Type: Task > Components: User Admin >Reporter: J.W. Janssen > Fix For: useradmin-mongo-next > > > The MongoDB-based store lists a dependency on MongoDB in its NOTICE file. > This isn't necessary/wanted and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5198) Service should not be available while being unregistered
[
https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15166938#comment-15166938
]
Carsten Ziegeler commented on FELIX-5198:
-
Test case which currently fails:
Index: src/test/java/org/apache/felix/framework/ServiceRegistryTest.java
===
--- src/test/java/org/apache/felix/framework/ServiceRegistryTest.java
(Revision 1732253)
+++ src/test/java/org/apache/felix/framework/ServiceRegistryTest.java
(Arbeitskopie)
@@ -23,6 +23,7 @@
import java.util.Arrays;
import java.util.Collection;
import java.util.Collections;
+import java.util.Dictionary;
import java.util.Hashtable;
import java.util.List;
import java.util.Observable;
@@ -31,11 +32,11 @@
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicInteger;
+import java.util.concurrent.atomic.AtomicReference;
-import junit.framework.TestCase;
-
import org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl;
import org.apache.felix.framework.ServiceRegistry.ServiceHolder;
+import org.apache.felix.framework.ServiceRegistry.ServiceRegistryCallbacks;
import org.apache.felix.framework.ServiceRegistry.UsageCount;
import org.easymock.MockControl;
import org.mockito.AdditionalAnswers;
@@ -54,6 +55,8 @@
import org.osgi.framework.hooks.service.FindHook;
import org.osgi.framework.hooks.service.ListenerHook;
+import junit.framework.TestCase;
+
public class ServiceRegistryTest extends TestCase
{
public void testRegisterEventHookService()
@@ -1228,6 +1231,34 @@
sb.append("Obtained service");
}
+public void testGettingServiceWhileUnregistering() throws Exception
+{
+final Bundle regBundle = Mockito.mock(Bundle.class);
+
+final AtomicReference registryRef = new
AtomicReference();
+final AtomicReference referenceRef = new
AtomicReference();
+final ServiceRegistryCallbacks callback = new
ServiceRegistryCallbacks()
+{
+
+@Override
+public void serviceChanged(ServiceEvent event, Dictionary
oldProps)
+{
+if ( event.getType() == ServiceEvent.UNREGISTERING ) {
+final Object obj = registryRef.get().getService(regBundle,
referenceRef.get(), false);
+assertNull(obj);
+}
+}
+
+};
+ServiceRegistry sr = new ServiceRegistry(null, callback);
+registryRef.set(sr);
+
+ServiceRegistration reg1 = sr.registerService(
+regBundle, new String [] {String.class.getName()}, "service is
unregistering", null);
+referenceRef.set(reg1.getReference());
+sr.unregisterService(regBundle, reg1);
+}
+
private Object getPrivateField(Object obj, String fieldName) throws
NoSuchFieldException,
IllegalAccessException
{
> Service should not be available while being unregistered
>
>
> Key: FELIX-5198
> URL: https://issues.apache.org/jira/browse/FELIX-5198
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.4.0
>Reporter: Carsten Ziegeler
>Assignee: David Bosschaert
> Fix For: framework-5.6.0
>
>
> Currently it is possible to get a service while it is being unregistered -
> if the service is get during processing of the unregistering event. This is
> the order of events:
> a) a service (factory) is unregistered in the framework
> b) the UNREGISTERING event is sent before the service is actually
> unregistered (this is as defined in the spec)
> c) the above event is handled synchronously, reactivating dependent components
> d) during this reactivation, some component looks up the service that is
> unregistered in a). as this service is still registered and marked as valid,
> it gets it
> According to ServiceRegistration.unregister the service should not be
> available anymore while the events are sent
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5198) Service should not be available while being unregistered
Carsten Ziegeler created FELIX-5198: --- Summary: Service should not be available while being unregistered Key: FELIX-5198 URL: https://issues.apache.org/jira/browse/FELIX-5198 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-5.4.0 Reporter: Carsten Ziegeler Assignee: David Bosschaert Fix For: framework-5.6.0 Currently it is possible to get a service while it is being unregistered - if the service is get during processing of the unregistering event. This is the order of events: a) a service (factory) is unregistered in the framework b) the UNREGISTERING event is sent before the service is actually unregistered (this is as defined in the spec) c) the above event is handled synchronously, reactivating dependent components d) during this reactivation, some component looks up the service that is unregistered in a). as this service is still registered and marked as valid, it gets it According to ServiceRegistration.unregister the service should not be available anymore while the events are sent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
