Re: how can we set the service.exported.configs property of ExportScopes

[Peng Zheng <pe...@apache.org>]

On 3/26/22 11:21, xuzhenbao133 wrote:
> Hi,
>         In the remote service code, The service.exported.configs property of  exported service(eg:examples/calculator_service) has been ignored . However, when the service is exported,we use the  service.exported.configs property of  ExportScopes to match the RSA  configuration type.I don't know why we don't use the service.exported.configs property of the exported service to match the RSA  configuration type, and how can we set the  service.exported.configs property of ExportScopes.
>
>
> https://github.com/apache/celix/blob/master/bundles/remote_services/remote_service_admin_dfi/src/remote_service_admin_dfi.c  #L552-573
> https://github.com/apache/celix/blob/master/bundles/remote_services/topology_manager/src/topology_manager.c #L566-582e

ping

I guess this is buried by our large volume GitHub messages ;)

-- 
Peng Zheng

Re: how can we set the service.exported.configs property of ExportScopes

[Pepijn Noltes <pe...@gmail.com>]

Hi,

Indeed I did not notice this mail, thanks for the ping.

On Wed, Apr 6, 2022 at 5:20 AM Peng Zheng <pe...@apache.org> wrote:

> On 3/26/22 11:21, xuzhenbao133 wrote:
> > Hi,
> >         In the remote service code, The service.exported.configs
> property of  exported service(eg:examples/calculator_service) has been
> ignored . However, when the service is exported,we use the
> service.exported.configs property of  ExportScopes to match the RSA
> configuration type.I don't know why we don't use the
> service.exported.configs property of the exported service to match the RSA
> configuration type, and how can we set the  service.exported.configs
> property of ExportScopes.
> >
> >
> >
> https://github.com/apache/celix/blob/master/bundles/remote_services/remote_service_admin_dfi/src/remote_service_admin_dfi.c
> #L552-573
> >
> https://github.com/apache/celix/blob/master/bundles/remote_services/topology_manager/src/topology_manager.c
> #L566-582e
>


IMO handling the service.exported.configs and service.exported.intents (see
[1] and [2]) is IMO surprisingly complex to handle correctly.
I think the current C RSA tries to handle configs (but maybe not
correctly), but does not handle intents.

The C RSA also has some code about scope handling, but this has been
dormant for a while and - if I am correct - not part of the OSGi remote
services / RSA spec.
The idea behind scope handling was that you could have multiple distributed
applications running on the same discovery without interference (a bit like
kubernetes namespaces).

Looking at the code, I think the service.imported.configs is added to the
remote endpoint during export at:
https://github.com/apache/celix/blob/a47432c8fd34fbfaad0cc41f9c1b1a2e686dc9f1/bundles/remote_services/remote_service_admin_dfi/src/remote_service_admin_dfi.c#L722
(Note that a endpoint description has the service.imported properties, see
also [3])

And the check whether there is a service.exported.configs is configured and
matching is done at:
https://github.com/apache/celix/blob/a47432c8fd34fbfaad0cc41f9c1b1a2e686dc9f1/bundles/remote_services/remote_service_admin_dfi/src/remote_service_admin_dfi.c#L552-L565

Lastly for import this is also check and at:
https://github.com/apache/celix/blob/a47432c8fd34fbfaad0cc41f9c1b1a2e686dc9f1/bundles/remote_services/remote_service_admin_dfi/src/remote_service_admin_dfi.c#L812-L824

So I think the service.export.configs property is handled correctly by the
C RSA.

Maybe also good to mention is that the C RSA was based on the OSGi 4.3
spec, so I expect it is not up to date with the OSGi 8 spec

[1]
https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.remoteservices.html#i1709051
[2]
https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.remoteservices.html#d0e1241
[3]
https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.remoteserviceadmin.html#service.remoteserviceadmin.endpointdescription

Hope this helps and if there any more question, please feel free to ask.



> ping
>
> I guess this is buried by our large volume GitHub messages ;)
>
> --
> Peng Zheng
>
>
Greetings,
Pepijn