# Service scope vs Component scope?

**URL:** <https://bnd.discourse.group/t/service-scope-vs-component-scope/220>\
**Category:** GENERAL\
**Created:** [March 3, 2022, 11:34pm UTC](https://bnd.discourse.group/t/service-scope-vs-component-scope/220 "2022-03-03T23:34:13Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![chrisr3](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/chrisr3/32/58_2.png) [@chrisr3](https://bnd.discourse.group/u/chrisr3)\
**Post date:** [March 3, 2022, 11:34pm UTC](https://bnd.discourse.group/t/service-scope-vs-component-scope/220/1 "2022-03-03T23:34:13Z")

</div>

This is not really related to Bnd (sorry!), but…

I have naively been assuming that declaring a component as `@Component(scope = SINGLETON)` would mean its services would be registered with property `service.scope=singleton` too. And yet I am now discovering that they are being registered with `service.scope=bundle` instead?! 😕

The documentation implies that `service.scope=bundle` means that `BundleContext.registerService()` was passed an instance of `ServiceFactory` for its `service` parameter, and I _suppose_ that wouldn’t preclude that service still being a singleton _in practice_, but…

I was hoping to use a filter `(service.scope=singleton)` to select only `SINGLETON` _components_ from a pool of both `SINGLETON` and `PROTOTYPE` _components_. I can obviously change this filter to `(!(service.scope=prototype))` instead, but now I am wondering if that would work either because “service scope” and “component scope” are clearly not _quite_ the same thing.

Have I made a huge and terrible error here please? Do OSGi Declarative Services not distinguish between `service` and `bundle` scopes? After all, it isn’t as if there’s a `component.scope` property registered along with `component.name` and `component.id`. Although support for references with `ReferenceScope.PROTOTYPE_REQUIRED` must obviously be implemented somehow too, and a filter like mine would seem to be a reasonable candidate for that.

Thanks for any advice here,  
Cheers,  
Chris

---

<div class="post-metadata">

**Author:** ![rotty3000](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/rotty3000/32/16_2.png) [@rotty3000](https://bnd.discourse.group/u/rotty3000)\
**Post date:** [March 4, 2022, 4:34am UTC](https://bnd.discourse.group/t/service-scope-vs-component-scope/220/2 "2022-03-04T04:34:45Z")

</div>

Your component services having `@Component(scope = SINGLETON)` _are_ singletons 🙂 (You should be able to write tests that prove this pretty easily.)

The property `service.scope` is not one that is set by a service provider. In fact if you set it, it will be overruled based on the type of object registered.

[**Table 5.1 Standard Service Properties**](https://docs.osgi.org/specification/osgi.core/8.0.0/framework.service.html#framework.service-service.properties) describes `service.scope` as:

> The service.scope property identifies the service’s scope. The Framework must set this property automatically. If the registered service object implements PrototypeServiceFactory, then the value will be prototype. Otherwise, if the registered service object implements ServiceFactory, then the value will be bundle. Otherwise, the value will be singleton. See Service Scope.

DS _always_ registers it’s services using either `ServiceFactory` or `PrototypeServiceFactory`. It does this so that it can control the lifecycle of the actual service “objects” that it will ultimately provide.

So what you’re witnessing is a quirk of how DS is implemented.

This is what enables DS components to be _delayed_ based on the state of references or configuration dependencies or to be externally “disabled”. So the `service.scope=bundle` while true reflection of the fact that the service was actually registered as a `ServiceFactory` does not reflect the reality that DS (and not the service registry) is providing a singleton object whenever `ServiceFactory.getService` is called.

I hope that helps explain what you’re seeing 🙂

---

<div class="post-metadata">

**Author:** ![rotty3000](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/rotty3000/32/16_2.png) [@rotty3000](https://bnd.discourse.group/u/rotty3000)\
**Post date:** [March 4, 2022, 4:42am UTC](https://bnd.discourse.group/t/service-scope-vs-component-scope/220/3 "2022-03-04T04:42:14Z")

</div>

Now, as you’ve observed, there’s no property on the resulting service reference that outwardly lets you determine between a “component” that is `singleton` vs. `bundle` scope. For `prototype` scope the `service.scope` should be accurate. It’s those other two which are next to impossible to outwardly distinguish between which is unfortunate.

---

<div class="post-metadata">

**Author:** ![mnlipp](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/mnlipp/32/13_2.png) [@mnlipp](https://bnd.discourse.group/u/mnlipp)\
**Post date:** [March 4, 2022, 9:23am UTC](https://bnd.discourse.group/t/service-scope-vs-component-scope/220/4 "2022-03-04T09:23:45Z")

</div>

You can [query SCR](https://github.com/mnlipp/jgrapes-osgi/blob/48b94a20324c1d1420daa4a16de2a2eeb05dc329/org.jgrapes.osgi.webconlet.services/src/org/jgrapes/osgi/webconlet/services/ServiceListConlet.java#L199), which allows you to e.g. display the information like this:

![image](https://global.discourse-cdn.com/free1/uploads/bnd/original/1X/d64dd504b049ca2035d770d729fcc57abb06d856.png)

(Taken from [here](https://jgrapes-console-demo.herokuapp.com/).)

---

<div class="post-metadata">

**Author:** ![chrisr3](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/chrisr3/32/58_2.png) [@chrisr3](https://bnd.discourse.group/u/chrisr3)\
**Post date:** [March 4, 2022, 9:30am UTC](https://bnd.discourse.group/t/service-scope-vs-component-scope/220/5 "2022-03-04T09:30:46Z")

</div>

Thanks, I suspected the explanation was something like that. Not having a programmatic way to select `singleton` components is indeed unfortunate, but the blocker in my case would have been not being able to exclude `prototype` components.

Cheers,  
Chris
