Hi All, As previously mentioned, Apache Celix is moving towards a new major release, and this comes with some API-breaking changes.
One of these changes is the removal of the old C API (all headers/functions without a `celix_` prefix). This means that users will need to adopt the updated API. However, with this new API, users won't have access to underlying service management objects like service reference, service registration, or service tracker. Even though these objects are part of the OSGi specification, they were omitted in the updated API for several reasons: - C does not have garbage collection, and using elements like service reference without additional locking or reference counting can lead to malfunctioning code. One could potentially address this with an explicit reference count or locking mechanism, but this would also deviate from the OSGi specification and iIMO such a change is more error-prone. - I believe service references, by design, are flawed. This is because one can use a service reference to check if an underlying service object remains available and then proceed to use it. However, due to the dynamic nature of OSGi services and the fact that the service reference does not lock the underlying service objects to prevent their removal, the actual service can be removed during its use. For Java, this is often not an issue, because the service remains in memory thanks to garbage collection. But if the service symbolizes an external resource, this could potentially (as per Murphy's Law) become problematic. - Abstraction leak: While this might be more of a personal preference, I believe that the utilization of a dynamic service framework shouldn't leak into application code. An Apache Celix service reference object is a good example of such a leak. It's worth noting that since the C standard doesn't have a concept of properties, leaking `celix_properties` is, in my view, acceptable. Also, `celix_properties` is a part of the utils library, not the framework library. - Using a long type as service ID, service tracker ID, etc., is more safe, because they can be reliably retained (always copied as value). The API will check for users if the provided ID remains valid and will act accordingly. Given these reasons, the updated Apache Celix API uses service IDs and tracking IDs to identify services or trackers and offers `useService*` and `useBundle*` calls. Users can offer a callback to avoid the use of dangling C objects or the utilization of services and bundles that have been removed. The intention was that this would cover all use cases for service reference, service registration, and service tracker within Apache Celix. There is one exception : Modifying service properties of an already registered service via the service registration object. However, changing the properties of a registered service in C is challenging, because it relies on garbage collection or requires additional ref counting. For most of the APIs and SPIs provided by Apache Celix, the use of service reference, service registration, or service tracker objects has already been removed. However, this isn't the case for the Apache Celix Remote Service Admin SPI. The Apache Celix RSA SPIs, has 2 locations where a service registration and service reference is used: - In `remote_proxy.h`: "service_registration_t *registration" within the `remote_proxy_factory` structure. - In `remote_service_admin.h`: "service_reference_pt" inside the `exportReference_getExportedService` function in the `remote_service_admin_service_t` structure. IMO in both instances, these could be replaced with a service id. For the `remote_proxy`, this would mean registering and unregistering services using the updated API. I also think that `exportReference_getExportedService` might be unneeded in the RSA interface, because it is not used by the topology manager. It's worth mentioning that the service reference is also used in the internal API, and ideally, this should also be updated. Any thoughts? Kind regards, Pepijn
